AI agent identity gaps widen across APIs, cloud, and LLMs

At a glance

What this is: Aembit argues that AI agents create a multi-protocol identity problem because one task can span API keys, OAuth tokens, managed identities and MCP credentials across separate trust boundaries.

Why it matters: IAM and security teams need to govern AI agent access as a cross-protocol identity problem, or they will keep leaving unowned gaps between credential systems.

By the numbers:

• Growing at a CAGR of roughly 46%, AI agents are increasingly deployed across production environments.

Context

AI agent identity is the governance problem that appears when one runtime needs to authenticate across several systems, not just one. The article describes an agent that can use an LLM API key, an OAuth token, a cloud identity session and an MCP token within the same task, which breaks the assumption that one control plane can govern the whole access path.

The security gap is not the existence of credentials. It is that each protocol has its own validation model, lifecycle and visibility boundary, so controls tuned for one layer do not see the others. For IAM and NHI programmes, that means the weakest point is often the handoff between identity systems rather than the credential itself.

AI agents are now being deployed in production at scale, so the problem is moving from edge case to operating model. The article positions protocol fragmentation as the structural reason AI agent identity now behaves differently from traditional workload identity.

Key questions

Q: What breaks when AI agents use several identity protocols in one task?

A: What breaks is the assumption that one identity control plane can describe the whole access path. The agent may authenticate through different systems with different token formats, lifecycles and trust models, so gaps appear at the boundaries. Teams need governance that tracks the chain, not just each credential in isolation.

Q: Why do AI agents increase access risk compared with fixed workloads?

A: Because an agent can assemble its access path at runtime, the true blast radius is not always known at provisioning time. That makes standing credentials more dangerous, since a single reusable secret can unlock a chain of tool calls, APIs, and data sources that was never intended as a static workflow.

Q: How can teams tell whether AI access is actually under control?

A: Look for evidence that access is limited by purpose, not just by account. If you can show which data the system can reach, which actions it can trigger, and how policy changes when the use case changes, you have real governance. If you only have sign-off at deployment time, control is still mostly theoretical.

Q: When should organisations move from secrets management to unified workload identity for AI agents?

A: They should move when agents need to authenticate across more than one protocol in the same task, or when different teams own different pieces of the credential stack. At that point, separate tools stop seeing the full risk. Unified workload identity becomes the only way to govern the complete access chain.

Technical breakdown

Why multi-protocol agent identity is structurally different

A traditional workload usually authenticates through one dominant path. An AI agent can cross several in a single execution, for example an LLM provider via API key, an enterprise app via OAuth, a cloud service via managed identity and a tool server via MCP token. Each of those mechanisms has different token formats, validation expectations and revocation behaviour. That means there is no single credential lifecycle to govern, only a chain of partially overlapping lifecycles. Once the agent switches context mid-task, security teams lose the assumption that one identity system can describe the full transaction.

Practical implication: Model AI agent access as a chained identity flow, not a single login event.

Why static SDK credentials create long-lived exposure

The article shows that several AI SDKs require credentials at client initialisation and keep them in memory for the session. That design turns what looks like a short-lived interaction into a persistent secret exposure window. Even if a secrets manager stores the original value safely, the agent still holds the credential while it runs, and that value may exist alongside other tokens for downstream systems. The result is not just secret storage risk, but runtime secret persistence across multiple trust domains.

Practical implication: Treat SDK initialisation as a credential exposure point, not a neutral implementation detail.

How protocol transitions create attack surface

The most distinctive risk is not one bad token type, but substitution and delegation across protocol boundaries. An attacker who gains one credential may try to reuse it in another protocol, while agent-to-agent delegation can spread identity across multiple providers and audits. If the agent is also able to request more access mid-task, scope can expand without a human checkpoint. The control failure is fragmented visibility, because no single system reconstructs the full path from one trust boundary to the next.

Practical implication: Correlate token use, delegation and privilege changes across protocols before you rely on audit logs.

Threat narrative

Attacker objective: The attacker aims to move through protocol boundaries, reuse valid tokens across systems and gain broader access than any single identity control intended.

1. Entry occurs when an AI agent starts a task with multiple active credentials, such as an LLM API key, an OAuth token and a managed identity session. Those credentials are valid in different systems but exist in the same runtime.
2. Escalation happens when the agent moves from one protocol to another and expands its effective access across trust boundaries, or when it requests more privilege mid-execution without a human checkpoint.
3. Impact follows when a compromised credential or delegated subtask is reused across systems, allowing access paths to spread beyond the scope any single control plane can see.

Breaches seen in the wild

• Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Protocol fragmentation is the real AI agent identity gap: The article shows that one agent can span LLM APIs, SaaS APIs, cloud identities and MCP tools in a single task. That is not a simple secrets problem, because each protocol has different validation rules and revocation semantics. The implication is that identity governance for agents must follow the trust boundary chain, not the credential inventory alone.

Static SDK credential patterns turn runtime access into persistent exposure: The article describes SDKs that keep API keys alive for the session lifetime, which extends the attack window beyond the actual business action. This is not just a storage issue, because the credential becomes part of the agent’s execution state. Practitioners should read this as a runtime governance failure, not merely a secrets hygiene problem.

Access review alone cannot describe agentic access paths: Traditional review processes assume a stable set of entitlements that can be observed and certified over time. That assumption weakens when an agent acquires different tokens for different protocols during one task and may release them before a review cycle ever sees them. The implication is that governance has to move closer to issuance and delegation events.

Unified workload identity is now a control-plane requirement, not a convenience: The article makes clear that separate tools for secrets, OAuth and cloud identity leave blind spots between protocols. A named concept here is cross-protocol identity drift: the access path changes shape as the agent crosses trust boundaries, but the governance model does not track the shift. Practitioners need a single identity view that can follow the workload through every authentication method.

Agent-to-agent delegation creates accountability gaps that classic IAM does not resolve: When one authenticated agent delegates to another, the identity chain can span several providers and authentication methods at once. That breaks the assumption that one audit trail or one owner can explain the access path end to end. The field should treat delegation chains as first-class identity objects, not side effects.

From our research library:

• Only 44% of organisations are currently using a dedicated secrets management system, according to the 2024 State of Secrets Management Survey.
• 54% of organisations are dissatisfied with their current secrets management solution because not all secrets are secured, and 43% cite lack of central management, according to the 2024 State of Secrets Management Survey.
• Read next: Agentic AI Identity Guide

What this signals

Cross-protocol identity drift: AI agents do not just expand the number of credentials in play. They change the shape of identity governance by moving across trust boundaries that no single secrets manager, OAuth provider or cloud identity system can fully see.

Identity programmes that still assume one protocol per workload will miss the highest-risk part of the agent path, which is the transition between systems. The practical question is no longer whether the agent can authenticate, but whether every hop is visible, scoped and reversible.

AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026. That gap reinforces the need to govern the whole execution chain, not just the model endpoint.

For practitioners

• Map every AI agent to a protocol-by-protocol credential inventory Document which credentials the agent uses for LLMs, enterprise APIs, cloud services and MCP tools, then identify where each credential is issued, validated and revoked. The goal is to expose the handoff points where one control stops and another begins.
• Replace persistent SDK secrets with per-task issuance Move away from API keys and tokens that live for the full session and issue credentials only for the task that requires them. Tie expiry to the specific operation so the agent cannot carry broad access across unrelated calls.
• Correlate delegation chains across identity providers Preserve a common correlation ID across LLM, SaaS, cloud and tool-server authentication events so you can reconstruct who acted, through which token type, and under which policy. Without that linkage, agent-to-agent delegation becomes an audit blind spot.
• Harden scope at initialization and mid-task elevation Review where agents receive broad access at startup and where they can later request more privilege without human approval. Tighten both points, because the article’s core risk is access growth across protocols rather than within one system.

Key takeaways

• AI agent identity is a cross-protocol governance problem, not a single-credential problem.
• The most dangerous gaps appear when agents move between LLMs, SaaS APIs, cloud services and tool servers during one task.
• Unified workload identity and task-scoped issuance matter because access can otherwise expand faster than traditional review cycles can see.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.