The Identity-and-Auth Infrastructure for Agents: Who Is Your Agent, and What Is It Allowed to Do?

Table of Contents

• Why Agent Identity Is a Different Problem
• The Three Questions Every Auth System Must Answer
• Non-Human Identity: The Missing Primitive
• Delegation and On-Behalf-Of: The Hard Part
• Credentials That Expire Before They Leak
• Authorization at Action Time, Not Login Time
• Where This Sits in the GaaS Stack
• Building vs. Buying the Identity Layer
• Insights Most People Overlook
• Frequently Asked Questions
• Conclusion
• References

Why Agent Identity Is a Different Problem

For thirty years, identity infrastructure assumed two kinds of actors: humans who log in, and services that talk to other services with a static credential. Agents break both molds. An agent is not a human, it has no fingerprint, no phone to receive a one-time code, no intuition that an action smells wrong. But it is also not a traditional service account, because it acts with judgment, takes a different path every run, and frequently does work on behalf of a specific human whose permissions it must inherit.

That last detail is where things get genuinely hard. When a sales agent drafts and sends an email from a rep's account, books a meeting on the rep's calendar, and updates a deal in the CRM, the question "who did that?" has two correct answers at once: the agent, and the rep. Classic auth systems can't express that cleanly. They were built to authenticate one principal, not a chain of them.

The stakes scale with autonomy. A read-only research agent that can only fetch public pages is low-risk no matter how it authenticates. An agent that can move money, modify production infrastructure, or email customers is a different animal, and the moment you sell that agent as a service, you inherit a customer's trust boundary you did not design. This is why identity and auth have moved from a checkbox to a core part of the infrastructure and orchestration layer that GaaS vendors compete on.

The Three Questions Every Auth System Must Answer

Strip away the jargon and any agent auth system has to answer three things, in order, on every meaningful action:

1. Authentication, who is this agent? Not "which API key was presented," but which specific, named, revocable identity is making this request. If your answer is "the prod service account," you have effectively one identity for a fleet, and you've lost the ability to revoke or audit one misbehaving agent without taking down all of them.
2. Delegation, on whose behalf is it acting? The agent rarely acts as itself alone. It usually carries a user's authority. The system must record and enforce that chain, not collapse it.
3. Authorization, is this action allowed, right now? Permission is not a one-time grant at startup. It's a per-action decision that should weigh the action, the target, the context, and the current state of the world.

Most teams nail the first question, hand-wave the second, and skip the third entirely. That's the gap this whole category exists to close.

Non-Human Identity: The Missing Primitive

The industry has settled on a name for the underlying concept: non-human identity (NHI). It covers service accounts, workload identities, API keys, and now agents. The category has exploded, analysts and security vendors now routinely note that non-human identities outnumber human ones in a typical enterprise by a wide margin, often cited in the range of 40-to-1 or higher, and agents are about to make that ratio look quaint.

What makes an agent's NHI distinct is that it needs to be first-class and granular. Concretely:

• Each agent (ideally each instance or each task run) gets its own identity, not a shared key.
• That identity is revocable in isolation, you can kill one agent's access without rotating a secret used by a hundred others.
• It carries metadata about provenance: which template/version produced it, which orchestrator launched it, which human or system owns it.

This connects directly to how teams already think about versioning agents and their tools, an identity that doesn't record which agent version is acting is an audit trail with a hole in it. When something goes wrong at 2 a.m., "agent v3.2.1 acting for user 8842 called the refund API" is a sentence you can act on. "The prod key did something" is not.

The frontier here is workload identity federation, issuing short-lived, cryptographically verifiable identities to workloads without long-lived secrets at all. Standards like SPIFFE/SPIRE pioneered this for microservices, and the same machinery maps cleanly onto agents. Google's guidance on workload identity federation is a good primer on why eliminating static service-account keys matters; the logic only gets stronger when the workload is an autonomous agent that might be tricked into leaking whatever it holds.

Delegation and On-Behalf-Of: The Hard Part

Delegation is where agent auth earns its keep. The dominant pattern borrows from OAuth 2.0, specifically the token exchange and on-behalf-of flows. The shape is: a user authorizes the agent (or the platform the agent runs on) to act for them, with a specific, scoped grant, "you may read my calendar and send email as me, but not touch billing." The agent then receives a token that encodes both its own identity and the delegated user authority, and downstream services can inspect that token to enforce the narrower of the two permission sets.

Two principles separate a safe delegation design from a dangerous one:

Least privilege, expressed as scopes. The grant should be the smallest set of permissions the task needs, not the user's full account. If a scheduling agent only needs calendar write and contact read, that's all the token should carry. The OAuth working group's security best current practice is required reading here; agents amplify every one of the classic OAuth footguns because they operate unattended and at machine speed.

The agent's authority can never exceed the user's. This sounds obvious and is violated constantly. The failure mode is an agent running with a powerful platform credential that ignores the delegating user's actual permissions, so the agent can do things the user themselves never could. The correct design intersects the two: effective permission = (what the agent is allowed) ∩ (what the user is allowed) ∩ (what this task was scoped to).

A subtler problem is multi-hop delegation. When an agent calls another agent, increasingly common as agent-to-agent protocols mature, the original user's authority and the chain of delegations must propagate without silently escalating. Today this is mostly unsolved at the standard level, which is precisely why it shows up repeatedly in discussions of agent-to-agent interoperability and protocol fragmentation. If you're building now, assume you'll have to enforce hop limits and chain validation yourself.

Credentials That Expire Before They Leak

Static, long-lived secrets are the original sin of machine identity, and agents make them far more dangerous. An agent reads untrusted content, web pages, emails, documents, tool outputs, and a sufficiently clever prompt injection can convince it to exfiltrate whatever credential it's holding. The mitigation isn't to make agents un-trickable (you can't, reliably). It's to make the credential worthless by the time it leaks.

That means:

• Short-lived tokens. Minutes, not months. A token that expires in fifteen minutes turns a catastrophic leak into a minor one.
• Just-in-time issuance. Mint the credential when the action is about to happen, scoped to that action, rather than handing the agent a broad key at startup and hoping.
• Audience and resource binding. A token good for one API shouldn't be replayable against another. Binding tokens to their intended audience blunts a whole class of confused-deputy attacks.
• Secrets never in the prompt or the model's context. The model should reason about what to do; a separate, trusted execution layer holds the credential and performs the privileged call. The credential should not be a string the model can read, summarize, or be tricked into emitting.

That last point is the one most teams get wrong because it's inconvenient. It's tempting to drop an API key into the system prompt so the agent can "just call the tool." Don't. Treat the model as a fundamentally untrusted component sitting inside your trust boundary, and keep credentials in the surrounding harness. This is the same instinct that drives good agent sandboxing, assume the reasoning core can be compromised and design so that a compromise is survivable.

Authorization at Action Time, Not Login Time

Authentication asks who. Authorization asks whether this specific thing is allowed. The mistake teams import from web apps is treating authorization as a one-time gate at the start of a session. Agents need continuous, per-action authorization because a single agent run might touch a dozen systems and take consequential actions the user never explicitly previewed.

The mature pattern is a policy decision point sitting between the agent and every privileged tool. Before the agent's intended action executes, the action, verb, target, parameters, context, is checked against policy. Policy engines like Open Policy Agent, and the open authorization models popularized by Google's Zanzibar paper on fine-grained relationship-based access control, give you the vocabulary: roles, relationships, attributes, and conditions evaluated fresh on each call.

What policy lets you express that static scopes can't:

• Value and rate limits. "Refunds under $100 are auto-approved; above that, pause for a human." This is the hook for human-in-the-loop checkpoints, the policy layer decides when to stop and ask.
• Context conditions. "Only during business hours, only for customers in this segment, only if the agent hasn't already done this action twice today."
• Action-specific rules. Read is fine; write needs an extra check; delete is forbidden outright.

Crucially, every decision, allowed or denied, should be logged with full context. That audit trail is not bureaucratic overhead; it's the artifact that makes an autonomous system defensible when a customer, an auditor, or a regulator asks what your agent did and why it was permitted to. For GaaS vendors especially, where you're operating inside someone else's trust boundary, this log is often the actual product moat. It pairs naturally with the broader observability stack for agent infrastructure, but auth decisions deserve their own first-class, tamper-evident record.

Where This Sits in the GaaS Stack

Identity and auth is not a standalone box; it's a cross-cutting concern that touches nearly every layer of an agent platform. It sits beneath the orchestration framework (which decides what the agent does) and above the tool integrations (which do the privileged work). It's the thing an agent gateway consults before routing a call. It's what makes reliable tool integrations safe to expose, because the gateway can enforce who's allowed to call what.

In a well-factored GaaS architecture, identity is a service the rest of the stack calls, not logic smeared across every agent. The orchestrator launches an agent and gets back a scoped identity. The gateway intercepts each tool call and asks the policy engine. The credential broker mints just-in-time tokens. The audit log records it all. Pull these into one coherent layer and you can reason about security; leave them scattered and you can't.

This is also where GaaS economics and security collide. Per-task and per-outcome pricing models assume you can attribute work to a specific agent run, which is impossible without per-run identity. The same infrastructure that secures your agents is what lets you bill for them accurately. Identity isn't just a safety feature; it's a prerequisite for the business model.

Building vs. Buying the Identity Layer

A wave of startups now sells "identity for AI agents" as a category, and the established identity providers, Okta, Microsoft Entra, and others, are racing to extend their platforms to non-human and agent identities. The buy-vs-build calculus mirrors every other infrastructure decision in the agent stack.

Lean toward buying if you're a GaaS vendor whose customers are enterprises. They will ask for SSO integration, fine-grained audit, compliance attestations, and the ability to revoke your agents from their identity provider. Reinventing OAuth flows, token exchange, and policy evaluation correctly is a multi-quarter security project with a long tail of subtle bugs, and getting it wrong is the kind of mistake that ends contracts.

Lean toward building only the thin policy and brokering layer that's specific to your domain, the rules about what your particular agents may do, while leaning on standards (OAuth 2.0, OIDC, token exchange, SPIFFE) and existing providers for the heavy primitives. The line to hold: don't invent new cryptography or new token formats. Do invent the policy vocabulary that captures your domain's risk decisions.

Whatever you choose, design the identity layer first, not last. Retrofitting per-agent identity and per-action authorization onto a system that assumed a shared service account is one of the more painful migrations in this whole space, second only, perhaps, to untangling state management after the fact. It touches every tool integration and every agent path you've already shipped.

Insights Most People Overlook

The model is inside your trust boundary, and that's backwards from every other component. We normally put untrusted things outside the wall and trusted code inside. The LLM is the one component that is both inside the wall and fundamentally manipulable by the untrusted data it reads. Auth design that doesn't internalize this, that lets the model see credentials or make the final authorization call, is building on sand. The fix is architectural: privilege lives in the harness around the model, never in the model's context.

Prompt injection is an authorization problem, not just a prompt problem. Most defenses against prompt injection focus on detecting or filtering malicious inputs, an arms race you will lose often enough to matter. The durable defense is to ensure that even a fully hijacked agent can't do much damage, because its credentials are short-lived, narrowly scoped, and gated by per-action policy. Identity infrastructure is the real prompt-injection mitigation; input filtering is the speed bump.

Per-agent identity is a billing feature before it's a security feature, and that's why it gets funded. Security teams have asked for granular machine identity for years and been deprioritized. What's finally forcing it is that outcome-based GaaS pricing is impossible without attributing actions to specific agent runs. The CFO's spreadsheet, not the CISO's risk register, is what ships per-run identity. Builders who frame this layer as enabling monetization, not just hardening, get resourced faster.

The hardest unsolved problem is multi-hop delegation, and the standards aren't ready. Single-agent, single-user OAuth delegation is reasonably well-trodden. Agent-calls-agent-calls-agent, each carrying and potentially narrowing a user's authority without ever silently escalating, has no settled standard. If your roadmap includes multi-agent collaboration, budget for building chain validation and hop limits yourself, and assume you'll have to redo it when the protocols converge.

"Revocable in isolation" is the test that separates real from theater. A quick way to assess any agent auth setup: ask whether you can revoke exactly one misbehaving agent's access in under a minute without disrupting any other agent. If the answer involves rotating a shared secret or redeploying a fleet, you don't have agent identity, you have a service account with extra steps.

Frequently Asked Questions

How is agent authentication different from service-to-service authentication? Service-to-service auth assumes a static, predictable caller acting as itself. Agents act non-deterministically, frequently on behalf of a specific human whose permissions they inherit, and they process untrusted input that can manipulate them. That combination demands per-agent (ideally per-run) identity, delegated authority, and per-action authorization, none of which a static service credential provides.

Can I just give my agent an API key and call it done? For a low-stakes, read-only internal tool, maybe. For anything that takes consequential actions or runs as a service for customers, no. A static key is a single point of catastrophic failure: it can't be scoped per task, can't be revoked without affecting everything sharing it, and if a prompt injection coaxes the agent into leaking it, the blast radius is your entire integration.

What's the role of OAuth in agent auth? OAuth 2.0 supplies the delegation machinery, authorization grants, scopes, and especially token exchange / on-behalf-of flows, that lets an agent act with a user's authority without holding the user's password. It's the most mature standard available and the right foundation, but it needs to be paired with short-lived tokens and an action-time policy layer to be safe for autonomous agents.

How do short-lived credentials actually help against prompt injection? They don't prevent the injection; they cap the damage. If a hijacked agent leaks a token that expires in fifteen minutes and only works for one narrowly scoped API, the attacker's window and reach are tiny. Combined with per-action authorization, even a fully compromised agent struggles to do anything consequential.

Where should authorization decisions live? In a dedicated policy decision point between the agent and every privileged tool, never inside the model's reasoning. The agent proposes an action; an external, trusted policy engine evaluates it against current rules and context and approves, denies, or escalates to a human. This keeps the manipulable component (the model) out of the decision it could be tricked into making.

Do small teams really need all of this on day one? You need the architecture on day one even if the implementation is minimal. Specifically: a distinct identity per agent, credentials held outside the model's context, and a single chokepoint where authorization happens. Those three choices are cheap early and brutally expensive to retrofit. The fancier policy rules and federation can come later.

Conclusion

Identity and auth is the layer that decides whether autonomous agents are an asset or a liability. The core discipline is small and stubborn: give every agent its own revocable identity, let it act on a user's behalf only through scoped delegated grants, hold credentials outside the model and make them short-lived, and authorize every consequential action at the moment it happens, logging the decision either way. Get those right and an agent that gets hijacked is an incident, not a catastrophe.

Within the broader GaaS infrastructure picture, this layer is unusual because it serves two masters at once: it's the safety system that keeps autonomous agents inside their trust boundary, and it's the attribution system that makes per-task and per-outcome pricing possible at all. That dual role is why it's moving from afterthought to foundation. Build it first, lean on proven standards and providers for the primitives, and reserve your own engineering for the domain-specific policy that captures what your agents are actually allowed to do. As multi-agent systems and agent-to-agent protocols mature, the identity layer is where the next round of hard, unsolved problems will be fought, and where the GaaS vendors who took it seriously early will have a durable advantage.

References

• OAuth 2.0 Security Best Current Practice (RFC 9700)
• Google Cloud: Workload Identity Federation
• Zanzibar: Google's Consistent, Global Authorization System