We have a bunch of AI agents sharing one API key. How do I give each agent its own identity so I can tell them apart in logs?

Stop authenticating agents with a shared secret and give each one its own key pair plus a short-lived identity token scoped to that single agent. The agent's identity helper generates a private key that never leaves your environment, enrols the agent under a unique name, and signs every request. Because each request carries a signature made by that agent's key, your logs record a distinct, verifiable agent identity on every line instead of one shared key value that every agent reuses.

Why isn't a shared API key enough to tell AI agents apart?

A shared key is a single string that every agent presents identically. Nothing in the request distinguishes one caller from another, and if the key is copied it still looks legitimate. You can tag requests with a label the agent sends about itself, but a label is self-asserted and can be spoofed, so it is not evidence. Per-agent identity makes the caller cryptographically provable rather than self-asserted.

Do I have to rewrite my agents to give them individual identities?

Usually not. The identity helper wraps the agent's outbound calls, handling enrolment, token refresh, and request signing, so the change is mostly a drop-in client plus a one-time human approval per agent. Your downstream systems sit behind a gateway that verifies the signature, so they do not have to change either.

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 human owner.

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 "who 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: a key pair whose private half never leaves your environment, and a short-lived identity token that names exactly one agent. The agent signs each request with its private key, and the signature covers the specific operation being requested. A verifier can then confirm two facts independently: the token names Agent A, and the signature on this request was produced by Agent A's key. That is evidence, not a self-asserted label.

Unique per agent — one key pair and one identity per agent, never pooled.
Sender-constrained — a token copied out of a log authorizes nothing, because the matching private key is needed to sign the request.
Short-lived — tokens expire in minutes, so a leaked token is useless almost immediately.
Owned — each agent is enrolled by a named human, so identity ties back to a person.

How to set it up

Run an identity helper beside each agent. It generates a private key locally, inspects the host, and enrols the agent under a unique name. The key never leaves the machine.
Approve the agent once. A named person is shown the agent and approves it. Until then the agent has no usable identity.
Issue a short-lived token. The identity service hands back a token bound to the agent's key and that machine, expiring in minutes.
Sign every request. The helper attaches a signature (using HTTP Message Signatures, RFC 9421) that covers the exact operation, so the proof cannot be replayed for a different call.
Verify at a gateway. A single gateway in front of your systems checks the token and the signature, records the agent identity, and only then forwards the request.

From the application's point of view, almost nothing changes: the helper handles enrolment, refresh, and signing, and the systems behind the gateway 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 human who owns it, the exact operation, and the moment it happened — all backed by a signature you can re-verify later. "Who did this?" becomes a lookup, not an investigation. Because the identity 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 keys, human-approved enrolment, short-lived sender-constrained tokens, and gateway 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 key pair and a short-lived identity token scoped to that one agent, and have the agent sign every request with its private 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. A signature made by a private key that never leaves the agent's host is evidence, because only that agent could have produced it.

What happens if a per-agent token leaks?

Far less than with a shared key. The token is sender-constrained, so without the matching private 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. Humans still sign in through your existing OIDC provider; 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