An agent workflow can obey every rule it was given, at every step, and still do the thing the rules exist to prevent. A paper posted to arXiv on September 16, 2026 by Ashwini Kurady, Sri Sai Charith Grandhi, Rajesh Gupta and Sumit Mamoria gives this a name, a compositional policy violation, and sorts it into four types with a different fix for each.
The paper matters to whoever writes the rules an agent must follow: an operations lead, a compliance officer, the engineer who configures the guardrails. Its argument is that almost all of today's agent governance checks one step at a time, while the policies a business actually holds, a referral threshold, a spending limit, a review requirement, are facts about the whole job. This post explains the four types using the paper's own worked examples, then turns its repair rules into a checklist. Three of the four authors give addresses at a company domain, runctrl, which is worth knowing when you read the paper's architecture section.
- 01Step-level checks cannot catch this class, by construction.The paper's point is not that the checks are inaccurate. A check on one step cannot evaluate a property that step does not determine, so making it more accurate changes nothing.
- 02Four types, sorted by what goes wrong.Authority creep is about who decides. Threshold laundering and cumulative sum violations are about a quantity that crosses a limit. Context collapse is about the file the decision is made on.
- 03The repair depends on where the guarded quantity changes.Move a gate later, add a gate that nobody holds, trace authority backwards, or re-derive the decision from the original submission. One of the four, not a general fix.
- 04The examples are illustrations, not incidents.The paper cites insurers' announced agent deployments as context. Its underwriting and purchasing examples are constructed to show the mechanism, and we present them as such.
01 — The shapeThe failure in one example
Take the paper's purchasing agent. It may buy office supplies under two rules: no single purchase over $100 without approval, and no more than $250 in a day. During one day it makes three purchases of $90. Each passes the first rule. No purchase, looked at on its own, breaks anything. The day's total is $270, and nothing was watching the total. The authors note that financial regulators already define prohibited "structuring" over a sequence of transactions rather than any one of them, for exactly this reason.
Now the harder version, from underwriting. Policy: any account whose prior losses over five years exceed $250,000 must be referred to a manager. A referral agent checks the loss history it is handed, sees $210,000, and correctly does not refer. A later intake step then parses a valid $75,000 claim and adds it to the file. The committed total is $285,000. The referral rule is still in the manual, fully in force, and it never fires, because the gate ran before the number finished changing and nothing looked again. The paper's phrase for this is that the value committed is not the value that was checked.
The rule is still sitting in the manual, fully in force, and it never fires.Ashwini Kurady and co-authors, Compositional Policy Violations, arXiv, September 2026
02 — The mechanismWhy step checks cannot see it
The governance most teams have bolted onto agents comes in three forms the paper lists: classifiers on inputs and outputs, rails applied per turn, and evaluators attached to individual spans of a trace. All three ask the same question at the same grain: is this action permitted, given what is visible at this step? That is a sensible question, and it is the wrong one for a referral threshold, because the threshold is a property of the account after every step has touched it.
The paper's central claim is stated as a limit, not a bug. A predicate over a single step cannot evaluate a property that step does not determine. So a monitor watching the referral agent has no signal, "not a weak signal but none at all", in the authors' words, and a better monitor on the same step has the same nothing. The only place the violation is visible is the relationship between the number a gate reads and the evidence that number was derived from, and no single step holds that relationship. This is why the paper's proposed fix is a runtime that evaluates policies over the complete execution trace, recomputing guarded quantities from raw provenance instead of trusting the pipeline's own derived numbers.
03 — The taxonomyThe four types
The paper sorts the four by what becomes unsafe through composition: who is entitled to decide, a quantity that accumulates, or the representation a decision is made on. Each row below gives the paper's definition in plain words, its worked example, and the check that would have caught it.
| Type | What composes | Paper's example | Check that catches it |
|---|---|---|---|
| Authority creep | Several components each make a small judgement call that removes one exception; together they decide something none was authorised to decide. | Policy: three or more material exceptions must be escalated. Normalising, deduplicating and materiality steps each dismiss one. The router reads a count of one and does not escalate. | Trace backwards from the routing gate to every input it depends on and ask which step's discretion produced it. |
| Threshold laundering | A gate checks a quantity correctly, then a later step changes the quantity, and nothing re-checks. | Referral at $250K of prior losses. Gate sees $210K and passes; intake later adds a $75K claim. Committed total $285K, no referral. | Re-evaluate the same rule on the committed state and compare with the value the gate saw when it fired. |
| Cumulative sum violation | Individually compliant actions add up past a limit that no step is responsible for checking. | Purchases capped at $100 each and $250 a day. Three purchases of $90 each pass the per-item rule; the day totals $270. | Keep a running aggregate over the whole trace, tied to the entity the policy is defined on, and compare it to the limit. |
| Context collapse | Every hand-off faithfully summarises what it received, and the file the reviewer sees no longer supports the decision the original did. | Each summary stays under a materiality tolerance; the drift accumulates to 0.19 against the submission, flipping refer to accept. | Re-derive the decision from the retained original submission and compare it with the decision the reviewed file supports. |
The paper is careful about the difference between the two quantity types. In threshold laundering a gate exists and is right; its defect is timing. In a cumulative sum violation there is no gate at the aggregate scope at all. One is fixed by moving a check, the other by adding one, and a workflow can have either without the other. It is equally careful about authority creep: fixing a genuine error, such as removing a duplicate row created by a retry, is not a judgement call and does not count. Only a step that picked one reasonable reading over another, and thereby made an exception disappear, contributes.
04 — RepairsOne repair per type
The paper's most useful sentence for a builder is that the right repair is dictated by where the guarded quantity changes. That rules out the reflex of adding a bigger monitor at the end. The four repairs, in the paper's terms:
Trace backward once
From the decision gate, walk back through every input it reads and record which component exercised discretion over it. Accumulated permissions that govern the gate's inputs are the finding.
Re-evaluate on the committed state
Keep the rule; run it again after the last step that can change the quantity, and compare with the value the gate first saw. The policy is an invariant on the final state, not a point-in-time check.
Add the gate nobody holds
Introduce a check at the aggregate's own scope, with the running total carried across steps, sessions or invocations and matched to the right entity.
Reconstruct from the original
Keep the original submission and re-derive the decision from it, then compare with the decision the reviewed file supports. Checking each summary against the previous one cannot see the drift.
This is not the same problem as agents attacking or misleading each other. In Emergence AI's eight-world study the agents were adversarial; here every agent is honest and in-scope, and the workflow is still wrong. Both need trace-level records, for opposite reasons.
05 — PracticeWriting policies at workflow level
You do not need the paper's full runtime, an event log with sequence numbers, a normaliser and a sequence analyser per type, to act on it. You need to rewrite each policy so that it names the thing it is actually about. Our earlier agent governance framework covers who owns the rules; this is how to phrase them.
- State every limit on the committed state. Not "the referral agent checks losses against $250K" but "no account is bound with prior losses above $250K without a manager's referral." The second sentence has to be checked at the end, which is the point.
- Attach a data-flow label to every guarded quantity. Loss total, daily spend, exception count, customer identifier. The label follows the value through each step, so the final check can find where it changed.
- Put approvals on the combination, not the step. The purchasing agent needed approval for the third purchase, not because it was over $100 but because of the two before it. Our approval-gate framework describes where such a gate sits in a workflow.
- Keep the original submission and re-read it. For any review step, the reviewer, human or model, should be able to see the source document, not only the latest summary.
- Log discretion. Every step that makes a judgement call should record that it did, and what the alternative reading was. Authority creep is invisible without this record.
If you want the rewrite done against a real workflow and its policies, our AI transformation service includes a governance review of exactly this kind.
06 — Next stepThe policy was about the whole job all along
Rewrite one policy as a statement about the finished workflow
Pick the policy that would embarrass you most if it failed, and write it as a fact about the committed result rather than about any step. Then ask which of the four types could break it: a quantity that changes after its check, a total nobody sums, a chain of small judgement calls, or a file that drifted from its source. Add the one repair that type calls for. Repeat for the next policy.