Learn · Identity
Give each AI agent its own identity instead of a shared API key
You have several AI agents in production and they all authenticate with the same key. When something goes wrong, your logs say the key did it, not which agent. Here is how to fix that: a distinct, verifiable identity per agent, so every request is attributable to one agent and one accountable sponsor.
The shared-key problem
A shared API key is a single secret that every agent presents the same way. It answers the question "is this request allowed?" but never "which agent sent it?" If three agents share one key and one of them deletes the wrong records, the audit trail points at the key, not the agent. Rotating the key means coordinating a change across every agent at once, so in practice it rarely happens. And because the key is just a string, a copy of it works exactly as well as the original from anywhere, so a leaked key is indistinguishable from the real caller.
The core issue: a shared key proves authorization but not identity. To tell agents apart you need something each request carries that only one agent could have produced.
What per-agent identity means
Per-agent identity replaces the shared string with two things for every agent: an anchor key whose private half never leaves your environment, and an identity token that names exactly one agent. The agent's identity is the anchor key's thumbprint. The agent signs each request with its anchor key, and the signature covers the specific operation being requested — an operation proof. A verifier can then confirm two facts independently: the token names Agent A, and the operation proof on this request was produced with Agent A's anchor key. That is evidence, not a self-asserted label.
- Unique per agent — one anchor key and one identity per agent, never pooled.
- Proof of possession — a token copied out of a log authorizes nothing, because the matching anchor key is needed to produce the operation proof.
- Expiring — identity tokens live for minutes, so a leaked token is useless almost immediately.
- Sponsored — each agent is enrolled under an accountable sponsor, so identity ties back to a person or organization.
How to set it up
- Run an Identity MCP beside each agent. It creates an anchor key locally, records a host digest, and enrolls the agent under a unique name. The anchor key never leaves the host.
- Enrollment approval, once. A principal signs in and reviews the agent, and the enrollment is approved. Until then the agent has no usable identity.
- Issue an identity token. The identity service (AIS) hands back a token bound to the agent's anchor key and its host binding, expiring in minutes.
- Prove possession on every request. The Identity MCP attaches a signature (using HTTP Message Signatures, RFC 9421) that covers the exact operation, so the operation proof cannot be replayed for a different call.
- Verify at the Gateway MCP. The Gateway MCP in front of your resource servers checks the identity token and the operation proof, records the agent identity, and only then forwards the request.
From the application's point of view, almost nothing changes: the Identity MCP handles enrollment, refresh, and signing, and the resource servers behind the Gateway MCP keep their existing interfaces. You can see this whole flow running end to end in the live demo.
What your logs look like after
Before, every line reads as the same key. After, each line records the agent's unique identity, the sponsor who stands behind it, the exact operation, and the moment it happened — all backed by an operation proof you can re-verify later. "Which agent did this?" becomes a lookup, not an investigation. Because the identity token expires on its own, an agent you forget about simply stops working within minutes rather than holding a live credential forever.
Oathera implements exactly this model: per-agent anchor keys, enrollment approval, identity tokens with proof of possession, and Gateway MCP verification. See the platform overview or developer building blocks to go deeper.
FAQ
How do I give each agent its own identity so I can tell them apart in logs?
Give each agent its own anchor key and an identity token scoped to that one agent, and have the agent produce an operation proof over every request with its anchor key. Each request then carries a verifiable, distinct identity, so your logs record which agent made each call instead of one shared key value reused by all of them.
Isn't a per-agent label in the request enough?
No. A label the agent sends about itself is self-asserted and can be spoofed or copied. An operation proof made with an anchor key that never leaves the agent's host is evidence, because only that agent could have produced it.
What happens if a per-agent identity token leaks?
Far less than with a shared key. The token requires proof of possession, so without the matching anchor key it cannot be used, and it expires in minutes regardless. A leaked shared key, by contrast, works indefinitely from anywhere.
Does this replace my API gateway or identity provider?
It sits alongside them. People still sign in through your own IdP; agents map to workload identity (SPIFFE) where you use it. Oathera adds the per-agent layer rather than asking you to replace what you run.
See the identity flow live More guides
← Back to Learn