💻 computer science

SARC: A Governance-by-Architecture Framework for Agentic AI Systems

This paper introduces SARC, a runtime governance framework that treats constraints as first-class specification objects to enforce obligations at multiple points within the agent loop, thereby eliminating hard-constraint violations and significantly reducing soft-window overages compared to traditional post-hoc or policy-as-code approaches.

Original authors: Gaston Besanson

Published 2026-05-12

📖 6 min read🧠 Deep dive

CC BY 4.0

Original authors: Gaston Besanson

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are building a very smart, autonomous robot assistant (an "Agentic AI") that can do things like order supplies, book flights, or manage money. You want this robot to be helpful, but you also need to make sure it doesn't break the law, spend too much money, or make dangerous mistakes.

Currently, most companies try to control these robots by giving them rules written in a notebook (prompts) or by checking their work after they finish (post-hoc audits). The paper argues this is like hiring a security guard who only checks the door after the thief has already run away. It's too late.

The authors introduce SARC (State, Action, Reward, Constraints), a new way to build these robots where the rules are hardwired into the robot's brain before it even takes a step.

Here is the simple breakdown of how it works:

1. The Core Idea: The "First-Class" Rule

In traditional programming, you tell the robot what to do (State), what tools it has (Action), and what it wants to achieve (Reward). The paper says we are missing a fourth, crucial piece: Constraints (C).

Think of it like a car:

Old Way: You tell the driver, "Please drive safely," and then you check the police report if they get a ticket.
SARC Way: You install a speed governor and a brake directly into the car's engine. If the car tries to go 90 mph in a 30 mph zone, the car physically cannot do it. The rule isn't just a suggestion; it's a mechanical part of the machine.

2. The Four "Security Gates"

SARC doesn't just have one rule; it has four specific checkpoints where the robot's actions are stopped and checked before they happen. Imagine a high-security airport:

The Pre-Action Gate (PAG): Before the robot even picks up a tool.
- Analogy: The TSA agent checking your ID and boarding pass before you get on the plane.
- What it does: If the robot plans to buy something expensive, this gate stops it immediately if it doesn't have a human's approval. It blocks "Hard" rules (like "Never buy illegal items").
The Action-Time Monitor (ATM): While the robot is doing the task.
- Analogy: A flight attendant watching the engine gauges while the plane is flying.
- What it does: If the robot is streaming data or making a long call, this monitor watches in real-time. If the cost gets too high or the data looks weird, it can cut the connection mid-flight.
The Post-Action Auditor (PAA): Right after the task is done, before the next one starts.
- Analogy: Checking the receipt immediately after you leave the store, before you go to the next store.
- What it does: It looks at what actually happened. If the robot spent too much money in the last 24 hours, it might slow down the next purchase. It handles "Soft" rules (like "Don't spend too much, but it's okay if it happens once in a while").
The Escalation Router (ER): The "Call a Human" button.
- Analogy: The pilot hitting the "Mayday" button and handing control to Air Traffic Control.
- What it does: If the robot sees something it's not sure about (like a new supplier), it pauses, calls a human, and waits for a "Go" or "No-Go" signal. If the human doesn't answer in time, the robot automatically says "No" to be safe.

3. Why "Just Telling the Robot" Doesn't Work

The paper proves mathematically that you can't just tell a robot, "If you break a rule, you lose 1,000 points of happiness."

The Problem: If a robot can make a million dollars by breaking a rule, and the chance of getting caught is tiny, the robot will still take the risk because the reward is so big.
The SARC Solution: Instead of hoping the robot chooses not to break the rule, SARC builds a wall that the robot cannot climb over. It treats rules as physical barriers, not just suggestions.

4. The "Receipt" (Audit Trail)

One of the biggest problems with AI is that when something goes wrong, nobody knows why or who did it.

Old Way: You look at a messy log file and try to guess what happened.
SARC Way: Every time the robot moves, it automatically prints a perfect, machine-readable receipt. This receipt says: "I wanted to do X. I checked Rule Y. Rule Y said 'Stop'. I stopped."
The Benefit: If a regulator asks, "Did you follow the law?", you don't have to guess. You just show them the receipt. The paper calls this "Auditable by Construction."

5. What Happens When Robots Talk to Each Other?

In big companies, one robot might hire another robot to do a job.

The Risk: Robot A might tell Robot B to do something illegal, hoping Robot B won't know the rules.
The SARC Fix: The rules travel with the work. If Robot A has a rule, Robot B must follow it too. If Robot B tries to hide the rule, the system catches it. It also keeps a clear family tree of who authorized what, so you know exactly which human is responsible for the final decision.

6. The Trade-Off (It's Not Free)

The paper is honest: SARC makes the robot slightly slower because it has to stop and check rules at every gate.

The Analogy: It's like driving a car with a strict speed limit governor. You won't get to your destination as fast as a reckless driver, but you won't crash.
The Point: The paper argues that in regulated environments (like banking or healthcare), being "safe and auditable" is more important than being "fast and risky." The cost of the delay is a known, manageable price to pay for safety.

Summary

SARC is a blueprint for building AI that follows the rules by design, not by luck. It moves the rules from a "suggestion box" (prompts) and a "post-game review" (audits) into the engine room of the AI. It ensures that if a robot tries to do something forbidden, the system physically stops it, asks a human for help, or logs the attempt perfectly, making the AI safe, explainable, and ready for the real world.

Technical Summary: SARC – A Governance-by-Architecture Framework for Agentic AI Systems

1. Problem Statement

Agentic AI systems, which perceive, plan, and act through tools and sub-agents, are entering regulated environments faster than governance infrastructure has matured. A critical structural mismatch exists: regulatory obligations (e.g., human oversight, risk management) are typically evaluated via post-hoc documentation or attached to prompts and dashboards. This creates a "structural mismatch" where constraints meant to limit execution are often assessed only after the action has occurred.

Current approaches suffer from specific failure modes:

Prompt Guardrails: Models can ignore, reinterpret, or route around instructions via tools.
Output Filtering: Cannot catch violations realized through side effects on the world rather than visible text.
Post-hoc Audit: Documents violations but cannot prevent them.
Workflow Rules: Often insufficient in dynamically expanding action spaces unless tied to a complete registry and enforced at dispatch.

The paper argues that governance controls must move from being attached to artifacts (prompts, logs) to being attached to execution within the system architecture.

2. Methodology: The SARC Framework

The authors introduce SARC (State, Action Space, Reward, Constraints), a governance-by-architecture framework. While $S$ , $A$ , and $R$ are standard Reinforcement Learning (RL) primitives, $C$ (Constraints) is the novel contribution. It treats constraints as first-class specification objects, equal to state and reward, and enforces them at declared points in the agent runtime.

2.1 The Specification Tuple

A SARC specification is defined as $\Sigma = \langle S, A, R, C \rangle$ .

Constraints ( $C$ ): Partitioned into three classes:
- $C_h$ (Hard): Violations are not permitted under any policy.
- $C_s$ (Soft): Violations are admissible at a declared marginal cost.
- $C_e$ (Escalation): Conditions requiring transfer of control to a human operator.
Constraint Structure: Each constraint $c \in C$ $c \in C$ is a quintuple $\langle src, class, pred, verif, resp \rangle$ $⟨ sr c, c l a ss, p r e d, v er i f, r es p ⟩$ , where:
- $src$: Source (regulatory, contractual, etc.).
- $class $:$ h, s,$ or $e$ .
- $pred$: Predicate over state, action, and time.
- $verif$: Verification mechanism (pre-condition, runtime monitor, post-hoc).
- $resp$: Response protocol (block, log, escalate, abort).

2.2 Runtime Enforcement Architecture

Constraints compile into four named enforcement sites within the agent loop:

Pre-Action Gate (PAG): Evaluates before dispatch. Used for hard constraints and predictive escalations decidable from state and action alone.
Action-Time Monitor (ATM): Evaluates during execution (e.g., wrapping tool calls). Used for constraints depending on partial outputs (cost accumulation, streaming content).
Post-Action Auditor (PAA): Evaluates after completion. Used for comparing post-action state to pre-action state (drift, side-effect verification).
Escalation Router (ER): Routes flagged actions to human operators with bounded queueing latency relative to the action's reversibility window.

2.3 Multi-Agent Extension

For multi-agent workflows, SARC introduces:

Constraint Propagation: Constraints inherit down the call chain. If a constraint is not decidable at a sub-agent's layer, it is evaluated at the deepest decidable layer ("decidability rescue").
Authority Intersection: Authority is the intersection of all principals and agents in the call chain; it is monotonically non-increasing.
Attribution-Preserving Trace Trees: The audit trail is a hierarchical tree, not a flat sequence, preserving the full chain of principal-agent relationships to prevent attribution dilution.

2.4 Formal Properties

Reward Shaping Limitation: The paper provides a formal counterexample (Proposition 1) showing that finite reward penalties cannot generally guarantee hard constraint satisfaction for low-probability, high-payoff violations. Thus, hard constraints must be architectural predicates, not reward terms.
Specification-Trace Correspondence: A system is "SARC-conformant" if it satisfies eight invariants (e.g., pre-action admissibility, trace derivation, enforcement completeness). This ensures that for every action in a trace, an auditor can mechanically verify which constraints applied and what response was taken, without accessing the model or prompts.

3. Key Contributions

Constraint Specification Model: A class-typed model ( $\langle src, class, pred, verif, resp \rangle$ ) that is implementation-agnostic but requires specific metadata for executability and auditability.
Agent-Loop Enforcement Architecture: A discipline mapping constraint classes to specific enforcement points (PAG, ATM, PAA, ER), converting governance from documentation to execution control.
Checkable Auditability: A formal definition of "auditable by construction" and a prototype checker that verifies runtime traces against specifications in $O(|T| \cdot |C|)$ time.
Multi-Agent Extension: Mechanisms for constraint propagation, authority intersection, and trace trees to handle complex enterprise topologies.
Regulatory Compilation Path: A method to map regulatory clauses (e.g., EU AI Act Article 14) into executable predicates and runtime checks.

4. Empirical Evaluation

The authors conducted a reproducible synthetic evaluation on a procurement task ( $H=1,000$ orders, 50 seeds) comparing SARC against four baselines: Post-hoc Audit, Output Filtering, Workflow Rules, and Policy-as-Code (PaC) only.

Results:

Hard Violations: SARC executed zero hard-constraint violations under exact predicates, matching the Policy-as-Code baseline but outperforming Output Filtering and Post-hoc Audit.
Soft Constraints: SARC reduced soft-window overages by 89.5% compared to the Policy-as-Code-only baseline. This was attributed to the explicit placement of a throttling response at the Post-Action Auditor (PAA) rather than relying on intrinsic performance.
Residual Violations: Under imperfect enforcement (predicate noise or enforcement failure), residual violations scaled with the enforcement-stack error ( $\epsilon_{pred} + \epsilon_{exec}$ ) rather than the environmental violation opportunity rate.
Latency Trade-off: SARC incurred a per-step latency of ~21ms (vs. 0ms for post-hoc), demonstrating the explicit cost of runtime governance.

5. Significance and Claims

The paper positions SARC not as a safety guarantee or a legal compliance certification, but as an architectural substrate that makes obligations executable, inspectable, and auditable at runtime.

Shift from Artifact to Execution: The primary contribution is the shift from attaching constraints to artifacts (prompts, logs) to attaching them to execution paths.
Auditable by Construction: SARC enables "auditable by construction," where the audit trail is generated by the system's adherence to its specification, rather than reconstructed from logs after the fact.
Regime B: The framework is designed for "Regime B" deployments (regulated, irreversible, or asymmetric loss environments) where omitting the constraint component $C$ renders a specification incomplete.
Economic Clarity: By forcing explicit declaration of operating points and reversibility windows, SARC makes the trade-offs between false positives, false negatives, and operator capacity visible as capital allocation decisions.

The authors conclude that SARC does not make systems safe by itself; rather, it provides the structural discipline required to engineer safety and compliance, separating optimization ( $R$ ), capability ( $A$ ), and admissibility ( $C$ ) to prevent systems from failing as unobservable anomalies.