AI agent identity threats: why MCP and token vaults matter

At a glance

What this is: This is an analysis of how AI agent connectivity through MCP and token vaults creates new identity security exposure, especially around privilege accumulation, prompt injection, and token theft.

Why it matters: It matters because IAM, PAM, and lifecycle controls built for humans or static machine identities do not fully cover agents that act, expand access, and call tools at runtime.

👉 Read Unosecur's analysis of MCP, token vaults, and AI agent identity threats

Context

AI agent identity risk emerges when software can act on behalf of users while also selecting tools and executing actions across systems. The article argues that Model Context Protocol and token vaults make this connectivity easier, but they also create a governance gap for identity security programmes.

The core issue for practitioners is that an AI agent is not just another service account. It can accumulate privilege, consume short-lived tokens, and interact with multiple applications in ways that complicate access review, zero trust enforcement, and token lifecycle control.

Key questions

Q: How should security teams govern AI agents that use external tools and data sources?

A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped permissions, and continuous monitoring. The key is to bind each agent to a task and a reviewer, then limit the tokens and tools it can reach. Governance must cover runtime behaviour, not just initial provisioning.

Q: Why do AI agents create more identity risk than traditional service accounts?

A: AI agents can change actions based on runtime context, which means their effective authority may expand as tasks evolve. Traditional service accounts usually follow fixed patterns, but agents can chain tool calls, request new access, and consume multiple tokens. That makes privilege review, audit, and containment harder.

Q: What breaks when token vaults are treated as a complete security control?

A: What breaks is the assumption that hiding raw secrets solves the access problem. Token vaults reduce direct credential exposure, but they do not prevent over-scoped issuance, delayed revocation, or misuse of delegated access. If the agent can still obtain broad authority, the vault is only reducing one exposure path.

Q: How can organisations reduce the blast radius of compromised AI agent credentials?

A: Organisations should shorten token lifetime, narrow tool permissions, and separate agent access by task and environment. They also need logging that links token issuance to actual use so a compromised credential can be isolated quickly. The goal is to stop one stolen token from becoming broad system impersonation.

Technical breakdown

Model Context Protocol and AI agent connectivity

MCP is a standardised way for AI agents to connect to external tools and data sources through context-aware requests rather than custom one-off integrations. In practice, it moves authorisation closer to the interaction layer, where the agent can request actions, fetch data, and trigger workflows through a common protocol. That improves interoperability, but it also means the security model now depends on the correctness of runtime context, token scope, and downstream permission enforcement. If the agent is granted broad tool access, MCP can become the delivery path for excessive privilege rather than a control point.

Practical implication: Treat MCP integrations as privileged access paths and review tool scopes as carefully as API credentials.

Token vaults and ephemeral credential handling

Token vaults are designed to issue, refresh, and revoke short-lived credentials so an AI agent does not directly handle raw passwords or long-lived API keys. That reduces obvious secret exposure, but it does not remove the underlying identity problem. The vault becomes part of the trust chain, and any gap in token scoping, revocation timing, or service-to-service delegation can still let an agent retain more access than intended. This is especially important when one agent is working across several systems, because the effective blast radius is determined by the widest token set it can obtain during execution.

Practical implication: Constrain token issuance to task scope and verify revocation actually happens when the task ends.

Why prompt injection becomes an identity event

Prompt injection is not just content manipulation. In an agentic environment, malicious instructions can cause the system to call tools, move data, or expose credentials that were never meant to leave the trust boundary. That is why the risk belongs in identity governance as much as application security. If the agent can interpret instructions and then act with linked credentials, the attack path becomes a delegated identity abuse case. The real failure is not only the prompt itself, but the fact that the agent’s authority can be redirected at runtime.

Practical implication: Map prompt injection scenarios to the identities and tokens the agent can reach, not just to model safety controls.

NHI Mgmt Group analysis

AI agent connectivity is creating an identity class that sits between humans and workloads. MCP and token vaults do not eliminate identity risk, they shift it into a more dynamic execution model where access is acquired, used, and extended at runtime. That means traditional service account assumptions no longer fully describe the subject being governed. Practitioners should treat agent identity as a distinct control domain.

Privilege creep is the right named concept for this problem, but the mechanism is different from human role drift. AI agents can accumulate access as tasks expand, integrations multiply, and token scope is widened to keep workflows functioning. The result is a growing entitlement surface that is operationally convenient and governance-poor. The implication is that access review designed for stable accounts will under-measure agent authority.

Prompt injection is an identity abuse path when the agent can act on the instructions it receives. The article correctly links malicious prompts to unintended actions, data disclosure, and workflow execution. That matters because the control failure is not simply unsafe text handling, but delegated authority being steered by untrusted input. Security teams should evaluate agent governance as a combined identity and instruction integrity problem.

Token theft becomes structurally worse when one compromised credential can represent several downstream systems. A stolen token is no longer just a secret exposure event. For AI agents, it can become a multi-system impersonation vector that bypasses the original user and the orchestration layer. Practitioners need to view token vault design as part of identity blast-radius management, not just secrets hygiene.

Zero standing privilege is a useful ambition, but the harder question is whether the agent can ever be safely re-authorised at runtime. AI agents that request access only during active execution reduce persistence, yet they also require continuous policy decisions that legacy IAM was not built to make. The field needs to rethink whether access decisions should be tied to a task, a user, or an agent lifecycle state.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• For a wider control model, see OWASP Agentic AI Top 10 for agent goal hijacking, tool misuse, and identity abuse patterns.

What this signals

Privilege creep is becoming a runtime problem, not just a recertification problem. Once agents can add tools, call systems, and inherit tokens on demand, access reviews alone will miss the moment when authority expands. Teams should pair lifecycle governance with execution telemetry so agent scope drift is visible while it is happening.

With 80% of organisations already reporting agents acting beyond intended scope, the governance gap is no longer theoretical. Programmes that still treat agent access as a variant of service account management will understate risk, especially where token vaults hide the underlying entitlement growth.

Identity blast radius: the useful unit of analysis is no longer the credential itself, but how far one agent token can travel across tools, data sets, and downstream automations. Security teams should design controls that collapse the reachable path, not just rotate the secret.

For practitioners

• Classify AI agents as governed identities Put agents into the same inventory and review cadence used for other non-human identities, with explicit ownership, purpose, and approval paths for each agent instance.
• Constrain token scope to the smallest task boundary Issue credentials only for the action being executed, and make revocation automatic when the task completes or the workflow changes direction.
• Test agent workflows for prompt-driven privilege escalation Red-team the prompts, tool paths, and downstream permissions together so you can see where a malicious instruction can trigger access outside the intended boundary.
• Monitor token use as an identity signal Correlate agent activity, token issuance, and tool invocation patterns so unusual access expansion is visible before the agent completes a full chain of actions.

Key takeaways

• AI agent connectivity through MCP and token vaults introduces a distinct identity governance problem because runtime action, tool use, and credential handling are now intertwined.
• The evidence already shows scope overreach is common, with 80% of organisations reporting agents acting beyond intended scope and 52% unable to audit the data those agents access.
• Practitioners need to govern agents as identities, not integrations, by narrowing task scope, limiting token reach, and making runtime behaviour observable.

Key terms

• MCP: Model Context Protocol is a standard that lets AI agents connect to external tools and data sources through a common interface. In identity terms, it shifts trust into the runtime interaction layer, where access decisions, tool selection, and context-aware authorisation all have to work together.
• Token Vault: A token vault is a controlled system for issuing, storing, refreshing, and revoking access tokens on behalf of an agent or user. It reduces direct exposure of raw secrets, but it still has to enforce scope, duration, and revocation correctly or it becomes part of the attack surface.
• AI Privilege Creep: AI privilege creep is the gradual expansion of an agent's effective authority as tasks, integrations, and tokens accumulate over time. It resembles traditional privilege creep, but it moves faster and is harder to detect because the expansion happens through runtime behaviour rather than obvious account changes.
• Identity Blast Radius: Identity blast radius is the amount of systems, data, and actions reachable through a single identity or credential. For AI agents, it is shaped by token scope, tool permissions, and delegation paths, which makes the reachable impact larger than the secret itself.

What's in the full article

Unosecur's full article covers the operational detail this post intentionally leaves for the source:

• The article walks through how MCP changes the mechanics of AI-to-tool connectivity in real deployments.
• It breaks down token vault behavior for short-lived credential issuance, refresh, and revocation.
• It lists practical threat patterns including privilege accumulation, prompt injection, and token theft.
• It closes with FAQ guidance on Zero Standing Privileges, visibility, and framework alignment.

👉 Unosecur's full article covers the threat patterns, token handling issues, and governance questions in more operational detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.