5 Identity Patterns Your AI Agents Need Before They Touch Production

Here's a scenario that plays out more often than anyone wants to admit.

A team ships an internal agent to production. Neat little thing. It reads tickets, calls a couple of internal APIs, sends a Slack notification, and marks the ticket resolved. The engineer who deployed it, in the interest of getting something out the door, gave the agent a copy of their own API token. The token has the permissions of a senior engineer, which is to say it can do almost anything.

Three months in, someone crafts a support ticket with embedded instructions. The agent, being an agent, treats those instructions as guidance. The Slack notification it sends goes to the wrong channel. The API call it makes touches production data it shouldn't have touched. And the audit log, when someone finally goes to reconstruct what happened, says the actions were performed by the senior engineer who lent their token six months earlier.

That engineer is going to have a really bad afternoon.

This is not a hypothetical. It's a pattern. And it's happening across the industry right now because most teams shipped agent-shaped software before they thought carefully about identity, and the tooling for doing this right isn't as widely known as it should be. What follows are five identity patterns that any agent in production needs to have in place. None of them are exotic. All of them are borrowed from twenty years of hard-won distributed systems experience, applied to the specific shape of the agent problem. If any one of them is missing, you have an incident waiting to happen.

Pattern 1: Give the Agent Its Own Identity

The single most common failure I see, and the one that causes the most cleanup work when things go wrong, is the borrowed identity problem. Agent runs under an engineer's credentials. Agent runs under a shared service account nobody owns. Agent runs under whatever role the deploying pod happened to inherit. All of these are the same failure dressed up differently, and the failure is that when the agent does something, you can't tell what the agent did versus what a human did.

The fix is unglamorous. Every agent in your production environment gets a distinct machine identity. In cloud terms, that's a service account or a workload identity that belongs specifically to that agent. In identity-provider terms, it's a separate principal that gets audited, rotated, and permissioned in isolation.

The SPIFFE and SPIRE projects have been doing serious work on machine identity in cloud-native environments for years, and their model of workload attestation (the agent proves it is what it claims to be through the environment it runs in) maps cleanly onto the agent case. Cloud providers offer their own versions: AWS IAM Roles for Service Accounts, Azure Workload Identity, GCP Workload Identity Federation. Pick one. The point is not the vendor. The point is that when an audit log entry appears, you can tell whether it came from Sarah, from the payments-agent-v3, or from something impersonating either of them.

Two easy tests to see if you have this pattern right. First, can you list every agent in your environment along with its distinct identity? Second, if you had to revoke one agent's access this afternoon without affecting anything else, could you? If both answers are yes, you're in good shape. If either is no, the borrowed identity problem is somewhere in your stack.

Pattern 2: Scope the Authority the Agent Gets Delegated

Once your agent has its own identity, the next question is what that identity is allowed to do. The lazy answer, which is where most first deployments land, is "everything the deploying team could do." The correct answer is "the narrowest possible set of actions required for the agent to do its specific job, and no more."

This sounds obvious. In practice, it is where most teams collapse, because designing narrow permissions is annoying and shipping is fun. But it's exactly the pattern that turns a small incident into a large one when things go wrong.

The relevant technical primitives here come from the OAuth 2.0 family, and they've matured a lot in the last two years specifically because of agent use cases. The OAuth 2.0 Token Exchange spec lets you swap a broadly-scoped token for a narrowly-scoped one before the agent uses it. OAuth 2.0 DPoP (Demonstrating Proof of Possession) binds tokens to specific clients so a stolen token can't be replayed elsewhere. The OAuth 2.1 draft consolidates these into a modern default.

For agent workloads specifically, the pattern that works is: the agent gets its identity from your identity provider, exchanges it for a scoped downstream token before each action, and that downstream token can only do the specific thing the agent needs to do right now. The tokens are typed. The scopes are named. And the blast radius of any single compromised token is one action, not the entire agent's job.

The uncomfortable question this pattern forces you to answer is exactly what actions your agent needs to take. Most teams have never enumerated this precisely. Doing so is uncomfortable and clarifying, in that order.

Pattern 3: Never Give the Agent Long-Lived Credentials

Long-lived credentials are the single most reliable source of production incidents in cloud environments, and they're worse for agents than they are for humans because agents don't rotate their tokens the way humans rotate their laptops.

The pattern is credentials that live for minutes, not months. Get them just before you need them. Discard them immediately after. Never persist them anywhere the agent's memory extends beyond a single request cycle.

The tooling for this exists and is production-mature. HashiCorp Vault has been doing dynamic secrets and short-lived tokens for years. Cloud provider IAM offers just-in-time credential issuance through workload identity federation. Kubernetes gives you projected service account tokens with configurable lifetimes measured in minutes. The AWS Signing Version 4 family, when paired with STS-issued session credentials, gives you the same shape.

The mental model shift that matters is that credentials become a request-scoped resource, not an agent-scoped one. When the agent starts a task, it acquires the credentials it needs. When the task ends, those credentials expire whether you remember to revoke them or not. If the agent's environment gets compromised, the attacker gets whatever credentials happened to be resident in memory at that instant. Which is almost nothing.

The specific failure mode this prevents is the one that keeps security teams up at night: a stolen credential file, a compromised container image with baked-in secrets, an agent that got prompt-injected into leaking its own environment variables. All of those attacks become dramatically less useful when the credentials the attacker steals expire in three minutes.

Pattern 4: Authorize Per-Tool, Not Per-Agent

The moment agents started calling tools, and especially since MCP became a standard for exposing tools to agents, the granularity of authorization became a live problem. The way most first-generation agent frameworks handle this is: the agent has an API key or an OAuth token, and any tool the agent can invoke uses that same credential. Blanket authorization. If the agent has permission for anything, it has permission for everything.

The pattern that works is per-tool authorization boundaries. Each tool the agent can invoke has its own scoped credential, tied to that specific tool and no others. When the agent invokes tool A, the credential presented has authority for tool A only. When it invokes tool B, a different credential presents authority for tool B only. Compromise of one tool's credential does not cascade to the others.

This maps cleanly onto MCP's tool schema model, where each tool is a named function with a specific parameter shape. The agent's authorization to invoke each function should be independently governed. In OAuth terms, each MCP tool becomes a resource with its own scope. In enterprise-security terms, each tool becomes an object in your authorization policy, and the agent is a subject that has been granted specific access to specific objects.

The additional discipline this pattern enforces is that when you introduce a new tool to an agent, you have to make an explicit decision about whether the agent should be authorized to invoke it. That decision goes through your normal access-control review. It doesn't just inherit from whatever the agent already had access to. Which is annoying, and correct.

The tools with write access, network egress, or access to sensitive data deserve especially close review. Those are the tools where a prompt-injected agent does the most damage. Treating each of them as a distinct authorization decision is the difference between a controlled system and a system that quietly grows lateral movement paths every time someone adds a tool.

Pattern 5: Preserve the Provenance Chain Across Every Hop

The final pattern is the one most teams don't realize they need until they're in the middle of an incident.

Agents rarely act alone. Agent A calls Agent B, which invokes a tool that talks to a downstream service, which triggers a job that eventually writes to a database. When something goes wrong at the far end of that chain, the question everyone needs to answer is: who initiated this? Not the immediate caller. The original caller. The human, or the scheduled trigger, or the external event that started the whole cascade.

Without an intentional provenance chain, that question is often unanswerable. Each hop drops the identity of the previous hop and substitutes its own. By the time you're at the database write, all you can see is that Agent D did it, and Agent D has no memory of why.

The pattern is to propagate identity, not replace it. Every hop signs its action with its own identity and includes the identity of the caller that triggered it. The provenance chain accumulates, so at the end of the chain you can read the complete history: user submitted request, request routed to agent A, agent A invoked agent B, agent B called tool X, tool X wrote to database Y. Every step signed. Every step attributable.

The specifications and tools for this vary by maturity. SPIFFE-based trust domains support this natively. OAuth token exchange with the act claim preserves acting-on-behalf-of relationships across service calls. In-house implementations often just require a well-designed context header propagated through every service call, containing signed identity claims from each hop.

Whatever the mechanism, the invariant that matters is: any action anywhere in your system can be traced back to the human, agent, or event that ultimately initiated it. When a bad outcome shows up in the logs, you can reconstruct who is accountable in real time rather than in a two-week postmortem. That capability is the difference between a system you can operate and one you're afraid to touch.

The Objections Worth Answering

"This is overkill for our internal tools." Every mature security incident in cloud history started with "this is just an internal tool." Internal agents get compromised. Internal tools become external targets when adjacent systems get breached. The five patterns cost a small amount of engineering upfront and prevent a very expensive class of incident later.

"Our IAM tooling doesn't support this natively." Most of it does, actually. Every major cloud provider offers workload identity federation, short-lived tokens, and per-resource scoping. HashiCorp Vault covers most gaps. What's usually missing is not the tooling. It's the discipline to use the tooling.

"We'll add this after we have product-market fit." The teams that say this most often are the teams that end up doing an emergency retrofit six months into rapid growth, when adding identity discipline to systems already in production requires touching every deployment. Doing it now, when the system is small, is much cheaper than doing it later, when the system is big and full of assumptions that would need to change.

"Compliance hasn't asked for this." They will. When AI-related incidents start appearing in enforcement actions, and they are already appearing, compliance teams get asked what identity boundaries exist around agent workloads. The teams with these patterns in place answer calmly. The teams without them scramble.

What This Buys You

Getting these five patterns right is not glamorous. It won't win you a conference talk. It won't get you featured on Product Hunt. What it will do is make the difference between an agent that misbehaves and gets caught immediately with a clear blast radius, versus an agent that misbehaves and blows up something you can't easily reconstruct or contain.

The teams that internalize this early get to operate agent-shaped software with the same confidence they operate any other production system. The teams that skip it get to write postmortems that are much harder than they needed to be.

None of these patterns are novel. They are the accumulated wisdom of two decades of distributed systems security, applied to a new class of workload. The tooling exists. The specifications are mature. What has been missing is teams treating agent workloads with the same identity discipline they'd apply to any other service in their environment.

Start with pattern one. The other four follow naturally once the foundation is in place.