AI agent security needs more than identity, NTT DATA and Snowflake say

AI agent security cannot be solved by issuing each agent its own identity, NTT DATA AIVista CTO Mukesh Karki and Snowflake chief security and trust officer Mayank Upadhyay said at VB Transform 2026. VentureBeat’s June research found that 69% of enterprises still use AI agents that share credentials, a pattern tied to higher rates of security incidents and near misses.

Karki and Upadhyay argued that enterprises deploying autonomous systems need controls at the level of each action, plus audit records that can withstand scrutiny. For regulated buyers, the claim is practical: auditors need evidence showing what an agent did, why it was permitted and whether the record was altered.

Why are shared credentials risky for AI agents?

Upadhyay said many companies are applying old software assumptions to agentic systems. Traditional applications usually execute a predictable flow after a user clicks a button. Agents can choose tools and paths as they work toward a goal, which makes broad permissions more dangerous.

The shared API key problem is both an access issue and a forensic one, according to Upadhyay. If one static credential lets an agent act across multiple users’ needs, the agent inherits more authority than a specific task requires. If something breaks or violates policy, the company may also struggle to link the action to the right agent.

Scoped credentials reduce that exposure, but Karki said they are only the baseline for customers in insurance, healthcare and financial services. In his view, regulated environments require limits based on the jurisdiction where an agent acts and the organization’s own rules.

He gave the example of claims adjustment, where an agent operating in Washington State may face different requirements from one handling a claim in California. The permission check cannot stop at whether the agent has a valid credential. It must evaluate whether the specific action is allowed at that moment under the relevant rules.

What does action-level authorization mean for AI agents?

Action-level authorization means checking an agent’s authority each time it tries to do something, rather than granting broad access at the start of a session. For an enterprise, that can mean approving a read action while blocking a payment, claim change or data transfer unless the task, confidence level and policy context support it.

Karki said governance should sit outside the agent and apply to every action. That separation matters because the enterprise later has to show that the agent was permitted to act, rather than relying on the agent’s own explanation of its behavior.

Upadhyay described governance across three layers:

• The agent layer, covering identity, tool permissions and MCP governance.
• The model layer, including protections against indirect prompt injection and the option to run models inside a customer’s VPC so prompts are not exposed to the model provider.
• The data layer, including least-privilege access, zero-copy architecture and role-based access control.

Snowflake administrators can set platform-wide limits such as read-only operations, Upadhyay said, while developers can narrow permissions further when they start an agent session.

What should enterprises audit first?

Upadhyay said companies reviewing current agent deployments should first examine static secrets and permissions, which he described as the largest fixable attack vector. He also pointed to shadow AI and said enterprises should use an MCP gateway to see which developers and systems are connecting to which MCP servers, rather than allowing unmanaged open-source servers to proliferate.

Both executives framed AI agents less like fully trusted employees and more like workers that need supervision while trust is built. Karki said that analogy breaks at scale because a company cannot realistically onboard and vet thousands of agents the way it would human staff. Upadhyay suggested treating agents more like interns: useful, but requiring oversight.

Karki warned that auditability is difficult to add after agent systems are already in production, especially when a company must explain agent behavior to regulators. His position was that provable records and policy enforcement need to be designed into the system from the start.

This story draws on original reporting from VentureBeat.