Agents Propose, Humans Authorize: A Reference Architecture for Governed Autonomy

The pressure is structural, not hypothetical. Roughly 41% of codebases are now AI-generated, and industry research suggests around 45% of AI coding tasks introduce a critical flaw or security issue. The cost of poor software quality sits near $2.41 trillion. You are not deciding whether to admit fast, occasionally-wrong systems into your change pipeline. They are already there, and they generate change faster than human review can absorb.

The common response is to reach for a better model or sharper prompts. That is the wrong layer. A better model still produces a non-trivial defect rate, and you cannot audit a probability distribution. What an enterprise needs is not more intelligence inside the agent, it needs a control layer around it. As we have argued in the control-layer thesis, AI is missing a control layer, not more models.

A control layer is not one feature. It is a small number of surfaces that every autonomous action must pass through, each answering a distinct question:

Miss any one and the others degrade. Approval without evidence is a rubber stamp. Evidence without attribution is unprovable under audit. Policy without approval is advisory, and advisory governance gets bypassed, about 80% of developers admit to routing around guardrails when those guardrails slow them down.

Policy is the first gate because it is the cheapest. It answers a yes/no question before any work happens: is an agent permitted to touch this surface, in this environment, under these conditions? Everything downstream assumes the action was admissible to begin with.

The failure mode here is policy-as-prose. When the rules live in a wiki, a runbook, or a quarterly change-advisory meeting, they are unenforceable at machine speed and they get skipped at exactly the moment they matter. Policy has to be code, evaluated inline, with no path around it.

Two design choices make policy real. First, express authority along axes that map to risk, not to surface signals like lines changed or file count: blast radius, data sensitivity, environment, and reachability. A three-line change to a shared authentication library is more dangerous than a 600-line change to an isolated internal tool, and only a policy that reasons about the dependency graph knows that. This is why policy cannot be evaluated from the diff alone, it needs the System Graph, a live map of services, dependencies, and CI/CD that tells the policy engine what a change actually touches. Second, default agents to propose-only. They may plan, generate, and stage a change, but moving it into a protected environment is a separate, governed event. That separation is the architecture's backbone.

Policy decides admissibility. Approval decides authority: which human, by role, signs off on a given class of change. This is where the governing principle lives, agents propose, humans authorize.

The trap is uniform approval. If a copy tweak and a settlement-logic change wait in the same queue with the same reviewer and SLA, the reviewer rubber-stamps both to keep up, and the one change that mattered slips through with the same glance as the rest. A gate that approves everything protects nothing.

The architecture's answer is to tier approval by blast radius, derived from the System Graph rather than self-declared by the author:

The objective is for the first two tiers to absorb the overwhelming majority of changes, so human attention concentrates on the genuinely dangerous minority. We go deeper on calibration in designing approval gates that don't become bottlenecks. Get tiering wrong and you have rebuilt the original queue with extra steps.

An approval is only as trustworthy as the evidence behind it. The reason most teams cannot safely auto-merge is that they have no defensible proof a change is good, so they fall back to a human eyeball as a weak substitute for a test that should have run.

Invert that. Every proposal should arrive at the gate already carrying the evidence the gate needs: which paths were exercised, what regressed, whether the original failing behavior was reproduced before the fix, and what reachability analysis says about exposure. That last point sharpens security gates specifically, reachability-based prioritization, asking whether a flaw sits on a path actually reachable in your deployed system, can mean 70 to 90% less exploitable exposure to triage. An unreachable flaw need not block a release; a reachable one routes straight to the strictest tier.

Evidence is not a static suite passing. It is validation that knows what changed and what depends on it. That is the job of coordinated Testing Fleets, agents that plan, execute, and maintain change-aware validation as the system evolves, rather than scripts that ignore the dependency graph and quietly rot. Watch for coverage laundering: a change that shows "tests passed" while the validation never exercised the changed path. The gate must read coverage *of the change*, not aggregate green.

Attribution is the surface most teams forget, and it is the one that decides whether the other three survive an audit. It answers the question an examiner actually asks: can you prove that *this specific change* was authorized by someone permitted to authorize it, on evidence that existed *before* approval, and that no control was bypassed?

"Do you have logs" is the wrong test. Logs can be edited and they decouple the proposal from the evidence from the approval. Attribution requires those to be a single immutable, linked artifact: the proposal, the validation evidence, the System Graph context at the moment of decision, and the authorization (or rejection), bound together. The trail should be a byproduct of how the system runs, not a reconstruction project that starts when the examiner arrives.

Two constraints raise the bar. Auto-merged changes, the ones no human watched, need the *same* evidence record as reviewed ones; the absence of a human in the path strengthens the attribution requirement, it does not relax it. And when data cannot leave your boundary, attribution still has to hold: Edge Runners execute as signed capsules inside a secure enclave and emit audit-ready evidence outward, so the proof comes to you while the data stays put.

These surfaces are not a checklist run once. They map onto the closed loop, Understand, Test, Reproduce, Remediate, Verify, and each loop pass writes to each surface. *Understand* is the System Graph feeding policy. *Test* and *Reproduce* generate evidence. *Remediate* is the propose step that approval gates, and remediation is the hardest, most critical surface to govern, which is exactly why letting agents fix code unsupervised is reckless and the approval machinery is the engineering. *Verify* confirms the change held and closes the attribution record. Remove any surface and the loop leaks: changes act without admissibility, approve without proof, or land without a trail.