Runtime policy enforcement for AI agents: from Permit to proven outcome

The policy said Permit. The payment still broke policy.

A manufacturer's procurement analyst asks for a corrected payment on a disputed invoice. The application gathers the invoice, purchase order, supplier record and verified bank account. A model extracts the correction, and a calculation sets the payable amount at $48,000.

Policy is checked. The result is Permit, with conditions: an eligible manager must approve; pay only the verified account; keep the amount at or below $50,000; re-evaluate if the amount, beneficiary or legal entity changes; keep the evidence.

A manager approves the exact $48,000 proposal. The work then waits for the next payment window. During the wait, a downstream mapping applies a tax adjustment and the payload becomes $52,800. Nothing about the workflow's shape changed. The business proposition did.

When the work resumes, the runtime sees a stored Permit and a completed approval and treats both as booleans. A worker with a broad service credential calls the treasury API. It pays $52,800 and returns success.

Every component did its job. The policy engine answered correctly for the facts it saw, the manager approved what was shown, the API executed what it received, and the trace has no errors. The audit trail holds a valid Permit and a valid approval, and no evidence that the final action satisfied either.

Is a policy decision the same as enforcement?

No. A decision says what should be allowed for one specific proposition. Enforcement is the step that actually stops, changes or lets through the action, and proves that only the approved action happened.

Authorization standards have long split these roles. A policy decision point evaluates facts against rules. A policy enforcement point sits where the action can actually be controlled and applies the result. Administration manages the rules; information sources supply the facts.

That split is healthy, because rules and application code change for different reasons. It becomes dangerous when an application treats "we called the policy service" as the end of governance. A decision applies to a proposition: this actor, doing this action, on this record, for this purpose, in this state. Change any of those and the decision may no longer apply.

Agents stretch the gap between decision and action. Model calls, context assembly, human review, queues, sub-workflows, retries, mappings and multi-day waits all sit between the check and the change. One early check can't govern all of that unless the runtime keeps exactly what was decided and confirms it still applies at the step that creates the effect.

A decision is more than Permit or Deny

Reducing authorization to allowed = true throws away what you need to enforce it. Standards such as XACML already return decisions with obligations and advice. In an agent workflow, the decision also needs to be tied to the exact thing it governed.

Conditions must actually run

A policy condition (an "obligation" in standards language) isn't a note attached to a Permit. It's something the system must do for the Permit to hold: redact fields before a model call, require a second approver, cap an amount, use a private deployment, keep a receipt, re-check at commit.

One decision often needs several steps to honor it. Context assembly removes restricted data, model routing picks an eligible region, the approval step enforces separation of duties, and the write step caps the amount. So the runtime has to split the conditions, send each to a step that can enforce it, and refuse to advance if any mandatory condition can't be met.

Where should policy be enforced in an AI agent workflow?

At every step that can disclose data, change what a model sees, choose a tool, record an approval, resume after a wait or change a system of record. A single gateway at the front door can't control any of the later steps.

The tool exposure and write rows are where most agent incidents land. For a fuller treatment of the tool layer, see governing AI agent tool calls.

Policy has to survive time

A decision has a decision time. Enforcement happens later, and the real-world effect later still. Between them sit seconds, days, a human review or an ambiguous callback. In that interval the actor's authority can expire, the rules can change, the record can be updated, the proposal can be recalculated, or another case can make a competing change.

Neither "always use the original rules" nor "always use the latest" is correct. A regulated calculation may intentionally stay on the rules it started under; a spending limit should reflect today's. Each workflow version should declare which facts stay bound to the past and which must be rechecked now.

Typical re-evaluation triggers:

• a change of actor, delegation, tenant, legal entity, record, action or purpose;
• a change in amount, beneficiary, terms or evidence;
• a newer revision of the target record, or a competing change to it;
• a rule, approval, model route or classification change declared material;
• expiry, revocation or a step-up requirement;
• an uncertain earlier outcome that must be reconciled before another attempt (see retries and idempotency).

In the payment example, the tax adjustment changed the amount. That should have invalidated both the decision and the approval and sent the case back for review.

Approval is a policy condition, not an email

When policy calls for human judgment, the approval has to be durable workflow state, not a notification. Keep the exact proposal and evidence shown, the approver and their authority, the separation-of-duties result, the rule version, the expiry, and the specific action the approval permits. If the amount, beneficiary, record, legal entity, contract text or evidence changes materially, the approval no longer satisfies the condition. The work returns to review. For more on this, see human-in-the-loop approval.

Can a prompt enforce policy?

No. A prompt can shape what a model tries to do, but it can't prevent or prove anything. Policy has to be enforced by the runtime around the model, at the steps that touch data and systems.

You can tell a model not to reveal restricted data, not to exceed a limit, or to ask for approval before using a tool. That may improve behavior. But the model can misread the instruction, be steered by content it retrieved, produce an invalid tool request, or decide a review is unnecessary. The OWASP agentic risks list goal hijack and tool misuse for exactly this reason.

So an agent's plan or tool call should enter the runtime as data: a proposal. The enforcement point then checks the delegated authority, record, action, purpose, proposal and state before anything happens. Models recommend. The application's authority decides.

Distributed enforcement, one meaning

Sub-workflows, async workers and external services often have their own enforcement points, and that's good: enforcement belongs near the thing it controls. But distribution can't mean each component inventing its own reading of the rules. The workflow definition should make the applicable rules, required facts, condition meanings and evidence expectations explicit.

A child workflow can't reuse a parent's decision just because it shares a tenant or service identity. A decision bound to one record, action or proposal stays bound to it. And when a downstream API can't understand delegated authority or conditions, the runtime must enforce them before the call and record enough to link the business authority to the effect.

Caching decisions is fine when the cache key includes every input that matters: tenant, record, proposal, rule version, time and assurance level. The conditions travel with the cached result. A cache that stores only "Permit" discards the very conditions that made it valid.

A decision log isn't proof of enforcement

A decision log shows what the policy engine received and returned. That's one layer. You also need to show what the enforcement point actually did, and what happened in the real world.

With all three linked, an auditor can follow one line from the rule to the confirmed change. Without the second and third, the payment case looks clean on paper.

Common anti-patterns

Ten rules for runtime policy enforcement

1. Declare an enforcement point at every step that can disclose, decide or change.
2. Bind each decision to the exact actor, record, action, purpose and proposal.
3. Store decisions as structured records, never a single boolean.
4. Treat conditions as work that must run; if one can't, stop.
5. Re-evaluate whenever anything material changes, and before the write.
6. Bind human approvals to the exact proposal and rule version.
7. Treat prompts, plans and tool calls from models as proposals.
8. Cache decisions only with every material input in the key, conditions included.
9. Record the decision, the enforcement and the confirmed effect, linked.
10. Make it visible where policy is decided, where it's enforced and what proves it.

The result: policy becomes behavior

Policy can't stay a detached rules service around an opaque process. The application has to keep the proposition policy evaluated, carry its conditions to the steps that must honor them, enforce it against the exact action, and keep evidence of what happened.

That doesn't mean every action is centrally approved or every step calls one service. It means the runtime can't lose the policy meaning that made an action legitimate. A policy decision says what should be allowed. Enforcement at run time proves that only that happened.