Agent Identity and Authentication in Distributed Systems

When you hand AI agents the same login-and-session model built for people, agent identity and authentication in distributed systems fails. Agents operate across trust boundaries at machine speed and carry inherited credentials that were never designed to be revoked mid-task, and this mismatch causes nearly every vulnerability now appearing in production deployments. You need per-component identity, credentials that expire fast, and delegation chains you can verify cryptographically. The standards to do this are assembling in real time, and so are the gaps.

Why agents break the identity model built for humans

An agent is not one thing: it is an orchestrator that plans the work, a reasoning engine that decides what to do next, a set of tool connectors that reach into other systems, and a runtime environment that actually executes the steps. Each of those pieces can sit in its own trust domain, run on its own infrastructure, and talk to different downstream services. The tidy phrase "agent identity" is already doing too much work before anyone has issued a single credential.

Human identity and access management assumes a person logs in, holds a session for a while, and logs out. Nothing about an agent works that way, and bolting agents onto a model built for human sessions is the root cause of the vulnerabilities that follow. Agentic identity has to do something human IAM and static service accounts were never asked to do simultaneously: establish which agent is acting right now, and which user or upstream process asked it to act in the first place. If you miss either half, an auditor, or an attacker, can't tell who is responsible for what just happened.

The modular structure of agents turns a single identity question into a distributed one. The problem doesn't stay contained to one tidy corner of the data center. Architectural sprawl of that kind means an agent's identity surface is negotiated fresh, environment by environment, every time the agent moves.

Inherited credentials and static secrets turn agents into a blast-radius problem

The dominant failure mode in agent security is not some novel exploit.

Static, hardcoded secrets get embedded in agent components, so they tend to carry far more access than the task needs, and once baked into a deployed component they're hard to rotate. Revoking one compromised credential means tracing every agent it touched, and by the time that tracing finishes, the damage is usually done.

In the 2025 incident, attackers stole OAuth tokens from the Drift–Salesforce integration, and that got them unauthorized access to customer Salesforce environments across multiple organizations. The network didn't see an attack. It saw a request from a legitimate account carrying valid credentials, and it had no way to distinguish the real integration from an attacker holding the same token. The fix the field keeps landing on is per-component authentication, treating the orchestrator, the reasoning engine, and each tool connector as its own identity-bearing workload with short-lived, scoped credentials rather than one shared secret passed around like a house key. Over-permissioning is structural: agents inherit human-scale access because most enterprise environments still have no provisioning path that grants anything narrower.

The governance gap between agent deployment and agent security

Enterprise adoption of agents has sprinted well ahead of the controls that would make that adoption safe, and nothing about the current trajectory suggests the gap closes by itself.

The rise of so-called digital workers, agents that write code, execute transactions, and touch sensitive systems directly, has outpaced the identity and security models meant to govern them, and that was a consensus view across RSAC 2026, not a fringe complaint. The identity piece of that gap is specific and measurable in kind if not always in exact figure: only a small minority of teams treat their AI agents as independent, identity-bearing entities in their own right, while most still lean on shared API keys for agent-to-agent authentication. Shared keys are the same static-secret pattern the credential section just flagged as dangerous, so the governance failure and the technical failure are just one failure wearing two labels.

When an agent can spawn and task other agents, a capability a meaningful share of deployed agents already have, the chain of command becomes unauditable under a shared-credential scheme, because nobody can say with confidence which spawned agent did what under whose authority. The blocker is governance, security, and auditability, the exact gaps this section has been describing, since most enterprise AI agent pilots have not reached production at scale. Enterprises are stuck in pilot purgatory because nobody can yet prove, to a compliance officer's satisfaction, who authorized what.

Agent identity requirements: per-component identity, dynamic secrets, and delegation chains

Solving this is not a matter of stretching existing human IAM a little further. It requires a model built from scratch around four principles: per-component identity, short-lived credentials, explicit delegation, and full causal-chain observability. Treat these as requirements a real solution has to clear. What the standards stack and the platform implementations later in this piece actually deliver against each one is a separate question.

Full causal-chain observability asks for more than what traditional IAM produces. Traditional access logs tell a story about who logged in and when. You need action logs that show which component acted, under which delegation, against which resource. Without that level of detail, least-privilege enforcement is just a policy on paper, and compliance audits turn into an exercise in hoping nobody asks a hard question.

Explicit delegation chains close out the list, and they are the hardest requirement to satisfy cleanly. When an agent acts on a user's behalf, that fact has to be recorded cryptographically in a form downstream services can verify. The Delegation Token carries cryptographic references to both the user and agent tokens, building a chain downstream services can actually check rather than take on faith. That requirement, proving not just that an agent acted but that it acted on someone's actual authority, is where the standards stack covered next starts to show its seams.

The standards stack assembling beneath agent authentication

The emerging consensus in this space maps three already battle-tested standards onto a stack built specifically for how agents behave, and that composability is both the stack's biggest strength and the source of the gaps that remain.

SPIFFE handles workload identity. It issues each workload a SPIFFE Verifiable Identity Document, either an X.509 certificate for mTLS or a JWT, derived from cryptographic attestation of the node and the workload itself, with no pre-shared secret required. That last part matters enormously given everything said earlier about static secrets: SPIFFE's entire design assumes the secret-in-a-config-file pattern is the enemy. The approach isn't theoretical. Uber processes billions of SPIFFE attestations daily, and Block, formerly Square, runs SPIFFE alongside WIMSE and OAuth together in production, which is about as strong a signal as exists that the stack holds up at real scale.

WIMSE covers workload-to-workload authentication, the layer above basic identity. That gives application-level proof of possession for workload-to-workload calls, though none of the WIMSE drafts have reached RFC status yet.

OAuth 2.0 Token Exchange, defined in RFC 8693, handles delegation.

These three pieces are starting to get stitched together formally. The IETF Internet-Draft draft-klrc-aiagent-auth-00, published March 2, 2026 by authors from Defakto Security, AWS, Zscaler, and Ping Identity, describes how WIMSE and the OAuth 2.0 family compose into one coherent agent authentication framework, with the explicit goal of heading off a landscape of incompatible, one-off implementations. Regulators are paying attention at the same time: the National Cybersecurity Center of Excellence published a concept paper on February 5, 2026, and NIST's Center for AI Standards and Innovation followed on February 17, 2026 with its AI Agent Standards Initiative, examining how OAuth 2.0, OpenID Connect, and SPIFFE/SPIRE apply to agent identity and multi-hop delegation.

Standards stack gaps: multi-hop delegation and ephemeral agents

SPIFFE, WIMSE, and OAuth 2.0 together handle authentication and two-party authorization well. But they do not yet solve delegation provenance across multi-hop agent chains, and the highest-risk enterprise workflows run exactly there.

WIMSE's Dual-Identity Credential covers two-party interactions cleanly, one agent talking to one service. Agentic JWT tries to patch this by extending JWTs with agent-specific claims, but JWTs are immutable once signed. A delegatee can't narrow its own authority without minting an entirely new token, and minting a new token breaks the cryptographic chain back to the original grant. That's a real structural limit, and no one will quietly fix it in a point release.

The deeper gap sits on the user-authorization side of the equation. Nothing in production today can give you an on-behalf-of token that records which specific person authorized a given inference call. Anthropic and OpenAI both shipped workload identity federation in 2026, so the short-lived-credential half of the picture exists, but the delegation half, proving a named human actually approved a specific action, remains unbuilt. SPIFFE has its own separate applicability problem, because agents can live for seconds, not hours. SPIRE needs dedicated attestation infrastructure, X.509 certificate issuance takes time that ephemeral agents don't have to spare, and a SPIFFE SVID issued for an MCP tool call has no defined mapping to an A2A agent card. SPIFFE secures identity within infrastructure boundaries, but it doesn't yet offer a cross-protocol identity flow that follows an agent as it hops between frameworks. None of this means the stack is wrong. The stack is necessary and still incomplete. That's why the platform vendors and hardware partnerships covered next have started filling the space standards haven't reached.

How hyperscalers and hardware partnerships are productizing agent identity

Through 2026, hyperscalers turned agent identity from a bespoke engineering project every enterprise had to solve alone into a platform feature that raises the baseline for everyone, but coverage still varies, and cross-platform interoperability is far from solved.

Google's Gemini Enterprise Agent Platform, launched April 22, 2026, ships with three named components: Agent Identity, Agent Registry, and Agent Gateway. Every agent gets a unique cryptographic ID mapped to auditable authorization policies and indexed in a central registry. That enables a distinction simple enough to say in one sentence but hard enough to build that most organizations haven't managed it on their own: the gap between an agent that can read everything in a system, and an agent that can read only what the specific person it's acting for is allowed to read. Comcast rebuilt its Xfinity Assistant on the platform's Agent Development Kit, and PayPal runs agent-based payments on it in production, so real transactional weight now backs the architecture, and it isn't just a demo.

IBM, Auth0, and Yubico took a different angle at RSAC 2026, building for the highest-stakes actions rather than the broadest coverage. The combination pairs IBM WatsonX AI orchestration with Auth0 identity flows built on the CIBA standard and Yubico YubiKey hardware authentication, producing a verifiable chain of accountability for agent actions that carry real consequences. The mechanics are straightforward: IBM's agents propose an action, Auth0 triggers a secure out-of-band approval request, and a YubiKey tap gives cryptographic proof that a specific human physically signed off on the decision. So where the standards stack can't yet produce a cryptographic audit trail of human authorization, a physical key tap can do it.

Google's Agent2Agent protocol fills the interoperability gap between the two. It has reached version 1.0, is now governed by the Linux Foundation's Agentic AI Foundation, and it uses signed agent cards with cryptographic signatures for domain verification. It's already in production across a large number of organizations, routing real tasks between agents built on entirely different platforms, and that matters because if identity only works within one vendor's walls, it isn't identity for a multi-agent world, just a demo with good production values.

Why runtime monitoring and

Every standard and every platform covered so far answers a question about the moment an agent requests access: is this component who it claims to be, does it carry a valid delegation, is the credential still inside its lifetime. None of that tells a security team what the agent actually did once access was granted, which is a different question and arguably the more dangerous one to leave unanswered. A credential can be perfectly issued, properly scoped, and still get used to do something nobody intended, because the authorization layer checks identity at the door and has nothing to say about behavior once the agent is inside.

Runtime monitoring has to be treated as a peer requirement alongside identity, built in from the start rather than added once identity is handled. Action logs that capture which component acted, under which delegation, against which resource, the observability requirement laid out earlier in this piece, only produce value if something is actually watching them while the agent runs, not just archiving them for a quarterly audit nobody reads in real time. The standards stack and the platform products covered above build the front door only. What happens after an agent walks through it, whether it stays inside the bounds of the delegation it was granted or quietly wanders past them, is the part of this problem the industry has barely started to build for, and it's where the next round of incidents, and the next round of standards, will almost certainly come from.