Governance · 4 minute read
Non-Human Identities for AI Agents: Identity Done Properly
Non-human identities for AI agents are distinct security principals issued to each agent role, with scoped permissions, delegated user context carried on every action, short-lived credentials from a broker, a registered owner and lifecycle, and audit logs that name the agent and the user it acted for, managed in the identity platform you already run.
Identity teams have managed non-human identities for years: service accounts, workload identities, pipeline credentials. AI agents are a new subclass with three properties that break old habits. They take actions on their own initiative within a role; they usually act on behalf of a specific person; and they can be steered by content they read. An agent running on a shared service account or a human's session is therefore both unaccountable and over-privileged. This guide sets out identity for agents done properly, expanding the agent identity and access control whitepaper and applying it inside the identity platform you already run.
Why do agents need identities of their own?
| Need | Without a distinct identity | With one |
|---|---|---|
| Accountability | Actions attributed to a person or a shared account | Every action names the agent role and version |
| Least privilege | Inherits a human's or a service account's full access | Permissions scoped to the role's tools |
| Delegation | Cannot distinguish acting for user A from user B | Delegated context on every call |
| Revocation | Cannot stop one agent without breaking others | Disable one identity |
| Audit | Logs are meaningless | Logs are evidence |
| Steering damage | A redirected agent has broad access | A redirected agent is bounded by its role |
How should identities be issued?
Through the platform's workload-identity mechanism (for example, frameworks in the SPIFFE family or cloud service principals), one identity per agent role, registered in the agent registry with owner, role description, tools, classifications, and delegated-context rules. Identities are verifiable and issued by the platform, not static keys pasted into configuration.
How does delegated context work?
The user's identity enters the runtime with the request; the runtime exchanges it, using standard token-exchange flows such as OAuth 2.0 token exchange, for a token naming both the agent role and the user; every tool call presents that token; the tool layer enforces the intersection of what the role may do and what the user may do. Where a legacy system cannot evaluate two principals, the gateway performs the user-entitlement check before the call. The gateway design is in how to build an MCP gateway.
How are permissions scoped?
Per tool, classified by consequence: read-only principals for reads, narrowly scoped writers for reversible writes, consequential actions as separate tools with separate principals withheld from most roles and gated for the rest. Design detail is in how to design tool permissions for AI agents.
How are credentials handled?
Brokered and short-lived. The runtime authenticates with the agent identity, requests a credential scoped to the tool and the delegated user, uses it, and lets it expire; the broker logs issuance. No long-lived secret lives in configuration, prompts, or context. See secrets management for AI agents.
What is the lifecycle?
| Stage | Action |
|---|---|
| Register | Registry entry: owner, role, tools, classifications, delegation rules |
| Provision | Identity and scoped principals; no shared accounts |
| Review | Scheduled attestation by the owner; unused permissions removed; agents included in the same cadence as human access |
| Change | Tool or scope changes reviewed; gaining a consequential tool is a gated change |
| Incident | Central disable of the identity; credentials revoked; see AI agent kill switch design |
| Retire | Identity revoked; registry archived with history |
What must be logged?
Agent identity and version; delegated user; tool and classification; parameters and target record (redacted); approval status and approver; outcome; trace identifier linking to the full execution trace. The trace pipeline is described in how to build an agent trace analysis pipeline.
How does this reuse the existing identity platform?
Register agents as a principal type in the directory or workload-identity system; extend the schema with owner, role, classifications, and delegation rules; reuse conditional access, access reviews, and SIEM integration; and put enforcement in the gateway for systems that cannot evaluate agent principals natively. A parallel stack for agents means a second inventory, a second review process, and a second thing for auditors to question.
What are the common mistakes?
- Agents under human sessions.
- One service account for all agents.
- Static credentials in configuration.
- Access reviews that skip agents.
- A parallel identity stack.
- No registry, so nobody can list what agents can reach.
- Identities issued per deployment, creating sprawl that hides which role actually acted.
How does FISTA Solutions help?
FISTA Solutions implements agent identity inside client identity platforms as part of its AI enablement practice, with forward deployed engineers working alongside identity and security teams, and every AI agent FISTA delivers carries its own identity, delegated context, and brokered credentials from day one. FISTA has delivered 150+ projects for 50+ companies across 12+ countries.
To review how your agents are identified today, message FISTA on WhatsApp, or read MCP security risks for how identity fits the tool layer.
Share-ready article cover
Download the generated social format.
Clear answers
Questions raised by this field note.
Straightforward guidance for evaluating scope, fit, and the next step.
01What is a non-human identity?
A security principal representing software rather than a person: a service, a workload, a pipeline, or an AI agent, with its own credentials, permissions, owner, and lifecycle. Agents are a distinct subclass because they take actions on their own initiative within a role, often on behalf of a specific user, and can be influenced by the content they read.
02Should each agent instance have its own identity?
Each agent role should. Instances of the same role share the role's identity and permissions, differentiated by delegated user context and trace identifiers. Identities per deployment or per copy create sprawl without adding control; identities shared across roles destroy the ability to scope and revoke.
03How does delegated context work in practice?
The user's identity is carried into the agent runtime and exchanged for a token that names both the agent role and the user, using standard token-exchange flows. Every tool call presents it, and the tool layer or system enforces the intersection. Systems that cannot evaluate two principals get the check at the gateway.
04What do auditors expect?
An inventory of agent identities with owners and permissions, evidence of least-privilege scoping per tool, records of scheduled access reviews that include agents, logs tying actions to an agent identity and a delegated user, and revocation procedures with test evidence. These mirror expectations for any privileged non-human identity.
Continue exploring
Related capabilities
Start with the hard problem
Need the outcome owned, not merely analyzed?
Tell us where delivery is constrained. We’ll map the fastest credible path from intent to verified production.