Identity, Intent, and Context

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.

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?