Identity, intent, and context are the three inputs a policy engine needs to decide whether an action should be allowed. For agentic AI, identity alone is insufficient because the same actor can pursue different goals through different tools at different moments.
What the Policy Engine Is Really Evaluating
Identity, intent, and context are separate inputs because each answers a different question: who is acting, what they are trying to do, and under what conditions the action is being requested. A policy engine that treats any one of those signals as sufficient will either block legitimate work or allow unsafe actions.
This matters because modern policy decisions are rarely binary. The same actor may be trusted for one action, denied for another, or allowed only when the surrounding context supports the request. In practice, the decision is about the combination, not any single signal in isolation.
Why Identity Alone Is Not Enough
Identity proves the actor, but not the purpose. That distinction is especially important in agentic systems, where the same agent can hold stable identity while pursuing different goals through different tools, prompts, or workflows.
When identity is overused as the main control input, organisations tend to create coarse allowlists or blanket denials that miss the actual risk. A policy engine needs to know whether the request fits the actor’s current purpose and whether the surrounding conditions make the action appropriate.
For a policy decision to be reliable, intent must be evaluated as a first-class signal rather than inferred from identity alone. Context then supplies the situational checks, such as the target resource, environment, time, trust boundary, or risk posture.
How Intent and Context Change the Decision
Intent narrows what the actor is trying to accomplish, while context constrains whether that action should be allowed right now. Together they help distinguish ordinary usage from misuse, even when the requester is authenticated and otherwise legitimate.
That is why policy design usually becomes more precise as it moves from static identity checks to request-level authorisation. A request for data export, privilege elevation, or tool invocation may be acceptable in one workflow and inappropriate in another, even if the same identity is involved.
This is also where Model Context Protocol authorization becomes relevant: it formalises how a server should evaluate requests with scoped, audience-bound access rather than assuming broad trust from the client side.
Policy Design Implications for Agentic AI
Agentic AI makes the identity, intent, and context model more visible because tool access is dynamic and goals can shift across a session. The right control point is not just “is this the same agent?”, but “is this the right action, for this goal, in this state, against this resource?”
That framing also explains why policy must be able to distinguish permitted delegation from unsafe autonomy. Without intent-aware and context-aware controls, an agent may legitimately authenticate yet still make an unsuitable or excessive request.
Useful policy systems therefore separate authentication, authorisation, and runtime judgement. Identity establishes the caller, intent describes the requested outcome, and context determines whether the request fits the governing rules.
Risk and Threat Considerations
When intent and context are weakly enforced, the main risk is over-permission: a valid identity can still perform the wrong action at the wrong time. In agentic workflows, that can turn a trusted session into a broad abuse path because the policy layer fails to distinguish purpose from possession of credentials.
Failure mechanism: attackers, misconfigured agents, or overbroad workflows exploit policy designs that check identity but not goal, session state, resource scope, or request context.
Impact: this can enable tool misuse, privilege abuse, data exposure, and actions that look authorised on paper but are unsafe in the actual operating context.
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 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent identity alone is insufficient when goals and tool use vary at runtime. |
| ASI02 — Tool Misuse | Intent and context determine whether a tool invocation is appropriate and safe. | |
| Recommendation — Require request-level authorisation checks that account for agent goal and privilege changes. Restrict tool calls by purpose, scope, and session context before execution. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Policy must limit actions to the minimum authority needed for the current request. |
| IA-5 — Authenticator Management | Identity is one input, but authenticators only establish who the caller is. | |
| AC-3 — Access Enforcement | Policy engines enforce allow or deny decisions based on identity, intent, and context. | |
| Recommendation — Enforce least privilege so identity alone cannot unlock excess action rights. Manage authenticators securely and pair them with separate authorisation decisions. Apply access enforcement rules that evaluate the full request context before allowing action. | ||
Practitioner Guidance
Why practitioners should care: the core governance question is not only “who is calling?” but “under what intent and conditions should this caller be allowed to act?” Treating those as separate policy dimensions reduces both false trust and unnecessary friction.
Common misunderstanding: many teams assume strong authentication is enough for safe authorisation. In practice, authenticated actors still need request-level checks that account for purpose, scope, and current context.
Practitioner takeaway: design policy so identity establishes the actor, but intent and context decide whether the action is appropriate.
Related resources from NHI Mgmt Group
- Why do AI logs need identity context for regulatory compliance?
- How can SOC teams use identity context to improve response to agent activity?
- How should security teams handle identity decisions when business context changes quickly?
- Why does Model Context Protocol create identity risk for enterprises?