TL;DR: Intent-based access control is trying to turn an AI agent’s goal into an authorization decision, but the hard problem is whether the “intent” belongs to the subject or the acting agent, according to IndyKite. When intent is formalised as access requests, governance shifts from prompt interpretation to validating delegated actions against a stable subject-goal model.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on IndyKite's blog post: Intent based access control becomes an authorization model for agentic AI when subject intent is separated from agent behaviour.
Why it matters: IAM, PAM, and agent governance teams need a way to decide whether an AI action matches delegated authority, not just whether the prompt sounded plausible.
Context
Intent based access control is an authorization pattern for AI systems that tries to compare what a user wanted with what an agent actually does. The governance gap is not only whether the agent is allowed to act, but whether the action is still aligned with the original request once tool use and execution are delegated. For agentic systems, that distinction matters because the decision boundary moves from a human approval step to runtime behaviour.
The deeper issue is that “intent” is being used to mean two different things: the subject’s goal and the agent’s inferred purpose. Those are not interchangeable in governance terms, because only the subject’s request can be tied back to a human or machine principal with an accountable access context. AI agents vs agentic AI helps frame why that distinction matters once systems move from chat to delegated action.
Once intent becomes an access request, the problem stops being linguistic and becomes structural. The question is whether the policy engine can normalize a goal into subject, action, resource, and context without assuming that a model can reliably infer motive on its own.
Key questions
Q: How do I control what an AI agent is allowed to do based on policy intent?
A: Enforce intent-based access control by turning the initiating request into a policy object that includes the subject, action, resource, and context. The authorization decision should validate each delegated tool call against that original request, not against a later interpretation of the agent’s purpose. That keeps control tied to accountable delegation rather than prompt wording.
Q: What is the difference between subject intent and agent intent?
A: Subject intent is what the human user or accountable principal asked for. Agent intent is what the software agent infers, optimises, or decides at runtime while carrying out that request. The gap matters when an agent expands scope, combines tools, or selects a higher-risk action that the subject did not explicitly authorise.
Q: How does intent get normalized into policy decisions?
A: Intent is normalised by translating the request into policy inputs such as subject, action, resource, and context, then evaluating those inputs against access rules, risk signals, and delegation boundaries. The decision engine can allow, deny, constrain, or require step-up approval when the inferred agent action exceeds the original authorisation.
Q: What happens when an AI agent acts beyond the original request?
A: When an AI agent acts beyond the original request, it has exceeded delegated authority and may trigger a policy violation, escalation, or revocation. Common controls include action allowlists, scoped tool permissions, approval gates, and auditable logs that show the human accountable for the agent’s runtime decisions.
Technical breakdown
Why intent becomes an authorization problem
Intent-based access control treats a prompt as evidence of a desired action, then checks whether the resulting tool calls stay within that scope. In practice, that makes intent a policy object rather than a language understanding problem. The article’s core move is to reduce free-form goals to access requests so the system can compare a declared purpose with actual execution. That works only when the requested action can be mapped cleanly to a known resource and policy context.
Practical implication: Design authorization logic around explicit subject-action-resource-context tuples instead of trying to interpret natural-language prompts directly.
Subject intent versus agent intent in delegated action
Subject intent is the goal expressed by the human or long-lived machine that initiated the workflow. Agent intent is the runtime behaviour the delegated system exhibits while trying to satisfy that goal. Those are different governance objects because the subject can be accountable while the agent can drift, overreach, or take a broader path than intended. The article argues that the safe control point is the subject’s request, not an inferred reading of what the agent “meant.” Read AI Agents vs Agentic AI.
Practical implication: Treat delegated action as a scope-checking problem and bind every tool call back to the originating subject request.
Normalising intent into access requests
The article proposes that intent can be represented as a set of access requests using OpenID AuthZEN-style tuples. That matters because authorization systems already know how to evaluate who the subject is, what action is requested, which resource is involved, and under what context the decision is made. This normalisation turns intent from an abstract goal into a policy input that can be evaluated deterministically. It also avoids letting the agent invent its own interpretation of the task. See the Agentic AI Identity Guide.
Practical implication: Use a normalized request model so policy enforcement can evaluate delegated AI actions consistently across tools and workflows.
NHI Mgmt Group analysis
Intent based access control is really an accountability model for delegated AI. The useful unit is not the prompt but the subject’s authorization context, because that is what ties action back to an accountable principal. Once an agent can take multiple steps after the initial request, the governance problem becomes whether every step still fits the original delegation. Practitioners should treat IBAC as a control over delegated authority, not as a language-plausibility filter.
Subject intent is the governance anchor; agent intent is only evidence. If the agent’s inferred purpose is allowed to redefine the decision, the policy boundary becomes circular. The article is pointing to a structural issue in agent governance: runtime behaviour can diverge from the initiating goal even when the original request was valid. That means access control must stay tied to the subject’s request context, not to a model’s later explanation of what it was trying to do.
OpenID AuthZEN-style normalization is the real enabler here, not prompt analysis. Access decisions become tractable when intent is reduced to subject, action, resource, and context. That approach aligns AI governance with established authorization practice instead of inventing a separate semantic layer for every agent. Practitioners should recognize this as an authorization architecture choice, not a new kind of reasoning engine.
Domain grounding is a control on scope drift, not a substitute for authorization. Limiting an agent to its relevant knowledge domain can reduce nonsensical requests, but it does not by itself prove the action is permitted. The stronger point is that governance should reject requests outside the agent’s operating domain before policy evaluation even begins. That keeps intent evaluation focused on legitimate business actions rather than speculative prompt interpretation.
In agentic systems, policy has to govern the delegation chain, not just the endpoint action. A human or machine subject may set the goal, but the agent executes the sequence. That creates a governance handoff that conventional IAM does not model well enough on its own. The practical conclusion is that authorization must follow the delegation path end to end.
From our research library:
- Only about one-third of approximately 500 organizations surveyed by McKinsey in 2026 report maturity level three or higher across agentic AI governance controls.
- Read next: Agentic AI Identity Guide
What this signals
Delegated AI will force authorization teams to move from prompt inspection to policy-bound execution. Once an agent can convert a single request into several tool calls, the real control point is no longer the language input but the delegated action sequence. That shift makes subject-bound authorization the deciding governance model for agentic systems, not an optional enhancement.
Intent drift becomes a design constraint when agent behaviour is allowed to unfold at runtime. Policy has to assume that the task may expand, split, or be reframed during execution, which means static review of the original prompt is insufficient. Governance programmes should prepare to validate every downstream action against the initiating principal’s request context.
Subject-goal binding: The practical control pattern is to keep the subject’s request, the agent’s action sequence, and the authorization decision inseparable. That reduces ambiguity when multiple agents or tool calls participate in one task and makes delegated authority auditable.
For practitioners
- Define subject intent as the policy source Base delegated AI authorization on the subject’s request context, not on an inferred reading of the agent’s own objective.
- Normalize prompts into access requests Map agent requests into subject, action, resource, and context fields so policy can evaluate them deterministically.
- Restrict evaluation to the agent’s operating domain Reject prompts that fall outside the organization’s intended knowledge or task domain before they reach authorization logic.
- Bind every tool call to the initiating principal Preserve delegation context across multi-step agent workflows so downstream actions remain traceable to the original subject.
Key takeaways
- Intent-based access control makes the subject’s request, not the agent’s inference, the basis for delegated authorization.
- The article’s central governance point is that agentic systems can drift from the initiating goal during execution, so policy must follow the delegation chain.
- Normalizing intent into access requests gives teams a deterministic way to validate AI tool use against authorized scope.
Related NHI Mgmt Group resources: AI Agents vs Agentic AI · Agentic AI Identity Guide · Agentic AI Identity Maturity Model · Top 10 Agentic AI Identity Issues
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 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent intent versus subject intent is an identity and privilege boundary issue in delegated AI workflows. |
| Recommendation — Bind delegated AI actions to the originating subject and reject privilege expansion beyond that scope. | ||
| NIST AI RMF | GOVERN — AI Governance and Accountability | Intent-based access control is a governance model for accountable AI decision making. |
| Recommendation — Establish governance for how AI actions are authorized, reviewed, and attributed to a accountable principal. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Delegated AI actions rely on trustworthy identity context and authorization boundaries. |
| Recommendation — Verify that the agent’s identity context matches the subject and the permitted request scope. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about how permissions are decided for delegated AI actions. |
| Recommendation — Align AI tool authorization with documented entitlements and the request context that justified them. | ||
Key terms
- Intent-Based Access Control: An access control model that evaluates not just what an agent is requesting, but the inferred intent and context behind the request, granting or denying access based on whether the action aligns with the agent's declared purpose.
- Subject Intent: Subject intent is the purpose or outcome a human principal or requester meant to achieve when authorising an action. In autonomous access control, it is the baseline used to compare the agent’s inferred runtime decisions against the approved scope, so policy can detect overreach or unauthorised expansion.
- Agent intent: The immediate goal implied by an AI agent’s current sequence of tool calls. Unlike static automation, intent can change at runtime, which is why identity governance for agents has to look beyond permission sets and toward execution-time behaviour.
- OpenID AuthZEN: OpenID AuthZEN is a standard for asking and answering authorization questions in a consistent way across systems. It defines an interoperable interface so applications and policy engines can exchange decisions without custom integration logic. The aim is to make authorization more portable, auditable, and easier to govern at scale.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or AI governance programme, it is worth exploring.
Published by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org