There is a design question almost never asked out loud that defines the entire risk model: when the agent calls an API, does it act as itself or as you?
Three models, three consequences
Own identity. The agent has a service account with permissions defined for it. Auditing is clear, but the permission set is the union of what any user might need — and it does not change according to who asked.
Impersonation. The agent assumes the user's identity. Permissions come out right per user, but the log shows the person doing things they did not do. In an investigation, you accuse the wrong human.
On-behalf-of. The token carries both identities: who acts and on whose account. It is the only model that preserves attribution and scope at the same time — and the one most implementations skip, because it is more work on day one.
Impersonation is not delegation. It is erasing the trace of who actually executed.
The rule that cannot be broken
Whichever model you pick, the ceiling is the same: the agent must never be able to do something the delegating user could not do alone. Effective authorisation is the intersection of what the agent may do and what the human may do.
When that intersection is not enforced, the agent becomes an escalation mechanism: an intern asks for a report and the broadly permissioned service account returns data they could not reach through the normal interface. Nobody broke in — the design authorised it.
What to record
- Agent identity and delegating human identity, in separate fields.
- The effective scope computed for that call, not the agent's maximum scope.
- Delegation validity — it should expire with the session, not with the service account.
The case with no human
An agent triggered by cron or by an event has no delegator. That case demands more scrutiny, not less, because there is no natural permission ceiling. Treat it as an autonomous workload: fixed minimal scope, no elevation possible, and an alert on any deviation from pattern.
