Safety

Fixing Agent Identity Is Only Step One for Secure Autonomous Systems, Say NTT DATA AIVista and Snowflake

At VB Transform 2026, Mukesh Karki of NTT DATA AIVista and Mayank Upadhyay of Snowflake warned that correcting shared credentials for AI agents is necessary but insufficient.

Fixing Agent Identity Is Only Step One for Secure Autonomous Systems, Say NTT DATA AIVista and Snowflake

At VB Transform 2026, Mukesh Karki, CTO of NTT DATA AIVista, and Mayank Upadhyay, Chief Security and Trust Officer at Snowflake, argued that while resolving identity issues is necessary, it is not sufficient to operate agentic AI systems safely at scale. They said enterprises must also implement action-level authorization and tamper-resistant audit trails for every agent interaction.

Why shared credentials create security incidents

VentureBeat’s June research found that 69% of enterprises are still running AI agents that share credentials, a practice linked to higher rates of security incidents and near-incidents. Upadhyay noted that many problematic assumptions were copied from earlier generations 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 inside an agent increases exposure. Upadhyay said: "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 added that this pattern also undermines forensics, since it becomes difficult to attribute actions to the correct agent when something goes wrong.

Scoped credentials are only the starting point in regulated industries

Karki, whose clients are largely 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," he said. However, he emphasized that scoped credentials are only the beginning: there are layered constraints, including the jurisdiction where the agent operates and the internal rules of the organization.

He pointed out that a claims adjustment agent operating in Washington state faces different regulations than one in California, and every claim is unique. "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 breaks down

Karki argued the analogy of treating agents like employees is limited. Agents need to learn an organization’s context like a new hire, but companies cannot 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 suggested placing agents one rung lower in the hierarchy: "Treat them like interns. 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 Snowflake, administrators can impose platform-wide guardrails such as read-only operations, while developers narrow an agent’s permissions when launching each session.

A three-layer approach to AI agent governance

Karki emphasized that governance must occur at every agent action and sit outside the agent: "That's the only way you'll be able to prove later that the agent took an action it was allowed to take."

Upadhyay described governance across three layers:

  • Agent layer: identity, tool permissions, and MCP governance.
  • Model layer: protections against indirect prompt injection and the option to run models inside the customer VPC so prompts remain invisible to the model provider.
  • Data layer: least-privilege access, zero-copy architecture, and role-based access control.

All three layers must be governed for agents to behave appropriately and safely.

What enterprises should audit first

For companies auditing governance of existing agents, Upadhyay recommended starting with two areas. The first is auditing permissions for static secrets, the largest fixable attack vector. The second is addressing shadow AI through an MCP gateway, preventing developers from running unmanaged MCP servers and giving administrators visibility into who is communicating with which MCP.

There is a tradeoff between constraint and capability that can be managed at the task level: use confidence scoring to withhold autonomous execution on high-risk actions and sandboxing as a middle path. Karki warned that many controls cannot be retrofitted after an agentic system is already running, and retrofitting is harder when auditors require proofs of why an agent behaved a certain way. "Provability has to be built ground up when you're designing the system," he said.


Sponsored content: the piece was presented by NTT DATA AIVista. VentureBeat notes that sponsored articles are created by companies that pay for placement or have business relationships with the publisher, and these items are clearly labeled.