NTT DATA AIVista and Snowflake: Identity alone won’t secure enterprise AI agents

enterprise AI agents">

Presented by NTT DATA AIVista VentureBeat’s June research found that 69% of enterprises are still running AI agents that share credentials, a practice associated with higher rates of security incidents and near-incidents. But at VB Transform 2026 , Mukesh Karki, CTO of NTT DATA AIVista, and Mayank Upadhyay, chief security and trust officer at Snowflake, argued that fixing identity is only the first step. Enterprises also need action-level authorization and tamper-resistant audit trails built into every agent interaction if they’re going to deploy autonomous systems safely at scale. "These organizations need to be able to prove to their auditors in a very tamper-resistant fashion that those records showing what they did actually prove what they're doing," Karki said. "And the provability is essentially your license to operate in a regulatory environment." Why shared credentials cause agentic AI security incidents The problem, Upadhyay says, is many assumptions were carried over from an earlier generation of software. "In the traditional software world, a human being clicks somewhere and the software does something very deterministic, and you know which API it's going to call," he said. "But in the agentic world, the software has a brain of its own, and it's constantly rewiring itself. If you give this software more permission than it needs for a particular goal, agents are exploratory by nature, so they're going to try lots of different things, and you'll have unintended side effects." Embedding a single static API key compounds the exposure, he added. "It's a really bad pattern if you have one API key, you shove it into the agent, and it's talking as anybody to a particular SaaS service, because then you're giving this agent the union of everybody's needs," he said, noting that the second failure mode is forensic, since "things may go wrong, and you wouldn't be able to attribute it to the right agent." Scoped credentials are only the starting point in regulated industries Karki, whose clients are mostly in insurance, healthcare, and finance, treats scoped credentials as table stakes. "In a regulatory setting, an agent that's not broadly scoped with shared scope credentials is not going to run, period," Karki said. "Having a scope credential is just a starting point. There are actually two layered constraints. One is the jurisdiction in which the agent operates, and then it's the jurisdiction or the rules of that organization." For instance, a claims adjustment agent in Washington State operates on different regulations than one in California, he adds, and every claim is different. "Those scoped credentials are not enough, because it has to be action-based and rules-based at the time it's taking action," he added. Where the employee analogy for AI agents breaks down The employee analogy, Karki argued, only goes so far. Agents still need to learn an organization’s unique context, much as a new employee does. But unlike people, enterprises can’t realistically build trust with thousands of agents over time. “A star employee in one organization might not be the best employee when they move to a different organization, not because they became worse, but because they don’t have the context of this new place, and the same is true with agents,” Karki said. “If every employee has 100 agents, you can’t say you’re going to onboard these agents and do a background check on them.” Upadhyay said the employee analogy should place agents one rung lower in the organizational hierarchy. "Treat them like interns," he suggested. "They have good intent, but they don't always know what they're doing, and you have to keep your eye on them while you gradually build trust." On the Snowflake platform, administrators can impose platform-wide guardrails such as read-only operations, while developers further narrow an agent’s permissions when they launch each session. A three-layer approach to AI agent governance There's no question where governance belongs, Karki says. "Governance has to happen at every agent action, and it has to sit outside the agent," he explained. "That's the only way you'll be able to prove later that the agent took an action it was allowed to take." Upadhyay broke governance into three layers: The agent layer covers identity, tool permissions, and MCP governance. The model layer addresses indirect prompt injection and enables models to run inside the customer’s VPC so prompts remain invisible to the model provider. The data layer covers least-privilege access, zero-copy architecture, and role-based access control. For agents to work properly, governance is required across all three. What enterprises should audit first For enterprises auditing the governance of existing AI agents, Upadhyay recommends starting in two places. The first is auditing permissions for static secrets, the largest fixable attack vector. Next is addressing shadow AI through an MCP gateway, so developers no longer have to run bootlegged open-source MCP servers under their desks and administrators have visibility into who’s talking to which MCP server. There's a tradeoff between constraint and capability, and that can be addressed at the task level, with confidence scoring used to withhold autonomous execution on high-risk actions, and sandboxing as a middle path. But Karki cautions enterprises already scaling their agentic systems. "A lot of this can't be retrofitted after you have an agentic system running, and it's even harder to retrofit if you have to prove to your auditors why exactly the agent behaved the way it did," he explained. "Provability has to be built ground up when you're designing the system." Sponsored articles are content produced by a company that is either paying for the post or has a business relationship with VentureBeat, and they’re always clearly marked. For more information, contact sales@venturebeat.com .