Every Agent Needs a Name 

Identity for non-human workers, delegated authority that only ever narrows, and why a permission decision must never be read from a token 

Ask most teams what identity their AI agent uses, and you get one of three answers — all variations on the same shrug. An API key someone generated. A service account older than anyone on the team. Or, the honest one: whatever credentials sat in the environment file, unchecked. 

None of that is AI agent identity. Those are keys, and a key answers a weaker question. A key says whoever holds this may proceed; an identity says this specific actor, doing this specific thing, for this specific person, right now. The difference stops being academic the moment something goes wrong. 

THE 60-SECOND VERSION 

• An agent with its own standing privileges is an unbounded liability — compromised or simply confused, it can do anything it’s permitted to, to anyone, with no link back to a responsible person. 
• The fix: make the agent a first-class principal that holds almost nothing, borrowing authority from the person who asked — a signed chain where the human is the subject and the agent is the actor. 
• Authority only ever narrows. Each hop carries the intersection of what the person holds and what was actually requested — no operation widens it. 
• Authorization is re-derived at the moment of action from the policy catalog, never read from token claims. A permission revoked at 09:00 is gone at 09:00, not when the token expires. 
• Enforcement lives at the resource, not the interface, so forging a call to a downstream address gets nothing. 

The problem with a well-behaved agent 

Start with a case where nothing malicious happens at all. Priya runs finance operations at a logistics company. Her team deploys an invoice reconciliation agent that reads invoices, reads the ledger, flags mismatches, and posts adjustments on small, clean matches. It gets a scoped service account. Sensible, even — until a second team wants vendor queries (permission added), then procurement wants contract-term checks (permission added). Six months later the agent holds fourteen permissions, granted at fourteen different moments, all of them, all of the time. 

Here’s what’s quietly become true: when a junior analyst in procurement asks that agent a question, it answers using its permissions, not the analyst’s — including payment history the analyst was never cleared for. It usually won’t reveal it, but “usually” is doing a lot of work. 

Nobody attacked anything. No credential leaked. The system worked exactly as designed — and the design was wrong. 

An agent with its own standing privileges isn’t a worker. It’s a shared account with a language model attached — the thing security teams have spent a decade trying to eliminate. 

Borrowed authority, not owned authority 

The fix mirrors how organizations already work, and it’s the same idea OAuth 2.0 formalized for delegated access over a decade ago. When a paralegal pulls a client file, they aren’t exercising a personal right to it — they’re acting on the authority of the partner who assigned them, on a specific matter, and the firm records both facts. Remove the assignment and the access evaporates. 

Agents should work the same way: an identity, permanently, so every action is attributable — but almost no authority of its own. When Priya asks it to reconcile March, it receives a grant naming her as the subject, itself as the actor, scoped only to what this task requires and drawn from what Priya herself holds. That last clause carries the whole idea: the agent can never exceed the person it’s acting for. If Priya can’t see a payment record, no agent working on her behalf can either, no matter how broadly it was provisioned for other purposes. 

Run the earlier scenario again with this in place. The procurement analyst asks the same agent the same question, and the agent now acts with the analyst’s authority, narrowed to this task. The payment history it could see while working for Priya simply isn’t reachable — not filtered by good judgment, but structurally out of reach. This is what delegated authority AI agents actually means in practice. 

Narrowing, hop by hop 

Real work rarely stops at one agent. An orchestrator hands part of the request to a specialist, which calls another for a lookup — and how authority travels across those hops is where systems hold together or quietly fail. 

Three properties make the chain trustworthy: 

• The subject never changes: Three hops deep, the record still says Priya asked for this — it never decays into “the ledger agent did it,” the failure mode that leaves incident response with a log full of service accounts and no way back to a person. 
• Each hop is signed and re-addressed for its recipient: A grant issued for the invoice agent isn’t a bearer token that works anywhere; it names its intended audience. Intercept and replay it against a different service, and it fails. 
• Scope narrows and never widens: Each exchange produces the intersection of what the subject holds and what this step needs. Four permissions become three, three become one — no code path adds one back. 

This is what makes a compromised agent’s blast radius finite and calculable. Subvert the ledger agent and the attacker inherits only what it was carrying for the request in flight — one permission, one task, expiring shortly. Compare that to the service-account version, where compromise hands over all fourteen permissions indefinitely. 

One rule is absolute: delegation never crosses a tenant boundary. No chain of exchanges, however trusted the intermediary, produces authority in another customer’s tenant — that path is rejected outright. 

The agent nobody asked 

A fair objection: what about work with no human requester — a nightly reconciliation, a monitoring agent, a compliance archive running monthly? Nobody asked, so there’s no subject to borrow from. 

The wrong answer is granting those agents standing privileges and calling it an exception — exceptions are where governance models go to die. The better answer treats non-human identity as a first-class category: the agent becomes a principal in its own right, authority explicitly granted for a stated purpose, reviewable and revocable the same way as any human’s access. 

Autonomous agents don’t hold no authority — their authority is deliberate rather than accumulated. This also answers a question most agent deployments can’t: which non-human identities exist, what can each do, and who approved it? One governance model, one directory — a report instead of a project. 

Where the decision is made matters as much as the decision 

A subtle failure shows up in a lot of otherwise careful designs. A token issued at 09:00 carries a set of permissions. At 09:15, someone removes one — an offboarding, a role change, an incident response. At 09:20 the agent presents its token and does the thing it should no longer be able to do, because that permission is still written inside a token that’s cryptographically valid. The trap is treating a token as a statement of what you may do, when it’s only a statement of who you are, signed by someone trustworthy. 

The discipline splits into three steps: 

• Verify at the edge. Signed by a trusted issuer? Addressed to us? Not revoked? Signature and provenance only — no permission decisions here. 
• Decide from the store. Is this principal, acting for this subject, allowed to do this, right now? Asked fresh, answered from the live catalog. 
• Enforce at the resource. The check happens where the data lives, not the interface that displays it. An agent doesn’t use the console — it makes calls, so a gate that only sits on the screen is one that a downstream address walks straight past — the same Broken Object Level Authorization pattern OWASP ranks as the single most common API vulnerability. 

The parts people forget 

Three details separate a whiteboard design from one that survives an audit. 

• More than one issuer. Human logins come from your identity provider; agent identities may come from elsewhere; a delegated grant is a third shape. Each issuer is trusted only for specific assertions — never “trust anything signed by anyone we’ve heard of.” 
• Revocation that actually revokes. Every credential carries a unique identifier and can be killed individually — “we terminated their access” should also mean their agent’s in-flight work stopped. 
• Binding a credential to its holder. A grant that works for whoever holds it is a grant that works for whoever steals it. Binding it to a key the legitimate holder possesses — standard practice under on-behalf-of token exchange patterns like RFC 8693 — makes a copied credential inert. 

What it costs 

Two honest trade-offs. A decision per action — re-deriving authorization instead of trusting a token means a lookup on the hot path, mitigated with caching and fast, coarse checks, but not free; trusting stale claims isn’t really an alternative. And more moving parts than an API key — token exchange, issuer trust, revocation, and key binding are more machinery than a shared secret in an environment variable. That’s the point — it’s what an API key was silently not doing — and it belongs in the platform, so agents inherit agent least privilege by default instead of each team implementing it inconsistently. 

WHAT TO TAKE AWAY

• A permanent identity makes an agent’s actions attributable; almost no permanent authority keeps a compromise bounded. 
• Authority is borrowed from the person being served — an agent can never exceed the human it acts for. 
• Scope narrows at every hop and never widens; a subverted agent inherits one task’s authority, not an accumulated pile. 
• Verify signatures at the edge, decide from the live catalog, enforce at the resource rather than the interface. 
• Delegation stops hard at the tenant boundary — rejected outright, never evaluated. 

NEXT IN THE GOVERNED AGENT 

Part 3 — Least-Privilege by Construction. An agent now has an identity and borrowed authority. But which other agents may it call? In most systems that question is never asked — and an agent that learns another’s address can simply dial it. 

Catch up on Part 1 – The Trust Gap if you’re joining the series here.