Identity identifies the actor. An intent passport defines the actor’s authorised behaviour, including purpose, data scope, time window, risk level and revocation rules. One answers who is acting, while the other answers what that actor may do, under what conditions and for how long. They solve different governance problems.
Identity answers who the agent is, intent passport answers what it may do
An AI agent’s identity is the actor record: the thing that lets a system recognise, authenticate, track and attribute that agent across sessions and tools. An intent passport is the policy envelope around that actor’s behaviour. It should bound purpose, data access, time window, privilege, revocation and approval conditions so the agent can act only within declared limits.
That distinction matters because identity alone does not say whether an agent may read customer data, send money, alter records or call sensitive tools. Intent does. In practice, the passport becomes the control plane for runtime authorisation, while identity remains the stable handle used to prove and monitor which agent is acting.
How identity and intent diverge in day-to-day governance
Identity is relatively durable. It is created, registered, authenticated, rotated, disabled and audited like any other governed actor. The intent passport is more situational. It can change by task, workflow, environment or risk level, and it should expire when the job ends. That makes the passport closer to a delegated authority statement than to an account profile.
They also fail differently. Weak identity creates confusion about who or what is acting. Weak intent creates overreach, where a valid actor performs actions that are technically authenticated but not properly authorised for the present context. For a useful comparison, the identity layer tells you which agent identity model is in use, while the intent layer tells you how that actor’s permissions should be scoped and revoked.
In well-run deployments, the two are intentionally separable. One agent identity can carry multiple intents over time, and one intent can apply to different agents if the governance model allows it. But they should never be conflated, because a reusable identity without a bounded intent becomes a standing permission problem, not an accountability solution.
Why the separation matters for control design and auditability
A clean split between identity and intent lets teams ask two different questions during review: can we trust this actor, and should this actor be doing this now? That distinction improves policy design, incident investigation and exception handling. It also makes it easier to revoke a dangerous behaviour without necessarily deleting the actor’s identity record, which is useful when the same agent still has legitimate work elsewhere.
The same logic underpins AI agent authorisation: policy should be evaluated per action, not assumed from the existence of an authenticated agent. It also supports Zero Trust for AI Agents, where the agent, the principal and the request are continuously verified instead of being treated as permanently trusted after login.
For auditability, intent is often the more important artefact. Identity answers attribution, but intent explains why a given action was allowed. That is what investigators, approvers and control owners usually need when they review a high-impact operation. An identity record without a current intent record is incomplete for governance purposes.
Risk and Threat Considerations
The main risk is privilege drift: an authenticated agent keeps a valid identity while its behaviour slowly expands beyond the original purpose, data scope or approval window. That creates overreach even when the agent is not compromised, and it gives attackers a larger blast radius if the identity or its credentials are abused.
Failure mechanism: When identity and intent are merged, teams tend to grant broad, durable access because they can recognise the actor but have not encoded the current task boundary. The result is standing authority that outlives the workflow, plus weaker detection when the agent performs actions that were never meant to be in scope.
Impact: Mis-scoped agents can expose data, modify systems, trigger unauthorised transactions or create hard-to-revoke access paths. A compromised or misdirected agent is then harder to contain because the identity appears legitimate even when the behaviour is no longer authorised.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Intent passports bound agent actions to the minimum required authority. |
| IA-9 — Service Identification and Authentication | AI agent identity concerns machine or service authentication and attribution. | |
| IA-5 — Authenticator Management | Identity and intent both depend on controlled credential lifecycle and revocation. | |
| Recommendation — Enforce least privilege so each agent action is limited to the current task and context. Authenticate each agent as a distinct service identity before allowing tool access. Rotate and revoke agent credentials when the passport expires or scope changes. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | The question contrasts stable identity with per-request authorised behaviour. |
| Recommendation — Verify the agent and the request continuously, not once at login. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent identity without bounded intent can lead to excessive authority and misuse. |
| Recommendation — Constrain agent privileges per action so authenticated identity cannot overreach. | ||
Practitioner Guidance
What to prioritise: Treat intent as a first-class control, not a comment field. The minimum useful test is whether you can state, for each agent action, the allowed purpose, data classes, expiry and revocation condition without referring to the original human owner.
What to verify: Check that the intent passport is machine-enforceable at the point of use, not just documented at onboarding. If the platform cannot block an out-of-scope action in real time, the passport is descriptive, not controlling.
Common mistake: Teams often assume a strong identity layer is enough and then discover that a perfectly known agent can still do the wrong thing. Identity supports attribution; intent controls behaviour. Both are needed, but they are not interchangeable.
Practitioner takeaway: If you can change what an agent is allowed to do without changing who it is, you are managing intent correctly. If every policy change requires reissuing identity, the design is too coarse for safe delegation.
Related resources from NHI Mgmt Group
- What is the difference between human identity governance and AI agent governance?
- What is the difference between patching a vulnerability and reducing identity blast radius?
- What is the difference between scanning AI-generated code and governing AI agent identity?
- What is the difference between a service account and an AI agent identity?