Runtime Policy Enforcement for AI Agents

Why prompts can't enforce enterprise policy

A prompt can tell an agent which actions are expected, but the model can misunderstand the instruction, be influenced by untrusted context, or choose an unexpected tool path. The same system that proposes an action shouldn't be the final authority on whether it is permitted. Put deterministic identity, authorisation, validation, and policy checks outside the model at the boundary where data moves or a business-system action is attempted.

What the policy decision should evaluate

A useful action-time decision includes more than the tool name. It should consider which agent and version is acting, who requested the work, which owner and use case apply, the target system and record, the action type, the resolved arguments, sensitive-data classes, current business state, and the active policy version. The exact inputs depend on the workflow, but the organisation should be able to explain why the action was allowed, changed, blocked, or escalated.

• Principal: agent, person, service, owner, and delegation context
• Resource: system, organisation, record, field, tool, or destination
• Action: operation, arguments, amount, volume, and reversibility
• Context: purpose, environment, risk tier, time, and current state
• Policy: approved version, applicable rule, result, and reason

Use more than allow and deny

Policy can preserve useful automation by returning an outcome suited to the risk. Allow the action when it is inside authority. Transform the request when protected fields must be removed. Narrow the scope when only part of the request is permitted. Block an unauthorised or unsafe action. Route higher-impact work to a human. Stop the run when the integrity of the control path is uncertain. The agent must be designed to handle each result without leaking internal governance mechanics to the customer.

Apply data policy before the restricted destination

Data control must run before sensitive information reaches a model, tool, provider, or evidence store that shouldn't receive it. The correct point can differ across steps in the same run. A customer identifier may be needed for a CRM lookup but removed from a model prompt. A full card number shouldn't be copied into a ticket or trace. Record which configured control was applied and preserve enough context to review the decision without recreating the exposure.

Make failure behaviour explicit

Runtime enforcement depends on policy services, identity, integrations, and target systems. Decide what happens when a dependency is slow, unavailable, or returns an ambiguous result. Consequential actions may need to fail closed or move to review, while low-risk reads may use a bounded fallback. Define retry limits, duplicate-action protection, timeout behaviour, and evidence for the failure. A control path is production-ready only when its degraded state is understood.

Test with an action that should be stopped

A credible test includes a normal request, a boundary condition, and an attempted violation. For the refund workflow, verify that the agent can read the order and eligibility, issue a refund inside its approved threshold, block a refund above the threshold, and create the authorised review ticket. Inspect the target systems to confirm that the blocked action did not occur. Then inspect the evidence to confirm the identity, amount, policy, block reason, fallback, and customer-facing outcome are connected.

A decision envelope for consequential actions

The enforcement point needs a resolved request, not a sentence saying the agent intends to help. Assemble the decision from authoritative context and return an outcome the workflow knows how to handle. A reviewer should be able to explain the result without private chain-of-thought.

• Who: requesting principal, agent, owner, runtime, and delegation chain
• Why: approved use case, current job, and bound business record
• What: target system, resource, operation, arguments, amount, and data classes
• State: verified prerequisites, prior steps, environment, and target-system status
• Policy: active version, matching rules, conflicts, and confidence in required attributes
• History: relevant reviewed precedent, where configured, treated as evidence rather than authority
• Result: allow, transform, narrow, review, block, or stop with reason and fallback