AI Agent Enforcement Has an Intent Problem

An AI agent is authorised to use a refund tool. It invokes the approved tool, under its own identity, with a valid credential.

The permission check says yes.

But the refund no longer serves the purpose for which that authority was granted. Perhaps the order is ineligible. Perhaps the conversation has moved to a different customer. Perhaps the agent is trying to preserve a satisfaction score rather than resolve a covered loss.

The tool is the same. The agent is the same. The permission is the same. The answer should still change.

This is the enforcement gap that appears when an enterprise governs an agent as a list of allowed actions instead of an actor operating within a specific purpose.

Permission to act is not permission for every purpose

Traditional access control asks an essential question: may this identity perform this operation on this resource?

That question remains necessary. It is not always sufficient for an agent.

An agent can plan, interpret changing information, select tools and continue through a generated sequence of steps. Its next action may be technically inside its permission set while no longer being relevant to the job the enterprise approved.

Consider an agent authorised to issue refunds below $100 for verified, policy-eligible damaged orders.

A coarse permission model sees two identical authorised actions. A purpose-bound model sees two different decisions.

The missing decision input is the job

The enterprise did not grant the agent an abstract right to issue refunds. It delegated authority to perform a job under defined conditions.

That delegation should bind together:

• The accountable owner and requesting principal
• The agent identity and approved use case
• The business purpose of the run
• The systems, records and tools the job may use
• Action types, arguments and thresholds
• Relevant workflow and resource state
• Data-handling requirements
• The conditions that require a block, fallback or human review

The enforcement decision should therefore ask:

Is this agent authorised to take this action on this resource, now, for the purpose and context of this run?

That is different from asking whether the tool appears on an allowlist.

Contextual authorisation is not a new idea

Security standards already recognise that authorisation can depend on more than an identity and operation.

NIST SP 800-162 describes attribute-based access control using attributes of the subject, object, requested operation and environmental conditions. The Open Policy Agent documentation likewise describes fine-grained, context-aware policy decisions.

The agent-specific problem goes further in one important way. The relevant context is not only time, location, role or resource. It includes the purpose of a delegated job and the sequence of events that led to the proposed action.

An agent creates that sequence dynamically. The enterprise may not know every valid step in advance, but it still needs to decide whether each consequential step remains inside the approved job.

That is why the useful question is not whether anyone has ever considered contextual access control. They have. The emerging problem is how to bind generated agent behaviour to business purpose throughout a live run.

Deterministic controls are necessary but need the right inputs

A deterministic system can enforce contextual policy when the relevant context has been made explicit. It can block refunds above a threshold, prevent access to another tenant, require a verified eligibility state, limit network destinations or deny an action outside business hours.

The weakness appears when the policy decision receives only:

agent = refund-agent
action = issue_refund
permission = allowed

No decision engine can evaluate a purpose it cannot see.

The answer is not to replace deterministic controls with an unconstrained model that guesses what is safe. The stronger design combines several layers:

1. Hard authority boundaries. Identity, tools, resources, data classes, destinations, argument constraints and thresholds remain explicit and deterministic.
2. Purpose binding. The run carries an approved job, requesting principal, relevant case and expected outcome.
3. Context assembly. The enforcement point receives the current workflow state, target resource, tool arguments, prior steps and applicable policy.
4. Semantic risk evaluation. Where the purpose cannot be represented fully as fixed attributes, a bounded evaluator can identify inconsistency, novelty or ambiguity.
5. Safe resolution. The result can allow, transform, narrow, block or escalate the action. It is not restricted to one blanket yes or no for the tool.

The final execution boundary should remain outside the agent. The agent proposes an action. The governed path decides whether that resolved action may proceed.

Intent cannot mean trusting the agent's explanation

An agent saying “I need this refund to help the customer” is not reliable evidence of purpose.

Prompt injection, model error or goal drift can produce a convincing explanation. Purpose must be grounded in evidence the agent cannot rewrite at will.

Useful signals include:

• The original user request and the approved use-case record
• The principal that delegated the task
• The customer, order, claim or case bound to the run
• Verified facts retrieved from systems of record
• Workflow state and completed prerequisite checks
• The exact tool arguments and destination
• The sequence of attempted and completed actions
• The policy and authority version active at decision time

The system is not reading the agent's mind. It is testing whether the proposed action is consistent with the grounded job and current state.

What purpose drift looks like in practice

Purpose drift does not always look malicious. It often appears as a locally reasonable step that no longer belongs to the authorised job.

A service lookup becomes a marketing export

A support agent may read a customer record to resolve an active case. The same CRM read permission should not automatically authorise the agent to collect customers into a campaign list.

A claims action crosses into discretionary settlement

An agent may be authorised to process a claim when policy conditions are satisfied. The same payment action may require review when the agent is compensating for poor service or interpreting an exception beyond the approved claims rule.

A document request expands beyond the case

An agent may retrieve documents attached to one underwriting submission. It should not use the same connector to explore unrelated accounts simply because the integration credential can reach them.

In each example, denying the tool completely would make the agent useless. Allowing it everywhere would grant more authority than the business intended. Enforcement must preserve the useful action while constraining its purpose.

Marshal's role in the decision path

Marshal is Difinity's enforcement layer for evaluating a proposed agent action against the authority, policy and context that apply to the run.

The decision is not meant to stop at “this agent can call this tool.” Marshal's role is to evaluate the resolved action in relation to the current job, relevant system state and enterprise policy before the target system changes.

For a refund run, that can mean connecting:

• The refund agent's identity and owner
• The customer and order bound to the case
• Verified eligibility and amount
• The authority delegated to the agent
• The refund policy and active limits
• The proposed tool arguments
• The approved fallback if the action cannot proceed

The result can permit the refund, reject invalid arguments, block the action or route it to human review while preserving evidence of the decision.

Decision memory can add precedent without turning precedent into policy

A planned addition to Marshal is decision memory.

The objective is not to let the system approve an action because something vaguely similar happened before. It is to give a new decision relevant organisational history.

For the same agent, tool and action family, decision memory could surface:

• Prior approvals and denials in comparable contexts
• The policy version and owner behind those decisions
• Which facts made an action materially similar or different
• Whether the proposed action is common, exceptional or genuinely novel
• Previous escalations and their reviewed outcomes

Repeated, well-grounded approvals can reduce unnecessary friction. A novel combination, departure from precedent or history of escalation can raise the decision for review.

Decision history must remain a signal, not a source of authority. Otherwise one mistaken approval can reproduce itself. Useful safeguards include policy-version boundaries, expiry, confidence thresholds, reviewer identity, reason codes and a clear route to invalidate precedent.

The evidence trail must explain why the answer changed

If two apparently identical tool calls receive different outcomes, a reviewer needs more than an ALLOW or DENY event.

The evidence should connect:

• The agent, principal, owner and delegated job
• The action, target, arguments and relevant resource state
• The context used for the decision
• The policy and authority version
• Any prior-decision signal used
• The result and reason
• The fallback, human intervention and final business outcome

This makes context-sensitive enforcement accountable. It also lets teams identify a bad rule, incomplete context or inconsistent precedent instead of treating the enforcement layer as an unexplained oracle.

A practical test for purpose-bound enforcement

Use two runs with the same agent, tool, amount and credential. Change only the business context.

In the first run, satisfy every prerequisite for the approved job. In the second, remove one material condition or shift the purpose. Then verify that the platform:

1. Carries the approved purpose into the run.
2. Resolves facts from authoritative systems rather than trusting the agent's claim.
3. Applies deterministic boundaries before execution.
4. Detects when the proposed action no longer fits the current job.
5. Routes ambiguity or higher risk to a defined fallback.
6. Records enough evidence to explain why the decisions differed.

If both actions receive the same answer because the permission is technically valid, the platform is governing access to a tool. It is not yet governing the agent's use of that authority.

Frequently asked questions

What is intent drift in an AI agent?

Intent drift occurs when an agent's proposed action moves away from the purpose or outcome for which its authority was granted, even though the tool and operation may still be technically permitted.

Can deterministic policy enforcement catch intent drift?

It can catch contextual violations that are represented in its decision inputs and rules. It cannot evaluate omitted or ambiguous purpose. A robust design retains deterministic hard limits and adds grounded job context, semantic risk evaluation and human escalation where fixed rules are insufficient.

Should the system trust an agent's stated intent?

No. Purpose should be grounded in the original request, delegated job, systems-of-record data, workflow state, tool arguments and prior steps. The agent's explanation may be useful context, but it should not grant authority.

What is decision memory for agent enforcement?

Decision memory gives the enforcement path relevant history about comparable actions, approvals, denials and reviewed escalations. It can help identify precedent or novelty, but prior decisions should remain evidence rather than automatically becoming policy.

Does purpose-aware enforcement replace permissions?

No. Identity, permissions and hard policy boundaries remain foundational. Purpose-aware enforcement makes those controls more precise by evaluating whether an otherwise permitted action is appropriate for this job, resource and moment.

The next generation of agent enforcement will not ask only whether an action is authorised. It will ask what that authority was for.

Explore Difinity's governed agent platform or read the practical guide to runtime policy enforcement for AI agents.