Writing the Policy Rule That Catches What the File Missed

The loop starts with evidence, not a workshop. Your fallback already emits one event per catch. That event is your raw material, and it should carry more than "action blocked."

Log, at minimum: the agent identity, the requesting user, the tool name, the full arguments, the target resource, the environment (staging or production), the outcome, and the fallback reason. The Sweet Security guide to agent policy enforcement makes a similar point, that decision records should capture the requested action, agent identity, the context, the policy evaluated, the verdict, enforcement action, the timestamp and the outcome, because those fields are what make audit and tuning possible later (Sweet Security).

Then do the boring part: deduplicate. Group catches by (tool, argument signature, environment). A month of fallback events usually collapses to a dozen distinct signatures. That shortlist is your work queue, and it is finite.

Two filters save time:

• Reads first. Read-only actions caught by the fallback are almost always a misconfigured allow list, not a policy question. Classify them, permit them, and move on.
• Sensitive reads get redaction, not approval. A read of secrets or customer records should return a masked result rather than queue a human, which the NOFire guide to runtime policy enforcement spells out in its action tier table (NOFire AI).

What you are looking for is the third bucket: writes that recur. Those are the ones the fallback was never designed to handle indefinitely.

A named rule has five fields, and a rule missing any of them is a wish:

The owner field is where most rule sets fail. A rule owned by a team is owned by nobody; when it misfires, everyone assumes someone else is watching. Assign one person and one backup, the way GitLab requires named approvers with specific roles on protected branches rather than an open call for review (GitLab docs).

Write the condition against structured fields only. The AI SDK policy documentation draws the line clearly: numeric thresholds, scopes, allow lists and time windows are strong fits for a policy engine, while "do not use bad language" is a weak fit that is hard to verify and easy to bypass (AI SDK). If you cannot point at a field in the tool-call input and write an exact check on it, the rule is not ready; keep the fallback for that case and revisit.

Here is a rule that would replace a recurring fallback, in Rego:

package agent.call

# Anything unmatched is denied, not allowed.
default decision := {"decision": "deny", "reason": "no rule covers this action"}

decision := {"decision": "allow"} {
  input.tool.name == "billing"
  input.args.operation == "refund"
  input.args.amount_usd <= 200
  input.args.currency == "USD"
  input.args.environment == "production"
}

decision := {"decision": "requires-approval", "reason": "refund above auto limit"} {
  input.tool.name == "billing"
  input.args.operation == "refund"
  input.args.amount_usd > 200
}

Note the default. The AI SDK package normalizes "no matching rule" to allow unless you set a default deny, which is the single most consequential line in any policy file you will write (AI SDK). Start from deny, then carve out the permits you can justify.

This is the step teams skip, and it is the only one that keeps the loop honest. Before the rule ships, write a test case for the exact catch you pulled from the logs. The test asserts the decision the new rule should produce. It fails today because the fallback fires instead.

That inversion does two things. It proves the rule addresses the real action rather than a plausible one, and it gives you a regression test for the next time someone edits the policy. The AI SDK documentation explicitly calls out that policies can be tested in CI with opa test, independent of the SDK (AI SDK). Treat policy as a reviewable artifact with its own test suite, not a function buried in agent setup.

A workable test table for one rule:

Write at least one negative case per rule, the "this should still be stopped" case. Rules that pass every test are usually rules that permit too much.

A new rule does not close the gap by itself; you have to remove the fallback's claim on that action. Otherwise the catch keeps firing and you have added a rule on top of a net that still catches it.

After the rule ships, watch the fallback events for that signature. If the rule is working, the signature drops to zero. If it does not, the rule's condition is wrong, not the fallback. Give every new rule a checkpoint: if its signature still appears in fallback logs after a set window, the owner reopens the rule.

The same discipline applies to the fallback itself. Put an expiry date on the catch-all path. Anthropic's published framework for trustworthy agents, cited in the Scalekit write-up on approval gates, recommends agents prefer reversible actions and request narrower scope when reversibility is unclear (Scalekit). A fallback that survives its expiry date without review is the clearest signal that governance has stalled.

Where the fallback is doing real work and you cannot yet name a rule, make it safety-preserving rather than silent. If no approver responds within the window, deny by default. An approval that times out into execution is a gate that does not exist (Arthur AI).

Take a support agent that issues refunds. The original policy is a fallback: any refund not on the allow list needs approval. Logs show 340 catches in a month. Dedupe collapses them to four signatures.

Signature A: refunds under $200 in USD. 310 catches. This is not a policy question; it is a missing threshold. Name the rule refund.issue.under_200_usd, allow, owner the payments engineer, review date one quarter out. Test cases from the table above.

Signature B: refunds between $200 and $2,000. 24 catches. Name the rule refund.issue.under_2000_usd, require approval from the on-call support lead, with the approval expiring in one business day. This is where the human actually adds value, so keep the gate narrow and put the evidence in front of the approver: amount, order, customer tier, prior refunds.

Signature C: refunds in a non-USD currency. 5 catches. Deny for now, with a named owner and a note that multi-currency is a separate project. Deny is a legitimate rule: it is explicit, testable and visible.

Signature D: one-off refunds to a large enterprise account. 1 catch. Leave the fallback in place and schedule a review.

The arithmetic is the insight. After one loop, the fallback stops catching 311 of the 340 actions it used to see, and the 29 remaining catches are all cases where a human decision is genuinely correct. Reviewers go from rubber-stamping 340 prompts to judging 29. The gate regains its meaning, which is the whole point.

This mirrors how mature multi-level approval systems already work. Oracle's approval workflow example routes a $5,000 budget to one approver, $5,001 to $20,000 to two, and anything above $20,000 to three (Oracle docs). The structure is not novel; applying it to agent tool calls, with named owners and test cases, is.

A rule set decays in three ways: the business changes underneath it, the agent's tool surface expands, and nobody removes anything. Cadence fixes all three if you separate the reviews.

Run a review of new fallback signatures on a short cycle, weekly is workable for active agents. Its job is intake: which catches are rising, which are duplicates, which need a rule this sprint. Run a review of existing rules quarterly. Its job is pruning: for each rule, check how many times it fired and how many times its decision was overridden. A rule that never fires is dead weight that makes the policy harder to read; a rule overridden more than a small fraction of the time has the wrong threshold.

Run a review of the whole policy after any change to the agent's tools or permissions. That is the moment a new capability appears without a matching rule, and it is exactly when the fallback catches something new.

The ownership point is what makes this work. Every rule has a name, an owner and a review date, and every decision the gate makes should record which version of the rule applied. GitLab's approval policies show the pattern in a code review setting: rules are enforced on protected branches, a maximum of five rules attach to each policy, and when rules are invalid or cannot be evaluated, approval is required by default (GitLab docs). That last behavior is the one to copy. A policy that cannot be evaluated should fail closed.

Two signals tell you the cadence is failing. The first is a fallback signature that appears in three consecutive review meetings with no owner assigned. The second is an approval queue where the median decision time drops to seconds, the rubber stamp showing up in the telemetry (ThreatLocker). Both mean the same thing: the loop stopped.

Not every caught action deserves a rule. Three categories should stay in the net, deliberately and with a label.

Novel actions. If an action has been seen once, writing a rule from a single sample risks encoding a mistake. Leave it in the fallback, tag it as novel, and revisit if it recurs.

Judgment calls. Some decisions genuinely need a person: a refund to a high-value account, a message to a regulator, anything legal or clinical. The evidence that these belong behind an approval gate is strong, and the Arthur AI guidance recommends pre-execution approval specifically for irreversible, high blast-radius actions (Arthur AI). The error is not gating them; the error is gating everything else alongside them.

Regression cover. Keep one deliberate catch-all path, default deny, for anything the policy file does not recognize. This is not the original fallback of "ask a human and proceed." It is the opposite: an unrecognized action is refused, and the refusal is logged as a defect for the next review. The NHI Mgmt Group analysis makes the case that the absence of coverage should be a security decision rather than an open door (NHI Mgmt Group).

That reframes the fallback from a queue into a sensor. It stays in the architecture forever, but its purpose changes from catching work to reporting gaps. When the report reads zero for a review cycle, you have closed the loop, and the next tool you add to the agent starts the cycle again.

If you are setting this up across several agents and need one place to route every model call while you build the policy layer, Quanta Inference exposes text, image, video, audio and embedding models through one OpenAI-compatible API key, which keeps the gateway stable while the rules underneath it change (Quanta Inference).