An AI agent should have its own identity, never a shared human or service account, and should hold credentials that are scoped to one resource and expire quickly. That limits what a hijacked agent can do and makes its actions traceable. The checklist below uses SPIFFE, OAuth token exchange and the MCP authorization rules.
Why do agents need their own identity?
When an agent acts under a person's login or a shared key, logs show the person or the key, not the agent. You cannot tell which agent did what, and revoking access for one means revoking it for all. OWASP's guidance on excessive agency lists a closely related failure: an extension that acts for an individual user but connects downstream with a generic high privileged identity.
A distinct identity per agent, and ideally per task or run, fixes both problems.
What does a workload identity look like?
SPIFFE, a standard for workload identity, describes an identity document (an SVID) that includes the workload's identity, called a SPIFFE ID, and a private key tied to it. The X.509 form is a short-lived certificate that workloads use for TLS or to authenticate to other workloads, and there is also a JWT form. You do not have to adopt SPIFFE itself, but its model is the right shape: identity is issued to a running workload, proved cryptographically, and expires.
How do you hand an agent access on behalf of a user?
OAuth 2.0 Token Exchange, RFC 8693, defines a protocol for obtaining security tokens from an authorization server, including tokens that use impersonation and delegation. Delegation matters for agents, because the resulting token can say that the agent is acting for a user, so downstream systems and logs can record both parties. Prefer delegation over handing the agent the user's own token.
What do MCP servers require?
The MCP authorization specification requires clients to use resource indicators (RFC 8707) so a token is requested for a specific MCP server, and requires servers to validate that tokens were issued for them as the audience. Servers must not accept or pass through other tokens. The MCP security best practices page calls token passthrough an anti pattern and says poor scope design increases the impact of a stolen token, with an example of broad scopes like files:* or admin:* granted up front.
The checklist
Constructed example: a coding agent opens pull requests and reads tickets. Use the list below to review it.
- Does the agent have its own identity, separate from any human and from other agents?
- Is the identity issued at runtime, not stored in a config file or an environment variable that lives for months?
- Do credentials expire in minutes or hours, and is renewal automatic?
- Is each token limited to one audience, the specific API or MCP server it is meant for?
- Are scopes the minimum for the task, for example read access to tickets and write access to one repository, not organization wide?
- When acting for a user, does the system use delegation so both the user and the agent appear in logs?
- Can you revoke one agent without breaking the others?
- Do high impact actions need a separate approval, no matter what the token allows?
- Are issuance, use and denial of credentials logged with the agent identity?
- Is there a test that shows an expired or wrong audience token fails?
If the coding agent in the example uses a personal access token from a developer's laptop with access to every repository, items 1, 3, 4, 5 and 6 all fail.
Where does Safeguard fit?
Safeguard provides agent identity and an MCP Guardrail that applies policy to agent tool calls, alongside policies and gates for pull requests. Use these as controls that sit with the checklist above rather than instead of it.
What to do
- Inventory every agent and the credentials it uses today.
- Replace shared and long lived keys with per agent identities issued at runtime.
- Set token lifetime, audience and scope limits in your authorization server.
- Adopt delegation for user initiated actions.
- Add logging that records agent identity on every call.
- Run a revocation drill for one agent and measure how long it takes.
Quick check
What is the difference between delegation and impersonation?
RFC 8693 covers both. With impersonation a token acts as the user. With delegation the token shows that one party acts on behalf of another, which keeps both visible for audit.
How short should an agent credential live?
The sources we reviewed do not give a number. Choose a lifetime tied to the task, such as minutes or hours, and test that renewal works.
Sources
- SPIFFE concepts
- RFC 8693, OAuth 2.0 Token Exchange
- MCP authorization specification
- MCP security best practices
- OWASP LLM06:2025 Excessive Agency
Last reviewed: 18 October 2026.
