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

At a glance

What this is: This is an independent analysis of why AI agent identity breaks traditional workload assumptions, with multi-protocol authentication emerging as the key finding.

Why it matters: It matters because IAM, PAM, and NHI programmes must govern one actor across several credential types, trust domains, and audit paths instead of treating each protocol in isolation.

By the numbers:

• Growing at a CAGR of roughly 46% and increasingly deployed across production environments, AI agents create authentication gaps that no single-protocol security solution can close.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.

👉 Read Aembit's analysis of AI agent identity across multiple authentication protocols

Context

AI agent identity is different from traditional workload identity because one runtime can hold several credential types at once, each governed by a different protocol and trust boundary. That creates an identity problem that cannot be solved by one secrets tool, one OAuth system, or one cloud-native control.

For identity teams, the challenge is not that agents use credentials. The challenge is that agents combine API keys, OAuth tokens, managed identities, and MCP tokens within the same task, which pushes governance beyond single-protocol assumptions and into cross-boundary control design.

Key questions

Q: How should security teams govern AI agents that use multiple credential types?

A: Security teams should govern the agent as one workload while still treating each credential type as a separate issuance and revocation domain. That means mapping every protocol the agent uses, enforcing least privilege per protocol, and preserving a single audit trail across all hops. The goal is to remove blind spots between controls, not just harden each control in isolation.

Q: Why do AI agents complicate traditional workload identity controls?

A: AI agents complicate workload identity because they can hold several credentials across several trust boundaries in one task. Traditional controls assume one primary identity context, but agents may use API keys, OAuth tokens, managed identities, and tool tokens in sequence or in parallel. That breaks the old model of one control plane seeing the full access story.

Q: What breaks when secrets rotation is the only control for AI agents?

A: Rotation alone breaks because it protects stored secrets but does not govern runtime use, memory residency, or cross-protocol transitions. An agent can still authenticate through another pathway while one secret is rotated, and the operational burden of coordinating multiple providers can push teams back toward broad, static access. Rotation without orchestration leaves the real attack surface intact.

Q: What is the difference between workload identity and protocol-specific credential management?

A: Workload identity authenticates the actor first and then brokers access across systems, while protocol-specific credential management handles one token type at a time. For AI agents, that difference matters because the same task may need multiple tokens with different rules. Without a unifying identity layer, governance becomes fragmented and the audit trail becomes incomplete.

Technical breakdown

Multi-protocol authentication in AI agents

AI agents often authenticate to multiple systems in one execution path. A single task may involve an LLM API key, an OAuth token for a SaaS app, a cloud managed identity, and an MCP bearer token. Each protocol has distinct validation rules, token formats, and permission models, so a control that protects one layer does not automatically govern the others. The practical failure is not merely secret exposure. It is fragmentation, where identity posture becomes impossible to reason about across protocol transitions. That is why traditional workload identity patterns break down once the agent can cross several trust domains in a single session.

Practical implication: map every protocol an agent can touch and treat each boundary as a separate control checkpoint.

Why SDK credential persistence creates standing access

Many AI SDKs require credentials at initialization and keep them alive for the lifetime of the process. That design means the agent begins execution with long-lived secrets already resident in memory, even when the downstream call only needs short-lived access. In practice, this turns runtime authentication into standing exposure. Secrets rotation can help at rest, but it does not eliminate the memory residency problem once the session begins. The risk is amplified when agents need multiple provider connections, because each additional integration adds another persistent token, another validation model, and another chance for overbroad scope.

Practical implication: reduce lifetime and scope of credentials at execution time, not just in the vault.

Delegation chains and audit loss across providers

Agent-to-agent delegation stretches identity accountability across multiple providers and authentication methods. When one agent hands work to another, the resulting chain can cross OpenAI, Claude, Salesforce, and cloud platforms without any single audit plane seeing the full path. That creates a correlation problem as much as an access problem. Even if each hop is individually valid, the total path may exceed what the original reviewer intended. Once delegation becomes multi-provider and protocol-aware, audit evidence fragments and the true effective identity becomes difficult to reconstruct after the fact.

Practical implication: preserve correlation IDs and delegation records across every hop before relying on audit logs.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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 central identity failure mode for AI agents. The article shows that one agent can hold API keys, OAuth tokens, managed identity sessions, and MCP tokens at the same time, each with a different security model. That means the governing problem is not isolated credential weakness but the absence of a unified policy plane across trust boundaries. Practitioners should treat protocol fragmentation as the control gap, not as a side effect of modern architecture.

Standing credential exposure window: The SDK pattern described here was designed for sessions that remain stable long enough to justify persistent credentials. That assumption fails when the actor is an agent because the access stack is assembled dynamically at runtime and can span several trust domains in one task. The implication is that conventional secrets governance no longer matches the tempo of execution, which is why access review and rotation logic need to be rethought around session-by-session behaviour.

AI agent identity is now a workload governance problem, not just an application security problem. The article makes clear that the control gap spans secrets management, OAuth federation, cloud identity, and tool-server authentication at once. OWASP-NHI and Zero Trust Architecture both become relevant because the actor is a non-human workload moving across multiple authorisation schemes. Teams that still assign ownership by protocol will miss the combined risk surface.

Identity accountability collapses when delegation chains cross providers without a single audit spine. The article's account of agent-to-agent delegation shows that the effective identity path can outgrow any one provider's logs. That is a governance problem for IAM, PAM, and IGA alike because certification, revocation, and incident reconstruction all depend on being able to reconstruct who or what acted. Practitioners should treat cross-provider delegation as a first-class governance object.

Named concept: multi-protocol identity confusion. This is the condition where one agent authenticates through several protocols in one task and the security team assumes each control layer sees the whole picture. It does not. The implication is that identity programmes need to govern protocol transitions explicitly, because the attack surface sits in the handoff between controls rather than in any single credential type.

From our research:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
• The next governance question is how teams close protocol gaps before agent fleets turn fragmented identity into routine exposure, as explored in OWASP Agentic Applications Top 10.

What this signals

Multi-protocol identity confusion: AI agent programmes should assume that no single security tool sees the full access story once an agent crosses API-key, OAuth, cloud identity, and tool-server boundaries. That makes correlation design, not just secret storage, a first-order requirement for any serious governance model.

With 24,008 unique secrets exposed in MCP configuration files in 2025, the protocol boundary itself is now a measurable exposure surface, not a theoretical one, according to the State of Secrets Sprawl 2026. Teams should expect governance gaps to widen as more agents stitch together tools at runtime.

The practical signal is whether your IAM programme can reconstruct the full task path after the fact. If it cannot link the agent, the protocol, the token type, and the downstream service, then policy coverage is already fragmenting in ways that incident response will struggle to repair.

For practitioners

• Map every credential type an agent can hold Inventory API keys, OAuth tokens, managed identities, MCP tokens, and any service-specific session material used in one agent workflow. Then document which system owns issuance, scope, rotation, and revocation for each one.
• Replace persistent initialization secrets with per-task issuance Move away from SDK configurations that keep long-lived credentials resident for the whole process. Issue access only when the task requires it and expire it as soon as the task completes.
• Correlate delegation across providers Preserve a shared identifier across LLM calls, SaaS access, cloud access, and tool-server interactions so investigators can reconstruct the full path instead of stitching together partial logs after an incident.
• Test boundary crossings as separate attack paths Red-team the transitions between OAuth, API-key, managed-identity, and MCP access rather than testing each protocol in isolation. The failure is often in the handoff, not the individual control.

Key takeaways

• AI agents create a multi-protocol identity problem because one task can span several authentication methods and trust domains at once.
• The key exposure is not just credential use, but credential persistence and boundary crossing that existing single-protocol controls cannot fully see.
• Identity teams should move toward workload-level governance, per-task access, and cross-provider audit correlation before agent deployments scale further.

Key terms

• Multi-Protocol Identity Confusion: A condition where one non-human actor uses several authentication protocols in a single task, but the security programme treats each protocol as if it were independent. The practical risk is that no single control plane sees the full trust chain, so accountability, revocation, and forensic reconstruction all become harder.
• Protocol Fragmentation: The split that happens when one workload is governed by separate tools for API keys, OAuth, cloud identity, and tool access. Each tool may work correctly on its own, but the gaps between them remain unmanaged. For AI agents, those gaps are where scope creep, token substitution, and audit loss appear.
• Per-Task Authorization: A short-lived access model in which the credential is issued for a specific operation rather than for the lifetime of the process. For AI agents, this matters because execution is dynamic and multi-system. The design goal is to reduce standing exposure and keep the access decision tied to the actual task.
• Delegation Chain: The sequence of identities and services involved when one agent hands work to another or calls multiple downstream systems. In AI environments, delegation chains can cross providers and protocols, which means audit and governance must capture the entire path, not just the first authenticated hop.

Deepen your knowledge

AI agent identity across multiple protocols is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are designing controls for agents that span LLMs, SaaS APIs, and cloud services, it is worth exploring.

This post draws on content published by Aembit: AI agent identity gaps across APIs, cloud, and LLMs. Read the original.