Agent Identity
Every security review of an AI feature arrives at the same question: when an agent acts, whose authority is it acting on?
The industry has not settled on one answer, and the two candidates behave differently under audit.
Two ways to give an agent an identity
| Approach | The agent's authority is | Revoking it means | Best at |
|---|---|---|---|
| Delegated | Borrowed from the person operating it | Removing the person's access | Keeping reasoning simple — an agent can never exceed its operator |
| First-class | Its own, granted directly to it | Revoking that identity alone | Attribution and least privilege — the agent is a principal you can name, scope, and audit |
The delegated model is easy to reason about and hard to over-grant. The first-class model gives you something delegation cannot: a subject in the audit trail that is the agent.
Most arguments treat these as rivals. They answer different questions, and which one you want depends on whether a person is present.
What this platform does
Both — chosen by whether there is someone to delegate from.
| The agent | Carries | Its permissions come from | The audit trail names |
|---|---|---|---|
| Runs for a signed-in person | That person's identity | The person's roles | The person |
| Runs unattended | A system token issued to it | The roles granted to that token | The token |
A system token is a first-class identity in the ordinary sense. It is scoped to one organisation, it draws its permissions from roles exactly as a person does, it can be revoked on its own without touching anyone else, and it appears in the audit trail as itself.
What the platform never does is hold a third identity of its own. There is no credential belonging to the endpoint, sitting behind both cases, that an agent falls back on when its caller's permissions run out. That is the thing being refused — not non-human identity, which is supported, but a broker.
Why refusing the broker matters
A broker identity has to be permissive enough for every caller it serves, so its permissions are the union of everyone's. From that point on:
- The agent's reach stops being knowable from the caller. Answering "what can this agent see?" means auditing the broker, not the person.
- Every access-control layer below is downgraded to advice. Isolation, permissions, policy and masking all evaluate against the broker's identity, which was never the identity you meant to check.
- The audit trail names the broker. Every action, by everyone, attributes to the same subject.
This is the failure the security literature calls excessive agency, and it is why the endpoint has no identity to fall back on. It is a small design decision that removes a large class of question.
What this costs: attribution
Attribution is where the model has a limit.
When an agent runs unattended, attribution is exact — the token is the actor, and one token per agent gives you one subject per agent in the audit trail.
When an agent runs for a person, the audit trail records the person. It does not separately record that the change arrived through an agent rather than through the console. Who is always unambiguous; through what is not part of the business audit record.
So today you choose which of the two you want to be able to prove:
| If you need to prove | Give the agent | And you lose |
|---|---|---|
| Which agent did it | Its own system token | The person behind the request |
| Which person did it | The person's own identity | That an agent was involved |
You cannot currently have both in one entry. The standards work that would close this exists — OAuth 2.0 Token Exchange defines a composite identity, where a token names both the party being acted for and the party acting — and adopting it would let one entry read "this person, through this agent". The platform does not implement it today.
Give each unattended agent its own system token rather than sharing one. It costs nothing, and it is the difference between an audit trail that names the agent and one that names a credential several agents happen to share.
Choosing for your own deployment
| Situation | Use |
|---|---|
| An assistant a person interacts with | The person's identity — attribution to the person is what you want |
| A scheduled job with no person involved | A dedicated system token, scoped to exactly what the job does |
| One agent serving many people | The identity of whoever is asking, per request — never one shared credential |
| A pilot you may need to shut off quickly | A dedicated system token, which can be revoked without affecting any person |
Revoking an agent that runs as a person means changing that person's access, which affects them too. An agent with its own identity can be switched off on its own.
Next
- Agent Patterns — the shapes agents take, and the permissions each needs
- AI Security Model — what an agent cannot do, and why
- AI Compliance — the claims and the evidence for each
- Control Access — how permissions are composed into roles