Your AI agent is a privileged user. Treat it like one.

Your agent authenticates, calls APIs, reads data and changes state on systems that matter. In most deployments it does all of that as a shared service accountdefinitionA non-human account that software signs in with. Shared ones tend to pick up years of extra permissions., or on the personal token of whoever wired it up. An agent acting on someone's behalf is a privileged user with no HR record, no manager and no leaving date, so it has to be governed as its own identity and not as a feature of somebody else's login. Which makes this an identity problem, and those have known answers.

We've argued before that zero trust is a proof obligation, and that conditional access is production code, not a portal click. Agents are the same argument at machine speed, with the same access decisions made hundreds of times an hour by a principal that can be talked into things. Most of the weight sits on three disciplines.

The most common agent deployment we find in production authenticates as something that already existed. Usually that's a shared service account carrying a decade of accumulated grants, or the credential of the engineer who built the integration. Both collapse two principals into one. The service account hands the agent every entitlement anyone ever needed from it, and you can't tell an agent's call apart from a nightly batch job's. The personal token is worse. The agent inherits a human's full standing access, and the audit log names that human as the actor for everything it does, including whatever it gets up to at 3 a.m. while they sleep. An agent acting for a person is not that person. It needs its own principal: one identity per agent, per deployment, per environment, registered alongside every other non-human identity with a named owner and a retirement date. DelegationdefinitionLetting an agent act for a specific person, and recording that so your logs show the agent and the person it acted for. then gets recorded instead of happening by accident. The agent holds a token that says agent-on-behalf-of-user, and both halves survive into every log line. That model also settles the authority question. An agent's ceiling is the intersection of what the agent is approved to do and what the delegating user actually holds. An agent invoked by a tier-1 support rep must not be able to issue a refund that rep couldn't issue by hand, however well the request is phrased. If your architecture can't express that cap, the agent is effectively manufacturing authority.

The second failure is durable authority. An agent registered once with the union of every scope it might ever need is the old standing-privilege problem in a new hat, and identity programs have spent a decade stripping standing privilegedefinitionAccess that stays on an account whether or not the current task needs it. out of human accounts. So issue credentials per task. When a run starts, exchange the agent's identity plus the delegation for a token carrying only the scopes that run requires, with a TTLdefinitionTime to live: how long a token stays valid before it expires and stops working. measured in minutes. A triage run that reads invoices gets read access to invoices for ten minutes. If it later needs to write, that's a fresh authorization decision and a fresh token, and the run wasn't quietly holding that capability all along. Pair scope with a tool and API allow-list that denies by default. The agent gets the four tools the job needs. Anything else, including the tools sitting one function call away in the same framework, gets refused by the authorization layer instead of by the model. That's also the point where prompt injectiondefinitionInstructions tucked into content an AI reads, like a document or a ticket comment, meant to make it do something its user never asked for. stops being a content-filtering problem. A poisoned document can make an agent want to do something you never asked for, and so can a malicious calendar invite or an instruction buried in a ticket comment. You can't filter your way to safety when the filter is probabilistic and the attacker gets unlimited attempts. What you can do is make the wanting irrelevant. Treat injection as a privilege-escalation path and the design follows. The credential in the agent's hand at that moment sets what a successful injection costs you. Your prompt hygiene doesn't. With narrow, short-lived scopes and a tool list that denies by default, a compromised run stays a bounded incident.

# agent:invoice-triage, run 4f21b8 (authorization trace)
principal:    agent:invoice-triage@prod  // own identity
on_behalf_of: user:ap-clerk-2291  // scopes capped by their rights
task_token:   invoices:read, vendors:read · ttl 10m
tools:        4 allowed · all others deny-by-default
denied:       payments.transfer · outside allow-list
held:         vendor.bank_details.update → human approval
audit:        37 actions · agent + delegator + tool + outcome
✓ token expired at 10m · revocation path tested < 1 min

Some actions have no undo. Money moves, a mailbox gets emptied, a vendor's bank details change, someone is granted a production role. Write those down first and make every one of them stop at a person. The agent asking its own conversation to confirm doesn't count, because that user is inside the trust boundary the injection already crossed. You need an out-of-band approvaldefinitionA point where a qualified person must sign off one specific action before it runs, and outside the agent's own conversation. that shows the concrete action and its parameters and goes to someone with the standing to allow it, recorded with their identity and a timestamp. For actions that are cheap one at a time and catastrophic in bulk, rate limits and blast-radius caps do the same job. Everything else needs an audit record, and every record needs four facts: which agent, which delegator, which tool with which arguments, and what came back. Teams skip three of the four. It bites in the incident where you have to say whether the agent acted on its own authority or someone else's, and whether the call actually worked. Emit the trail from the authorization layer, since a compromised agent is an unreliable narrator of its own behavior. Then review it the way you review human access. Look at what was granted and what was genuinely used, and take back the rest. Agents pile up entitlements the way people do, only faster and more quietly. An agent never complains about access it no longer needs.