Policy engine

Whether an agent may put a customer’s card number in a prompt, or act on a support ticket containing the sentence “ignore your previous instructions”, is usually decided inside the agent: a regular expression in a try block, a system prompt asking the model to be careful, an amount threshold written by whoever built the refunds agent. Each of those is enforced by the thing being governed, changes whenever someone redeploys, and is invisible to the person who has to answer for it in an audit.

The second failure is the one that costs you. Injection arriving in a user’s own message is the demonstration; injection arriving in a tool result — a ticket body, a scraped page, a row from a database somebody else writes to — is the channel that actually hijacks agents, because the model reads data as instructions and that data was written by whoever filed the ticket. A guardrail that only inspects what a user typed does not see it at all, and neither does one that inspects the text after the model has already read it.

Then there is the control that breaks the business. Most policy engines let you write a rule and switch it on, and the first thing you learn about its false-positive rate is which team’s work stopped. That is why a rule here can be staged in shadow mode, and why the backtest that replays it against recorded traffic reports “unknown” rather than “zero” whenever the recorded evidence cannot answer the question — a zero reads as safe to promote, and the promotion is the outage.

Seven trigger kinds, and no eighth. There is no free-text trigger: you cannot write a rule that blocks any prompt containing a particular phrase, because the payload conditions available are the ones the detectors and the scanner produce.

Scope is the other half of matching. Agent ids, team names and tags each select, and an empty scope is global. The comparison is deliberately asymmetric — team names are compared case-insensitively because a human types them under incident pressure, tags are compared case-sensitively — and the backtest coverage report names that asymmetry explicitly, because a scope of tags PCI selects nothing when the agents are tagged pci and the resulting report would otherwise read as a clean zero.

Tool and model patterns are wildcards, not regular expressions: an asterisk matches any run of characters including a slash, matching is case-insensitive, and every other metacharacter is escaped, so a pattern cannot become a regular expression by accident. The shipped refund rule matches the pattern rather than a single server for a reason the source states plainly: the action is what matters, not who hosts it, so it catches an issue_refund on the order database and on the payments service alike.

Injection scoring is nine weighted patterns run over sanitised text, with the weights summed, multiplied by 1.25 when the source is a tool result, and capped at 1. The multiplier is the whole point: a directive inside a tool result is more suspicious than the same words typed by a user, because the user of a tool result is data rather than a principal. A tool-result directive scores 0.4 on its own and 0.5 arriving from a tool, so a rule set at a minimum confidence of 0.5 fires on the ticket body and not on the person typing into your console.

Sanitisation runs first, and that ordering is load-bearing rather than tidy. A scanner reading un-normalised text is looking at a different document from the one the model will read, which is the entire ASCII-smuggling attack: the Unicode tag block encodes a complete invisible alphabet, so the word “hello” can be written in characters no reviewer and no naive pattern will see. Normalising to a fixpoint first means every downstream detector, and every human reading the trace, sees what the model actually receives.

The scan is inline, synchronous and running on attacker-controlled text, so its cost is a security property. Node cannot interrupt a running regular expression: one pattern that backtracks super-linearly stalls every other request sharing the process. Two such patterns were found in this build. The reported one took 121 ms on a 200 KB input; auditing the rest found a worse one, the markdown exfiltration pattern, at 51 seconds on the same input — a single-request denial of service. Both were rewritten to be linear, a 64 KB scan cap was added, and every adversarial 200–400 KB input was re-measured at under 4 ms. Every pattern added since must be linear in the length of its input, and the constraint is written into the file that holds them.

The 64 KB cap is a deliberate trade. An injection payload has to be read by the model to work, so anything worth detecting is already in the first 64 KB; beyond that a caller is only buying scan time that is charged to every other request on the process. Text past the cap is not scanned.

A backtest replays a candidate rule against recorded traffic and reports what it would have changed. It runs the real evaluator twice per request — once with the baseline rulebook, once with that same rulebook plus the candidate forced to enabled and enforcing — and reports the delta. The candidate is removed from the baseline by id first, so backtesting a rule that is already stored compares it against the estate without it rather than against itself. Because the candidate is then the only difference between the two runs, every difference in outcome is attributable to it, without the replay re-implementing a line of the decision path.

Three properties make it a control rather than a report. First, a reachability gate: a request stopped by a kill switch, a dormant agent, a permission or delegation denial, a rate limit or a budget never reached policy evaluation at all, so it is excluded from the denominator rather than counted as traffic your rule left alone. Second, per-trigger coverage as a first-class field, with null counters rather than zeros whenever the recorded evidence cannot answer — null is a question, zero is a false answer. Third, a digest that survives promotion, so the evidence you gathered on a shadow rule is still valid when you flip it to enforce.

The digest covers exactly what the rule does: its trigger, its action, its scope and its priority. Mode and enabled are excluded deliberately, because a digest that changed the moment you flipped shadow to enforce would invalidate the very backtest being used to authorise the flip — an unsatisfiable gate. Priority is covered, because re-ordering a rule changes which other rules shadow it, which is exactly what a backtest measures.

Where a deployment sets the flag, the promotion gate has two halves and is only a gate with both. One refuses a shadow-to-enforce or disabled-to-enabled promotion without an acknowledged backtest of the policy as it will be after the update, so patching the trigger and flipping to enforce in one request cannot borrow the acknowledgement of the rule that was tested. The other refuses to create a rule that is already enforcing — without it, an operator refused a promotion could delete the rule, post it back as enforcing, and be enforcing untested in two requests. Authoring stays unrestricted: a shadow rule and a disabled rule enforce nothing, so both are created freely. The gate is off by default, because imposing a process control on an existing install mid-upgrade would block a change already in flight.

Acknowledgement is a human act, not a checkbox on a report. It is single-use, it records who accepted the result, and the audit entry copies the coverage level and the impact figures that were accepted, so a later reader does not have to trust that the stored report is unchanged. A report whose coverage came back as none is still acknowledgeable — that is a person explicitly accepting “impact unknown”, which is a decision someone’s name should be on, and a different act from having measured a safe result.