Authority guide
An AI agent is not a user
The tempting design is to give the agent a seat: a login, a name in the member list, the same role as the person who summoned it. That fiction is convenient for a week and expensive forever. An agent needs a distinct principal, not a borrowed human identity.
Direct answer
An AI agent should be modeled as a distinct non-human principal acting under delegated authority—not as another human seat and not as the human’s full identity. Each run receives short-lived, scoped capabilities. Effects stay attributable. Permissions can be revoked without erasing history.
Definition
What an agent principal is
A principal is whoever an access check and an audit record can name. Humans are principals. Services are principals. An AI agent that can open a pull request, leave a comment, or touch customer data is also a principal. The mistake is to pretend it is a person, or to pretend it is nobody.
It does not need a human-style login UI or an employee fiction in order to have that distinct principal. SPIFFE workload identity already treats software as something that receives its own identifier and credential. The agent is closer to a workload than to a coworker. Give it an identity that can be granted to, logged, and revoked. Do not put it on the org chart.
That identity is also not the human who started the work. If Aisha delegates a coding task and the repository later shows only Aisha, you have impersonation dressed as convenience. You can no longer tell which effects were hers, which were the agent’s, or how to stop the next run without locking Aisha out.
Do not collapse these
Five identities that get treated as one
Most agent-permission failures start as a naming failure. The system has one “user” field and puts the human, the bot, the job, and the API key in it.
Human principal
The accountable person or organization. They authenticate as themselves. They remain responsible for what they delegate, including when an agent does the typing.
Agent definition
The kind of agent: its purpose, default policy, tools, and standing instructions. A definition is a template. It is not a live grant of power over a repository or a billing account.
Durable agent instance
A particular non-human principal that persists across days: “Aisha’s Northline coding agent.” It has an identity. It does not automatically inherit Aisha’s login, her other workspaces, or last month’s permissions.
Execution run
One bounded attempt: a session, job, or turn with a start and an end. The run is what actually touches tools. It should receive short-lived, scoped capabilities—not the instance’s entire possible life.
Runtime or provider credential
How the model is invoked: an API key, workload identity, or sandbox account. That credential authenticates the runtime. It is not the agent’s authority over the project, and it is not the human.
Two different questions
Authentication is not authorization
Authentication establishes which principal is acting. Authorization decides whether that principal may perform this action on this resource, now, under this policy. NIST’s Zero Trust Architecture insists on that evaluation remaining continuous. Being able to call the model, being present in a room, or having succeeded yesterday is not a reason to skip the check.
The same split appears in ordinary access-control catalogs. NIST SP 800-53 Revision 5 still wants identification, least privilege, and accountable event logging when the actor is software. An agent does not get a exemption because it is helpful, or because it was started by someone who would have been allowed to do the same thing by hand.
Least privilege follows immediately. The Model Context Protocol authorization tutorial treats scopes as something to minimize and to step up, not as a standing “the agent is logged in” state. A run that needs to read one repository should not receive a token that can see billing, the next workspace, or the merge button.
On whose behalf
Delegation leaves two names. Impersonation leaves one.
OAuth 2.0 Token Exchange makes the distinction operational. A token can carry a subject—the party on whose behalf work is done—and an actor—the party doing it. That is delegation. Impersonation issues a credential that makes the actor indistinguishable from the subject. Downstream systems then have no honest answer to “who did this?”
For agents, impersonation is the default accident. The human’s Git token is pasted into the environment. The bot user is added as a collaborator with the human’s role. The audit log shows a person who was in a meeting. Prefer an explicit actor. The human remains the accountable principal. The agent remains the working principal. Both names belong on the effect.
Delegation is also how you keep synchronized project state honest. If two agents can write, and both writes look like the same human, you cannot reconstruct causal order or authority later. The identity model and the state model fail together.
What a grant must name
Scope is more than a role name
OAuth Rich Authorization Requests exist because a single scope string is a poor description of access. An agent grant should be at least as specific: action, resource, time, budget, and approval.
| Dimension | May include | Must refuse |
|---|---|---|
| Action | Read repository files; open a draft pull request. | Merge, force-push, delete branches, or change repository settings. |
| Target resource | The northline/app repository, and comments on its own draft. | Any other repository, workspace, or customer dataset. |
| Time | This run, or a short lease measured in hours. | A standing token that survives the weekend by default. |
| Budget | A bounded number of tool calls, tokens, or dollars. | Unlimited retries that become a quiet denial-of-wallet. |
| Approval | Drafts and comments proceed. Merge waits for Aisha. | Self-approval because the agent “usually does this.” |
A concrete example
Northline, draft only
Aisha owns Northline, a routing tool. She starts her coding-agent instance on a single job: propose a safer retry policy in the northline/app repository. The run may read that repository and open a draft pull request. It may comment on its own draft. That is the entire grant.
The agent remembers, from last month, that Aisha often merges small infrastructure PRs herself after lunch. It also has a provider credential that can call the model. Neither fact is a permission. The run cannot merge. It cannot open the billing page to “check the spend.” It cannot search Aisha’s other workspace for a similar retry helper. If it tries, the capability check fails, and the failure is recorded.
Mid-run, Aisha decides the change is more sensitive than she thought. She revokes the instance’s write grant. The current run cannot open another draft. The draft already opened stays, with its author still named as the agent instance and run, delegated by Aisha. History is not rewritten to look like she typed the patch.
A later audit record should be able to answer:
- Which human or policy delegated this work?
- Which agent instance acted, and which run?
- What capability was granted, on which resource, until when?
- What effect actually occurred, and against which base?
- Was further approval required, and who gave it?
- If the grant was revoked, when—and did later effects stop?
If the record cannot answer those questions, the system gave an agent effects without giving the project a principal. That is the failure, even if the retry policy was fine.
A practical model
Separate the human, the instance, and the run
You do not need a new identity product to start. You need names that do not collapse, and grants that expire.
- 01
Keep the human as themselves
Aisha authenticates as Aisha. She does not share a password with the agent, and the agent does not sit in her employee seat.
- 02
Give the instance its own principal
The coding agent is a durable non-human identity. Reviews, logs, and revocation talk about that identity—not about “the user.”
- 03
Issue capabilities to the run
Each execution receives a short-lived, scoped grant. The instance’s existence is not a permission slip for every future job.
- 04
Separate the runtime credential
The provider key or workload identity calls the model. It should not be reused as the agent’s authority over Git, billing, or another team’s files.
- 05
Attribute every effect twice
Record the acting agent and run, and the human or policy that delegated. One name in the log is not enough.
- 06
Revoke forward, keep history
When Aisha pulls access, later runs fail closed. Earlier drafts, comments, and decisions remain inspectable.
Memory is not a grant
Remembered instructions do not become permissions
Agents accumulate notes: house style, the owner’s habits, a sentence from a chat that sounded like standing policy. That material can be useful context. It is not an access-control system. If memory can widen scope, every prompt injection and every stale aside becomes a privilege-escalation path.
The same discipline belongs next to shared project context: accepted decisions travel; unreviewed memories do not. A constraint in project state can inform what the agent proposes. Only a current capability can let it act.
- Merge the pull request
- Access billing or payment methods
- Search or read another workspace
- Mint new credentials or widen its own scope
- Turn a remembered instruction into a permission
- Act after the run’s lease or budget expires
Stop future work
Revocation should fail closed, not rewrite the past
OAuth token revocation is the narrow protocol version of a broader rule. When a grant is withdrawn, outstanding credentials should stop working, new runs should not receive the capability, and in-flight work should fail closed if it still needs that capability. The product should not “clean up” by deleting the draft, the comments, or the fact that the agent acted.
Provenance is why. SLSA provenance asks who produced an artifact, from what source, and with what parameters. Agent effects need a similar predicate. If revocation erases the actor, you can no longer tell whether a merge conflict, a leaked path, or a surprising comment came from a person, a run, or a reused token.
MCP security guidance is explicit about a related failure: token passthrough and confused deputies destroy audience and accountability. If an agent presents someone else’s token, or a token minted for a different resource, the downstream system cannot name the acting principal. Model the agent as itself, issue tokens to that principal, and revoke those tokens. Do not launder the human’s credential through the bot.
Design lessons
What current Vespyn work keeps naming separately
These are design lessons from systems Vespyn is building, not a claim that the whole architecture ships publicly. The separations are the useful part.
One lesson is to keep the human, the agent instance, and the run as different objects. The human is accountable and authenticates as themselves. The instance is a durable non-human principal with a life cycle. The run is the only thing that should receive the short-lived capabilities that can change a repository or a document. When those three share a single “user id,” every later control becomes folklore.
Another lesson is that project control is not identity. A room or session may have a controller—someone currently allowed to accept consequential changes. That lease can move. It is not the same thing as “who is logged in,” and it is not the same thing as the agent instance that happens to be working. Presence is not authority; a runtime is not authority either.
A third lesson is that the runtime—the model provider, the sandbox, the machine that executes tools—needs its own credential and should stay in its lane. The runtime calls the model. It should not be the name that appears on a pull request, and it should not inherit the human’s workspace.
Named separately, those pieces can be granted, reviewed, and revoked. Collapsed into a user account, they can only be trusted or feared.
Limits
What this method will not do
A clean principal model will not make an agent trustworthy at the task. It will not stop a wrong patch that stayed inside scope. It will not replace code review, product judgment, or the decision not to delegate a job at all.
Distinct identities also have a cost. More names mean more bookkeeping. Teams will be tempted to create one shared bot user “for simplicity.” That is impersonation with extra steps. If several agents share one principal, you can revoke all of them or none of them, and you still cannot tell which run did the damage.
There is a fair counterargument on small personal spikes: a single human, a single agent, a throwaway branch. You can keep the model in your head for a day. The moment the agent can reach billing, another workspace, or a shared project, the fiction becomes someone else’s incident.
This page is a working method, not a claim that any particular product already performs it for you. The useful test is simple. If you revoke the agent, does the human remain able to work? If you read last week’s pull request, can you still see that an agent wrote it?
Short answers
Questions this usually comes down to
Is an AI agent a user account?
No. A user account is a human or organizational identity with a login, a lifecycle, and usually a broad role. An AI agent is a non-human principal that should act under delegated, scoped authority. Giving it a human-style seat hides who is accountable and what it may do.
What is an agent principal?
It is the distinct identity of the agent as an actor: not the human, not the model vendor, and not a single run. The principal lets you attribute work, grant capabilities, and revoke them. It does not require a human login screen or an employee fiction.
What is the difference between delegation and impersonation?
Delegation means the agent acts on behalf of a human, and both identities remain visible. Impersonation means the agent acts as the human, so logs, reviews, and access checks cannot tell them apart. Prefer delegation whenever an effect needs to be audited.
Should each AI agent have its own identity?
Yes, if it can cause effects. A durable instance needs a principal so grants and logs have a subject. Each run should still receive its own short-lived capabilities. One shared “bot user” for every agent in the company recreates the human-seat mistake at a larger scale.
How should agent permissions be revoked?
Revoke the grant so later runs cannot obtain it, expire or destroy outstanding tokens, and fail closed. Do not delete the history of what the agent already did. OAuth token revocation is the narrow protocol analog; the product rule is stop-future, keep-past.
Can agent memory grant permissions?
No. Memory can store facts, preferences, and prior instructions. Authority comes from a current grant issued to a run. A remembered sentence such as “Aisha lets me merge” must not widen scope.
Sources
Further reading
- NIST SP 800-207, Zero Trust Architecture
Access is evaluated continuously from identity, context, and policy. Trust is not implied by being “inside” a network, a chat, or a workspace.
- SPIFFE workload identity concepts
Workloads receive their own identifiers and credentials. A process does not need a human login in order to be a distinct principal.
- OAuth 2.0 Token Exchange (RFC 8693)
The actor and subject can both appear on a token. That is the protocol picture of delegation, as distinct from impersonating the subject.
- OAuth Rich Authorization Requests (RFC 9396)
Authorization can name types of access, locations, actions, and privileges instead of a single coarse scope string.
- OAuth 2.0 Token Revocation (RFC 7009)
A client can notify the authorization server that a token should no longer be accepted. Revocation stops future use; it is not an erase of history.
- MCP authorization and least-privilege scopes
The Model Context Protocol’s authorization tutorial treats access as scoped and step-up capable, not as a standing “the agent is logged in” state.
- MCP security best practices
Confused-deputy, token-passthrough, and over-broad scope problems all get worse if the agent is modeled as the user. Audience, consent, and minimization stay specific to the acting principal.
- SLSA provenance
A provenance record answers who produced an artifact, from what, and how. Agent effects need a similar predicate: who delegated, which run acted, on which inputs.
- NIST SP 800-53 Revision 5
Access control, identification, and audit families still apply when the actor is software. Least privilege and accountable event logging do not become optional because the actor is an agent.
Adjacent problems
Related guides
Vespyn
If you want this kept current for you
Vespyn is being built around shared project state for people and agents. It is not generally available. The next step is the waitlist.
Join waitlist