Identity for Agents: How Do You Actually Authenticate a Non-Human Actor?

Table of Contents

• Why Agent Identity Is Its Own Problem
• The Three Questions Every Auth System Must Answer
• What We're Borrowing From Machine Identity
• Delegation: The Part That's Genuinely New
• Credentials an Agent Can Actually Hold
• How GaaS Vendors Are Implementing This Today
• Common Mistakes That Turn Identity Into a Liability
• Insights Most People Overlook
• Frequently Asked Questions
• Conclusion
• References

Why Agent Identity Is Its Own Problem

For thirty years, identity systems sorted the world into two clean piles. Humans logged in with passwords and, eventually, a second factor. Machines, servers, scripts, cron jobs, got service accounts and API keys. The two categories rarely blurred, and when they did, security teams treated it as a bug to be fixed.

Agentic AI breaks the sorting hat. An agent is a piece of software, so your instinct says "machine identity, done." But a machine identity has never been able to read an email, decide the sender deserves a refund, and call the payments API to issue one. That's a human-shaped decision flowing through a machine-shaped credential. The agent occupies a genuinely new slot: a non-human actor that exercises judgment. Andreessen Horowitz has called identity and authorization the missing infrastructure layer for AI agents, and the gap they're pointing at is exactly this one, our identity stack assumes the thing holding a credential either follows fixed instructions or is a person we can hold accountable. An agent is neither.

The stakes are higher than they look. A service account that gets compromised does whatever its script was always going to do, just for an attacker. An agent that gets compromised, or simply prompt-injected, which is the same outcome without the breach, can be reasoned into misusing every permission it holds. That makes the identity question inseparable from the new enterprise attack surface that agent credentials create. You're not just authenticating code. You're authenticating a decision-maker you can socially engineer.

The Three Questions Every Auth System Must Answer

Strip away the protocols and agent authentication reduces to three questions that must be answered on every single call. Most failed designs answer one or two and assume the third.

Who is this agent? Authentication in the narrow sense. The "refund-processing-agent" instance making this request is the one we registered, not an impostor or a stale clone. This is the part traditional machine identity already solves well.

On whose behalf is it acting? Delegation. The agent is rarely the principal. It's acting for a specific customer, a specific employee, or a specific tenant. A refund agent processing Alice's order must carry Alice's context, not a blanket "can refund anyone" grant. Skip this and every agent becomes a confused deputy by design, which is exactly the failure mode explored in the confused-deputy problem for tool-using agents.

Is this specific action allowed right now? Authorization, evaluated per-action rather than per-session. The same agent that may read order history should not necessarily issue a $4,000 refund without a human in the loop. Authority isn't a property of the agent; it's a property of the agent plus the action plus the context.

The reason these three keep getting conflated is that for human users we usually collapse them. You log in (who), the session implies you're acting for yourself (on whose behalf), and your role grants a fixed set of permissions (what). For agents you have to pull them back apart, because the answers diverge constantly. This separation is the conceptual core of least-privilege design with scoped permissions, and identity is where it starts.

What We're Borrowing From Machine Identity

The good news is we are not inventing cryptography from scratch. The machine-identity world spent the last decade building exactly the primitives agents need, mostly for microservices and cloud workloads. Three are worth knowing by name.

OAuth 2.0 client credentials and token exchange. OAuth already models a software client obtaining a token to call an API. The client-credentials grant gives an agent its own identity; the more interesting piece is RFC 8693 token exchange, which lets a service swap one token for another that carries delegated authority. That's the mechanism by which an agent can present "I am refund-agent acting for Alice" as a verifiable token rather than a claim it just asserts. The IETF token-exchange specification was written for service-to-service delegation, and it maps onto agents almost without modification.

mTLS and short-lived certificates. Mutual TLS proves both ends of a connection cryptographically. Pair it with certificates that live for minutes instead of years and a stolen credential is worth little by the time anyone exfiltrates it. Short lifetimes are the single highest-leverage control in agent identity, because the threat model assumes the agent's runtime is exposed to untrusted input.

SPIFFE/SPIRE for workload identity. SPIFFE, a CNCF project, issues cryptographically verifiable identities to workloads without baked-in secrets, deriving identity from attested runtime properties instead. For agents running as containers or functions, SPIFFE gives each instance a verifiable name (a SPIFFE ID) the moment it starts, with no API key to leak. It answers "who is this agent" robustly.

What none of these solve on their own is the judgment layer. They authenticate the workload beautifully and say nothing about whether the workload should have reasoned its way into the action it's attempting. That's why borrowing the primitives is necessary but not sufficient.

Delegation: The Part That's Genuinely New

If you only remember one idea from this piece, make it this: an agent's authority is borrowed, and the chain of borrowing has to travel with every request.

Consider a realistic chain. A customer asks a top-level "concierge" agent to book travel. The concierge delegates flight search to a specialized travel agent, which calls a booking tool, which charges a card on file. By the time money moves, the action is four hops from the human who authorized it. If each hop just re-authenticates as itself, the booking API sees a trusted travel agent and approves a charge, with no cryptographic evidence that a real customer ever asked for it. That's how you get a charge nobody authorized and no way to prove who did.

Proper delegation threads the original principal's consent through the whole chain. Each hop produces a token that says, in effect, "I am agent B, I received authority from agent A, who received it from customer Alice, scoped to book one flight under $800." The scope narrows at each step; it can never widen. This is the agent-world version of OAuth's on-behalf-of flow, and it's the only way to keep chain-of-custody intact across a multi-agent workflow. When something goes wrong, you can replay the chain and point to the exact link that exceeded its grant.

The hard engineering question is propagation. HTTP headers, message-queue metadata, and tool-call envelopes all need a consistent place to carry delegation tokens, and every component must refuse to act on a request that arrives without one. Emerging conventions around the Model Context Protocol are starting to standardize where this context lives, though, as the broader cluster discusses, MCP's security model still has known weaknesses around exactly this kind of authority propagation.

Credentials an Agent Can Actually Hold

A credential is only as safe as the agent's ability to keep it secret, and agents are bad at keeping secrets, because their whole job is to process untrusted text that may try to extract those secrets. That reframes the credential question. You're not choosing the strongest credential; you're choosing the one that does the least damage when the model is manipulated into revealing it.

Avoid: long-lived API keys in the prompt or environment. A static key the agent can read is a key a prompt injection can read. If the agent can see it, treat it as already leaked. This is the default that ships in too many quickstart tutorials and the first thing to rip out before production.

Better: short-lived tokens fetched per-task from a broker. The agent never holds a durable secret. It authenticates to a token broker using a workload identity it can't exfiltrate (an attested SPIFFE identity, a cloud instance role), and the broker hands back a narrowly scoped token good for one task and a few minutes. Even a successful injection captures something nearly worthless.

Best for sensitive actions: keep the credential out of the agent entirely. Put a policy-enforcing proxy between the agent and the real API. The agent says "issue a refund for order 1234"; the proxy holds the actual payment credential, checks the delegation chain and policy, and either executes or refuses. The agent's reasoning never touches the secret. This pattern connects directly to securing the agent's tools rather than just the agent, the tool boundary becomes your enforcement point, and the agent is treated as permanently semi-trusted.

The throughline: design as if the agent's memory and context will eventually be read by an adversary, because for any internet-facing agent processing user input, that's not paranoia. It's a Tuesday.

How GaaS Vendors Are Implementing This Today

In the agent-as-a-service market, identity is quietly becoming a buying criterion, and a few patterns have settled out across vendors.

Most serious platforms now register each deployed agent as a first-class identity in the customer's IdP or in a dedicated non-human-identity directory, rather than reusing a shared service account. That gives the buyer something to audit, rotate, and revoke per-agent. Vendors increasingly support customer-managed credentials, the buyer's secrets live in the buyer's vault, and the agent fetches them at runtime through a broker, so the GaaS provider never holds the customer's keys. Per-action authorization is moving from "nice to have" to table stakes for anything that touches money or regulated data, usually implemented as an external policy engine the customer can inspect.

The maturity gap between vendors is wide, and it's the easiest thing to probe in a security review. Ask a prospective GaaS provider three questions: does each agent instance get a unique, revocable identity; can you show the delegation chain for a given action after the fact; and where does the credential physically live when the agent calls our systems? Strong answers correlate tightly with the broader controls a security questionnaire for buying agents should surface. Weak or hand-wavy answers usually mean a shared key and a shrug, which is a finding in itself.

Common Mistakes That Turn Identity Into a Liability

A few failure patterns show up so reliably they're worth calling out directly.

The god-mode agent. Granting one agent broad permissions "so it can handle anything" is the most common and most expensive mistake. It maximizes blast radius and guarantees that a single prompt injection compromises everything the agent can reach. Scope down to the actual task, every time.

Reusing a human's identity. Letting the agent log in as the employee it works for is tempting because the permissions are already set up. But now you've lost the ability to tell human actions from agent actions in your logs, which destroys the audit trail regulators will demand from GaaS vendors and makes incident forensics nearly impossible. Agents need their own identities, distinct from any human's.

Trusting the network instead of the request. "It came from inside our VPC, so it's fine" assumes the agent's environment is trustworthy. It isn't, the agent ingests untrusted text all day. Authenticate and authorize every request on its own merits regardless of where it originated.

Forgetting revocation. Agents get retired, forked, and redeployed constantly. If your identity system makes it hard to kill a specific agent's credentials instantly, you have no real kill switch when one misbehaves. Revocation should be one action, and it should take effect in seconds.

Insights Most People Overlook

Identity and authorization are the same problem for agents, even though we teach them as separate. For humans, authenticate-then-authorize works because a person's authority is stable across a session. An agent's authority changes from action to action depending on whose behalf it's acting and what it's reasoning toward. The moment you accept that, you stop building login systems and start building per-action decision systems, and most of the painful retrofits in this space come from teams that designed the former and needed the latter.

The agent should hold the weakest credential that still works, on purpose. Counterintuitively, you do not want to give your agent strong, durable credentials. You want to give it the most disposable, narrowest, shortest-lived thing that gets the job done, and push real authority into proxies and brokers the agent can't read. Strength of credential is a liability when the holder can be talked into handing it over.

Non-human identities already outnumber human ones, and agents are about to make the ratio absurd. Most enterprises already run dozens of machine identities for every human identity, and that count predates agents entirely. A workforce that spins up task-scoped agents on demand could push it into the hundreds. Identity governance that depends on humans manually reviewing accounts simply does not survive that volume, the review itself has to be automated, which is its own emerging sub-discipline.

"Authenticate the agent" is the wrong framing; authenticate the delegation. The interesting security property is almost never "is this really refund-agent." It's "did a real principal actually authorize this specific action, and can I prove the chain." A system that nails agent authentication but treats delegation as an afterthought will pass a naive audit and fail the first real incident, because the question an investigator asks is never "which binary ran", it's "who told it to."

Short credential lifetimes do more for you than stronger cryptography. Teams agonize over algorithm choices while issuing tokens that live for hours. For agents, time-to-live is the dominant variable. A weaker token that expires in ninety seconds beats a stronger one that lives all day, because the entire threat model assumes the credential will leak, the only question is how long it's useful afterward.

Frequently Asked Questions

Can't I just give my agent an API key like any other integration? You can, and for a low-stakes read-only agent it might be fine. The moment the agent touches money, personal data, or anything irreversible, a static key becomes the weakest link, because the agent processes untrusted input that can extract it. Move to short-lived, task-scoped tokens fetched from a broker, and keep the most sensitive credentials behind a proxy the agent never sees.

How is agent identity different from the service accounts we already use? Service accounts run fixed code with stable permissions. Agents exercise judgment and act on behalf of shifting principals, so their effective authority changes per action. You need delegation (whose behalf) and per-action authorization layered on top of the basic "which workload is this" that service accounts already provide.

What does delegation actually look like in a request? A token, typically a JWT obtained via OAuth token exchange, that encodes the original principal, the chain of agents that handled the request, and a scope that narrows at each hop. Every downstream service validates the token and refuses to act if the requested action exceeds the carried scope.

Do I need SPIFFE, or is OAuth enough? They solve different layers. SPIFFE answers "which workload is this" without baked-in secrets and shines for containerized agents. OAuth (especially token exchange) handles delegated authority. Many production setups use SPIFFE for the agent's base identity and OAuth tokens for per-task, on-behalf-of authority. Pick based on which gap is more painful, and expect to use both as you mature.

How do I authenticate one agent to another in a multi-agent workflow? Each agent authenticates with its own workload identity (mTLS or a SPIFFE-backed token), and the delegation token from the originating principal travels alongside. Agent-to-agent auth without propagated delegation is how you get a confused deputy, so never let an internal agent act on a peer's say-so alone, it must carry evidence of the original human authorization.

Where should the agent's secrets actually live? Not in the prompt, not in plain environment variables the agent can read. Use a secrets manager or token broker the agent reaches via an identity it can't exfiltrate, and for the highest-stakes credentials, keep them entirely outside the agent behind a policy-enforcing proxy.

Conclusion

Authenticating a non-human actor is less about inventing new cryptography and more about accepting that an agent is a new kind of principal, a decision-maker whose authority is always borrowed. The mechanics come from machine identity we already trust: OAuth client credentials and token exchange, mTLS, SPIFFE workload identities, short lifetimes. What's genuinely new is delegation, the requirement to thread a real principal's consent through every hop of a multi-agent workflow and to evaluate authorization per action rather than per session.

The practical posture follows from one assumption: the agent's context will eventually be read by an adversary, whether through breach or prompt injection. Design from there. Give the agent the weakest credential that works, keep real authority in proxies and brokers it can't read, make every credential short-lived and instantly revocable, and never let an action execute without a verifiable answer to who authorized this. Do that and identity stops being your largest liability and becomes the control plane the rest of your agent security, scoped permissions, audit logging, kill switches, and governance, depends on. In the GaaS landscape, the vendors who treat agent identity as a first-class problem are the ones who'll still be standing after the first wave of agent-credential incidents.

References

• a16z, AI Agents Need an Identity and Authorization Layer
• IETF RFC 8693, OAuth 2.0 Token Exchange
• SPIFFE, Secure Production Identity Framework for Everyone (Overview)
• Google Cloud, Why Non-Human Identities Are the Next Security Frontier