SARC Shows Why Remediated Agent Actions Need to Be Re-Evaluated
SARC Suite One-Pass composes three governance engines at a single pre-action control point: one for authority, one for predictive cost and carbon, and one for evidence quality. The interesting part is what happens when one of those controls is allowed to change the action itself. A judgment made earlier can become stale, so the relevant gates need to re-evaluate the changed action before it executes. I rebuilt the artifact from a clean clone, reproduced its reported results, then added my own adversarial tests without touching its code or scenarios. The reauthorization mechanism works. But the authority model it relies on is narrower than it first appears.
Event analysed: . This analysis was published on 28 August 2026.
Only the properties its policy was written to read, and that is a scoping choice the artifact documents about itself rather than a defect I found. SARC Suite One-Pass (github.com/besanson/sarc-suite-one-pass) composes three published governance engines, sarc-governance for authority, Greensarc for predictive cost and carbon, and sarc-dq for evidence quality, at a single pre-action control point. Its Remediate-Regate protocol evaluates the evidence gate first, recomputes context after substitution, then re-evaluates every gate on the remediated action before returning a result. I reproduced the artifact from a clean clone on macOS with Python 3.11.16, ran its own release gate end to end, and confirmed its 207 tests pass, its formal checkers pass, and its two independent paper builds are byte identical. I then wrote 8 additional adversarial tests on a separate branch, without editing any existing scenario, predicate, or source file, bringing the total to 215 passing tests. The central positive finding: when I added an authority cap and forced a resource budget remediation that lowered order value below that cap, the SARC authority gate correctly re-evaluated the new, lower value and admitted an action it would have escalated before remediation. Reauthorization on a changed value works. The boundary is what the authority gate's own predicates read. The gate function evaluate_sarc_pag receives exactly four values, role, the allowed role set, order value, and the order value cap, drawn from an action context that also carries an agent identifier, a SKU, a day, a proposed quantity, and a decision identifier. None of those five other fields reach the authority predicates. Two of the six boundaries I tested, delegation provenance and the absence of a multi-action budget ledger, are explicit scope limits the paper itself states rather than gaps I found. The other four, resource identity, actor-specific identity, temporal validity, and a consumable execution-specific grant, are present in the data model but simply outside what the configured policy evaluates. None of this is a vulnerability I can substantiate. It is a coverage boundary in what one governance policy was configured to read at one execution point.
SARC Suite One-Pass composes three governance engines at a single pre-action control point: one for authority, one for predictive cost and carbon, and one for evidence quality.
The interesting part is what happens when one of those controls is allowed to change the action itself. A judgment made earlier can become stale, which means the changed action needs to go through the relevant controls again before execution.
I rebuilt the artifact from a clean clone, reproduced its reported results, then added my own adversarial tests without changing its original code or scenarios.
The reauthorization mechanism works. But the authority model it relies on is narrower than it first appears.
What happened
Besanson published SARC Suite One-Pass on GitHub under an Apache 2.0 license, the companion artifact for his paper One Gate Is Not Enough: Composing Stateful Pre Action Controls for Agentic AI. The artifact does not reimplement governance logic. It imports and calls three separately published, real engines directly: sarc-governance for authority (arXiv 2605.07728), Greensarc for predictive cost and carbon budget (arXiv 2606.15954), and sarc-dq for evidence quality (arXiv 2607.26313), and composes them at one pre-action control point.
The paper's own framing is precise. Once a pre-action governance control is permitted to transform the action it governs, governance stops being a set of independent checks and becomes a composition problem over constraints, transformations, and state. It demonstrates three consequences of that permission. Remediation-induced control coupling: a control that transforms an action can invalidate another control's earlier judgment on it. Non-commutative remediators: the two implemented remediation operators, evidence substitution and resource downroute, do not commute, applied in opposite orders they disagree at 86 of 243 grid points a finite-model checker tests. And governance-state contamination: an admissible but uncovered defect can be promoted into a governed buffer's trusted state and reused by future remediations.
Its answer to the first problem is the Remediate-Regate protocol. Evaluate the evidence gate first. Recompute context after substitution. Then re-evaluate every gate on the remediated action before returning a result.
Besanson also published a LinkedIn article about the work, framed around the question the paper opens with: an agent can clear a permission check, a budget check, and a data quality check, and still take an action nobody actually approved, because the action that executes is not always the action any single check evaluated.
What I reproduced
I cloned the repository fresh on macOS, built an isolated virtual environment with Python 3.11.16, and installed the artifact's dependencies through its own bootstrap process, which pins and clones the three composed engines at fixed commits. I installed Poppler for the paper verification path and ran the artifact's own mandatory release gate rather than a subset of it.
I then created a separate branch, moona adversarial, and added one new test file, test_belay_adversarial.py, containing 8 additional tests. I did not edit composition.py, specs/authority.yaml, or any existing scenario file to make a test fail. Every adversarial test exercises the artifact's real, unmodified evaluate_sarc_pag function and its real, unmodified authority specification, the same code path the artifact's own 207 tests already exercise. The combined suite reported 215 passing tests, and the artifact's original 207 remained green throughout. I want to be plain about the framing here. Nothing below is a report of SARC breaking. It is a report of what SARC's own authority policy was configured to look at, produced by testing that policy directly rather than by editing it.
What the artifact gets right
The paper's own claim is that a single pass evaluation, checking all gates once against the original action, can be unsound once one gate is allowed to remediate that action, because a gate downstream of the remediation ends up judging a value that will never execute. The Remediate-Regate protocol answers that with two phases. Phase I evaluates the evidence gate and recomputes context if it substitutes a value. Phase II re-evaluates every gate, authority included, against the remediated action rather than the original one. I confirmed this directly in the source rather than taking the README's word for it. The authority gate call in Phase II is passed the remediated context's order value, not the value the action started with.
To see whether that actually matters rather than just existing as a code path, I built on the artifact's existing tight budget workflow and added an authority cap between the action's pre-remediation and post-remediation order value. Before remediation, the order value exceeded the cap I set, and the authority gate correctly escalated it. The resource gate then triggered its own remediation, scaling the committed quantity down to fit the remaining budget, which also brought the order value below the authority cap. Phase II re-evaluated the authority gate against that new, lower value, and the action was admitted. That is the clearest way I know to test whether SARC's re-evaluation is real: give it a case where the pre and post-remediation verdicts would differ if the gate read a stale value, and check that it does not.
Adversarial authority findings
Every finding below follows the same method. I read the artifact's action context, its authority specification, and the function that evaluates authority against that context, then tested whether a property the context carries actually reaches the authority decision. I am careful throughout to separate three different things: a genuine authority coverage boundary, a scope limit the artifact already states about itself, and a claim I did not test and am not making.
| Finding | Tested dimension | Represented in the action context | Read by the authority gate | Result | Classification |
|---|---|---|---|---|---|
| A1 | Resource identity | Yes, sku | No | Two actions differing only in target SKU receive identical authority verdicts | Authority coverage boundary |
| A2 | Monetary value after remediation | Yes, order_value | Yes | A resource budget remediation that lowers order value below an authority cap correctly flips the verdict from escalate to admit | Positive control |
| A3 | Actor identity | Yes, agent_id | No | Two different agent identifiers with the same role receive identical authority verdicts; agent_id is preserved in the output record for attribution only | Authority coverage boundary |
| A4 | Delegation provenance | No representation at all | No | No parent agent, principal, delegator, or grant identifier exists anywhere in the action model | Explicit open problem |
| A5 | Temporal validity | Yes, day | No | Two otherwise identical actions on different days receive identical authority verdicts; no expiry or valid until field exists | Authority coverage boundary |
| A6 | Execution history across actions | No cumulative field; predicates are documented as per decision | No | Two sequential actions each under a per action cap are each admitted even though their combined value exceeds it, matching the policy's own documented per decision scope | Architectural boundary |
| A7 | Execution specific grant binding | Yes, decision_id, for audit and replay | No | decision_id indexes and reconstructs a decision but is not a consumable authorization token the gate checks | Authority coverage boundary |
A1. Resource identity is recorded but not authority bearing
The action context the artifact builds for every decision, ActionContext in composition.py, carries agent_id, role, sku, day, proposed_qty, order_value, est_cost_eur, and est_carbon_g. The function that evaluates the authority gate, evaluate_sarc_pag, takes exactly five parameters: the loaded specification, role, the allowed role set, order_value, and order_value_cap. The configured authority specification, specs/authority.yaml, defines exactly two constraints, role_authorised and order_value_cap. sku never appears in either the function signature or the specification. Two actions that are identical in every respect except which SKU they target therefore receive the same authority decision. This is not automatically a bug. It is an authority model coverage boundary: resource identity is present in the execution context but does not participate in the configured SARC authority decision.
A2. The positive control: remediated monetary value is correctly reauthorized
Covered above. I am restating it here only to keep it in its place in the table, because it is the finding that keeps the rest of this section honest. SARC's Remediate-Regate protocol is not broken. It re-evaluates the property its policy reads, and it re-evaluates it against the actual, executed, remediated value.
A3. Actor identity: preserved for attribution, not read for authorization
Two decisions with different agent_id values but the same role produce identical SARC authority verdicts, because agent_id, like sku, never reaches evaluate_sarc_pag's arguments. It is not discarded from the system: the output record's context block preserves agent_id, so every decision remains attributable to the agent that made it after the fact. But attribution and authorization are different guarantees. SARC Suite preserves agent identity for attribution, but the configured authority policy is role based rather than actor specific. I am not saying SARC does not authenticate agents. I tested one thing, whether a specific agent identifier changes the authority verdict, and it does not, under the currently configured policy.
A4. Delegation provenance: a stated open problem, not an undocumented gap
I deliberately did not write a test designed to fail here, because the paper already answers the question directly. Its own text describes the resource gate's downroute mechanism as a single agent, single budget window mechanism, not a multi agent conservation guarantee, and its conclusion states plainly that it is leaving general convergence, concurrency, delegation, and arbitrary stateful remediation as open problems. The action context has no field for a parent agent, a principal, a delegator, a delegated scope, or a grant identifier, and none of those concepts appear anywhere in composition.py. Delegated authority is explicitly outside the current single agent model rather than an undocumented failure, and I think that distinction is worth taking as seriously as any finding I did test.
A5. Temporal validity is recorded but not authority bearing
ActionContext records a day field for every decision, and the artifact's W2 workflow evaluates actions on a weekly commitment cadence built from that field. But day never enters evaluate_sarc_pag, and neither the function nor the specification exposes a timestamp, an expiry, or a valid until concept for an authority decision itself. Two otherwise identical actions on different days receive the same authority verdict. Temporal context is recorded in the action model but is not authority bearing in the configured SARC adapter. I want to be precise about what I am not claiming: I did not establish that a time bounded authority policy was ever promised, and I am not describing an expiry bypass. I tested whether time changes the verdict, and under the current policy it does not.
A6. Execution history: stateless by explicit design, not by oversight
A comment directly above the authority predicates in composition.py states the design intent in the artifact's own words: the cap and allowed roles are per decision data. evaluate_sarc_pag builds a fresh context from role, the allowed role set, order value, and the cap on every call, with no history, no previous action count, and no cumulative spend carried between decisions. I tested this directly: two sequential actions, each valued under a per action cap, are each independently admitted, even though their combined value exceeds that same cap. I want to be exact about what this does and does not show. It does not violate the existing policy, because the existing policy is explicitly per decision, and the artifact says so in its own comments. What it does show is a real distinction worth naming: the composition contains stateful mechanisms elsewhere, including an evidence history buffer and a Greensarc budget that persists across a day or a week, but the authority decision specifically is stateless across executions in the configuration I tested.
A7. Decision identity exists for audit, not as a consumable authorization grant
Every decision record carries a decision_id, used to index persisted decisions, reconstruct them for audit, and replay experimental results deterministically. It does not enter evaluate_sarc_pag, and nothing in the authority path exposes an authorization identifier, an approval identifier, a nonce, or any consume on use mechanism that would bind one authority verdict to exactly one execution. I want to be precise about a term I am deliberately not using: this is not a replay vulnerability. The artifact's own references to replay concern reproducing experimental results from persisted evidence, not replay protection for an authorization credential, and I am not asserting the two are the same problem. Decision identity exists for audit and reproducibility. The inspected authority path does not model a consumable, execution specific authorization grant, and those are two different properties that happen to share a superficially similar name.
What this does not prove
I want to be as clear about the edges of this record as about its findings. I did not test the sarc-governance, Greensarc, or sarc-dq engines in isolation, only the composed authority path as SARC Suite configures and calls them. I did not test whether a different authority specification, one that did register sku, agent_id, day, or a grant identifier as predicates, would behave any differently. Nothing here suggests it would not; the engine's predicate registry is designed to accept custom predicates, and specs/authority.yaml is a configuration choice, not a hard limit of the underlying sarc-governance engine. I did not evaluate the artifact's evidence gate or resource gate for the same six dimensions, only its authority gate, because the paper's own central claim is specifically about authority, resource, and evidence controls composed together, not about any one gate's internal completeness. I did not test the artifact under adversarial network, concurrency, or multi agent conditions, which the paper itself states are out of scope. And I did not test SARC Suite's proprietary counterpart, the GIGO Bench harness the README references as a separate, non public product. Everything in this record concerns the open artifact only.
Why it matters for agent authority
The interesting result here is not that SARC failed. It is that SARC succeeded exactly where its policy was configured to succeed, and that success draws a precise line around what a pre action authority decision actually needs in order to mean something. A2 shows that re-evaluation on a changed property works when that property is represented in the policy. A1, A3, A5, and A7 show that representation in the data model and participation in the authority decision are two different things, and an execution boundary can carry a field without ever consulting it. A4 and A6 show that some of what looks like a gap is instead a scope the artifact names honestly, which is a different and more useful kind of finding than a silent omission would be.
Put together, they sharpen a single question I keep coming back to: what information has to be present at the execution boundary before a reauthorization decision can actually establish that this specific agent may take this specific action, on this specific resource, under this specific grant of authority, at this specific point in time. SARC Suite answers two of those five clauses, this specific agent only by role rather than by identity, and this specific action only through the one monetary property its policy reads. The other three, this specific resource, this specific grant, and this specific point in time, are recorded in the same action object without ever reaching the decision.
My take
SARC provides evidence that governance must be recomputed after an agent action is transformed. My reproduction and adversarial testing found that this mechanism behaves correctly for the authority dimension its policy represents. The remaining boundary is representational, not mechanical: in the composition I tested, authorization is expressed through role and per-decision monetary value, while resource identity, actor-specific identity, time, delegation provenance, execution history, and execution-specific grant binding are present in the data the system already carries but are not part of the same authority decision. I think that is a more useful finding than either a clean bill of health or a broken gate would have been, because it names something reusable: a re-evaluation mechanism is only as complete as the policy it re-evaluates, and a policy's completeness is a property of what it was configured to read, not of the architecture that calls it.
What to watch next
Whether a future revision of SARC Suite, or a deployment built on the same sarc-governance engine, registers resource identity, actor identity, or temporal validity as authority bearing predicates, which the engine's own predicate registry already supports without an architectural change. Whether the paper's own named open problems, delegation and multi agent conservation across a chain of agents, get a companion artifact of their own the way authority, resource budgets, and evidence quality each did. Whether decision_id or an equivalent identifier is ever bound to a single consumable execution grant rather than serving audit and replay alone. And whether other Remediate-Regate style implementations elsewhere in this market show the same pattern I found here, a working re-evaluation mechanism whose completeness depends entirely on which properties its policy was configured to read.
Sources
This analysis interprets third-party reporting, research and announcements. Moona is not the original reporter of the underlying events.