Is your AI agent running on someone else's login? Give it its own, and cap what it can do

AI agents now sign in, call APIs, read data and change things on systems that matter, and many of them do it on someone else's account. If you run one, give it its own identity, short-lived access for each task and a person who signs off anything you can't undo. This post explains why, then what to do if an agent's access gets misused.

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 that's an identity problem with known answers.

The cost shows up in two places. The agent can reach far more than its job needs, so one bad instruction can do a lot of damage. And when something goes wrong, your logs name the wrong actor, so you can't tell an auditor or an insurer who actually did what.

We've argued before that zero trust is something you have to prove, and that conditional access is production code you test like any other. Agents make the same case at machine speed. They make the same access decisions hundreds of times an hour, and someone can talk them into things.

For engineers, the point of that chain is step four. Prompt injectiondefinitionSomeone hides an instruction in a document or ticket comment an AI will read. If the agent follows it, it does something its user never asked for, with whatever access it holds. gets the agent to want something, and the credential decides whether it can do it. Every fix below works on what the agent holds at that moment, because that part you control.

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, registered alongside every other non-human identity with a named owner and a retirement date. DelegationdefinitionLetting an agent act for one person and writing that down. If Priya hands an agent her refund queue, the log shows the agent did the work for Priya. 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.

The standards already cover this. OAuth 2.0 Token Exchange (RFC 8693) separates delegation from impersonation: under delegation the acting party keeps its own identity, and the token's act claim names it. Ask your identity provider whether it can issue tokens like that, since it decides how much of this you build yourself.

That model also settles the authority question. An agent's ceiling is the overlap between 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. Identity programs have spent a decade stripping standing privilegedefinitionAccess that stays on an account whether or not today's task needs it. Nobody notices it sitting there until someone misuses it. out of human accounts, and agents shouldn't bring it back.

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. Set a token to expire after ten minutes, and a copy someone pulls out of a log only works for a few minutes. 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 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 where prompt injection stops being a content-filtering problem. A poisoned document can make an agent want something you never asked for, and so can a calendar invite or a ticket comment. You can't filter your way to safety when the filter is probabilistic and the attacker gets unlimited attempts. OWASP makes a similar point in its Top 10 for LLM applications: it's unclear whether fool-proof prevention exists.

What you can do is make the wanting irrelevant. Treat injection as a way to escalate privilege and the design follows. Whatever credential the agent holds at that moment sets what a successful injection costs you, and prompt hygiene doesn't change that much. Keep scopes narrow and short-lived, deny tools by default, and 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

That's what a good trace looks like. The agent tried a payment it wasn't allowed to make and got refused, and the bank details change sat waiting for a person. Anyone reviewing it later can tie all 37 actions to the agent and the clerk it worked for.

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. Record it 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. Many logs record only the account and the time. 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, and an agent never complains about access it no longer needs.

Most of our agent reviews start with a spreadsheet. We list every agent, the account it signs in with and what that account can actually reach. Then we look at where people approve things and whether the logs would hold up with an auditor. The AI agent identity page explains how we work, and non-human identity governance covers the service accounts and tokens around it. You can also start with an assessment.