AI systems are outpacing the governance frameworks designed to control them. Here’s the architecture that changes that.
Jason Brashear Founder, ArgentOS · Partner, Titanium Computing · AI Infrastructure Builder
Something is broken in how we govern AI systems, and most people building in this space know it even if they haven’t named it yet.
We have AI agents that reason asynchronously, coordinate across distributed systems, execute code, call APIs, make financial decisions, and produce content at scale. What we don’t have is a governance layer that keeps pace with any of that. The oversight mechanisms we rely on today are stitched into agent architectures at build time, brittle by design, reactive in practice, and nearly impossible to audit across heterogeneous deployments.
That’s the structural risk a recently published academic paper called Governance-as-a-Service (GaaS) is trying to address. The paper, authored by Suyash Gaurav, Jukka Heikkonen, and Jatin Chaudhary and published on arXiv in August 2025 (arXiv:2508.18765), proposes positioning governance not as a feature baked into each agent but as infrastructure — a runtime service layer akin to compute or storage. The authors are blunt about it: GaaS does not teach agents ethics. It enforces them.
Having spent years building multi-agent systems at scale, I think this framing is exactly right. Let me explain why, what the framework actually proposes, and what it means for how we build AI systems going forward.
The Problem with How We Govern AI Today
The dominant approach to AI governance right now is what I’d call embedded oversight. You build rules into your agent’s system prompt. You add guardrails to your model at training time. You write policy checks into your application logic. Maybe you add a moderation layer on the output side.
This works up to a point. For simple, single-agent, single-purpose systems, embedded oversight is fine. But the moment you start building what most serious AI infrastructure looks like in 2025 — distributed ecosystems, multiple specialized agents, asynchronous execution, agents calling other agents — embedded oversight starts to fall apart.
“Existing oversight mechanisms are reactive, brittle, and embedded within agent architectures, making them non-auditable and hard to generalize across heterogeneous deployments.” — Gaurav, Heikkonen & Chaudhary (2025)
The problems compound quickly. If governance is embedded in each agent separately, you have no consistent policy enforcement across the system. Agents from different providers, built by different teams, running different models, will have inconsistent behavior under the same policy requirements. You can’t audit what you can’t observe, and you can’t observe behavior that’s embedded in a black box.
There’s also the adversarial dimension. In multi-agent systems, agents can probe each other. A compromised or poorly aligned agent can attempt to elicit non-compliant behavior from a well-governed one. Embedded oversight has no real answer to this because it has no system-level view.
I’ve seen this pattern play out in practice. When you’re running many specialized agents across multiple departments, you quickly realize that trying to bake governance into each agent individually is not just inefficient — it’s architecturally wrong. The agents shouldn’t be responsible for enforcing policy on themselves. That’s what infrastructure is for.
What GaaS Actually Proposes
The core insight of the GaaS framework is simple but powerful: governance should be a decoupled runtime layer, not a property of individual agents. The paper proposes a modular, policy-driven enforcement layer that intercepts, evaluates, and acts on agent outputs at runtime — without altering model internals or requiring agent cooperation.
That last part is worth dwelling on. The GaaS layer doesn’t need agents to opt in. It doesn’t require the models to be retrained. It doesn’t depend on prompts being structured in a particular way. It sits between agents and their outputs, and it operates on declarative rules.
The Trust Factor Mechanism
One of the most practically interesting elements of GaaS is the Trust Factor (TF) mechanism. Rather than treating all agents as equivalent, the system scores each agent based on its compliance history and the severity-weighted violations it has accumulated.
An agent that consistently operates within policy boundaries builds a high trust score. An agent that repeatedly triggers violations — whether intentionally or due to model drift — gets penalized. Trust scores are dynamic and continuous, not binary and static.
This matters enormously for multi-agent coordination. In a system where agents call other agents, trust scores allow you to dynamically modulate how much autonomy a given agent is granted. A high-trust agent might be permitted to execute certain actions autonomously. A low-trust agent might require human confirmation before proceeding. The same policy framework handles both.
Trust Factor Logic (Conceptual):
agent_trust_score = f(compliance_history, violation_severity, recency_weighting)
if trust_score < THRESHOLD_LOW: route to human review
if trust_score < THRESHOLD_MED: apply coercive intervention
if trust_score >= THRESHOLD_HIGH: allow autonomous execution
Three Types of Intervention
The GaaS framework distinguishes between three modes of enforcement intervention, each appropriate for different scenarios:
Coercive interventions block or redirect agent outputs that violate policy. These are hard stops — the agent tried to do something it shouldn’t, and the governance layer prevented it. In financial decision-making contexts, for example, an agent attempting a transaction that exceeds risk thresholds gets blocked before execution.
Normative interventions don’t block the agent but modify its output to bring it into compliance. Think of this as guided correction rather than hard refusal. The agent’s intent is preserved where possible, but the output is shaped to meet policy requirements.
Adaptive interventions are the most sophisticated. Rather than applying a static response, the governance layer adjusts its enforcement behavior based on context, agent history, and system state. This is where the Trust Factor comes into play most directly — a first-time minor violation from a high-trust agent gets handled differently than a repeated severe violation from a low-trust one.
What the Research Found
The paper’s authors tested GaaS across three simulation regimes using open-source models including LLaMA 3, Qwen 3, and DeepSeek-R1, applied to both content generation and financial decision-making tasks.
In the baseline regime, agents operated without governance. In the second, GaaS enforced policies. In the third, adversarial agents actively probed the system’s robustness. All actions were intercepted, evaluated, and logged.
The results were clear: GaaS reliably blocked or redirected high-risk behaviors while preserving throughput. Trust scores successfully tracked rule adherence, isolating and penalizing untrustworthy components without disrupting the broader system. Crucially, the adversarial testing showed that the runtime interception model is robust to agent-level manipulation. Because governance doesn’t depend on agent cooperation, an adversarial agent can’t simply choose not to comply — it doesn’t get the option.
Why This Architecture Matters Beyond Compliance
If you read GaaS purely as a compliance solution, you’re underselling what it actually enables. Yes, it gives you auditable, enforceable policy. But the deeper value is architectural.
When governance is decoupled from agent implementation, you can swap agents without re-implementing policy. You can onboard agents from external providers without compromising your governance posture. You can update policies at the infrastructure layer without touching agent code. You can run heterogeneous agent fleets — different models, different providers, different capabilities — all under a unified governance layer.
This is the difference between governance as a constraint on what you can build and governance as infrastructure that enables you to build more. The GaaS model is the latter.
When governance becomes infrastructure, it stops being a limitation on your system and starts being a capability multiplier. You can move faster, onboard more agents, and take on more complex tasks because the safety layer scales with you.
There’s also a trust dimension that extends beyond the system itself. Organizations deploying AI in regulated industries — healthcare, finance, legal — face increasing pressure to demonstrate compliance, not just assert it. A runtime governance layer that logs every interception, every trust score change, every policy enforcement decision gives you an audit trail that embedded approaches simply cannot produce. That audit trail is increasingly the price of admission for enterprise AI deployment.
Connecting GaaS to the Autoresearch Loop Primitive
I’ve been thinking a lot lately about what Andrej Karpathy’s autoresearch project represents as a work primitive — the idea that autonomous experimentation loops, driven by objective score functions, are about to become a fundamental building block of how work gets done. The short version: human defines the arena and the success metric, agent experiments autonomously within that arena, objective score decides what stays, loop runs indefinitely and compounds improvement overnight.
GaaS is the governance layer that makes autoresearch safe to deploy on consequential tasks.
Think about what happens when you point an autonomous experimentation loop at something like financial decision-making or healthcare content generation. The loop needs to be free to experiment — that’s the whole point. But experimentation in consequential domains means the system will sometimes try things that violate policy. Without a runtime governance layer, you have two choices: constrain the loop so tightly it can’t explore effectively, or accept that it will occasionally produce non-compliant outputs.
GaaS gives you a third option. Let the loop explore freely. Intercept violations at the governance layer before they reach users or execute in the real world. Let the Trust Factor mechanism track which experimental directions are consistently compliant and which are problematic. Use that signal to guide the loop’s exploration strategy.
The loop becomes self-governing. Not because you’ve constrained it, but because the governance infrastructure shapes its behavior at runtime without limiting its ability to improve.
What This Means for How We Build
If you’re building multi-agent systems today, the GaaS framework suggests a few concrete architectural shifts.
1. Treat governance as a service, not a feature
Stop baking policy enforcement into individual agents. Design a dedicated governance layer that every agent routes through. This layer is responsible for interception, evaluation, enforcement, and logging. Agents are responsible for their core tasks. The separation of concerns makes both better.
2. Build trust as a first-class system concept
Every agent in your system should have a trust score that evolves based on its compliance history. This score should influence how much autonomy the agent is granted, how its outputs are handled, and how it’s weighted in multi-agent coordination. Trust is not binary. It’s a spectrum, and it should be dynamic.
3. Design for auditability from day one
Every governance decision should be logged with enough context to explain it: what policy was triggered, what the agent’s trust score was at the time, what intervention was applied, what the output was before and after. This is not just good practice — it’s increasingly a regulatory requirement, and organizations that build audit trails now will have a significant advantage as compliance requirements tighten.
4. Separate policy from implementation
Governance rules should be declarative and modifiable without touching agent code. When the regulatory environment changes — and it will — you should be able to update your policies at the governance layer without redeploying your agents. This is what makes GaaS genuinely scalable across heterogeneous deployments.
The Bigger Picture: Governance as Infrastructure
We are in the early innings of a world where AI agents are handling consequential tasks at scale. Financial decisions. Medical information. Legal document processing. Content moderation at platform scale. These are not domains where we can afford reactive, embedded, non-auditable governance.
The GaaS paper frames its contribution clearly: by positioning governance as a runtime service akin to compute or storage, it establishes infrastructure-level alignment for interoperable agent ecosystems. That framing is right. We already accept that you don’t build your own database from scratch — you use infrastructure. We accept that you don’t build your own network stack. The natural next step is accepting that you don’t build your own governance layer embedded in each agent. You use governance infrastructure.
The organizations that get this right early will have a compounding advantage. Not just in compliance posture, but in the speed and confidence with which they can deploy increasingly capable AI systems. Governance as infrastructure doesn’t slow you down. It’s what lets you go fast safely.
The question is no longer whether AI systems need governance. It’s whether your governance architecture can scale as fast as your AI capabilities. GaaS says it can.
The GaaS paper is available on arXiv at 2508.18765. If you’re building multi-agent systems, it’s worth reading in full. The framework is still early-stage, but the architectural thinking is sound and the direction is right.
If you’re working on governance challenges in your own AI systems, I’d love to hear what you’re seeing in practice. The problems the GaaS paper names are real, and the solutions are still being built.
Top comments (0)