Glossary of Governed Autonomy: Policy, Approval, Attribution, and Blast Radius

The reason this is urgent rather than pedantic is in the numbers. 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 fast, occasionally-wrong systems enter your change pipeline; they are already there. What you are deciding is whether the control vocabulary you buy on actually constrains them.

There is also a behavioral fact worth naming up front: about 80% of developers admit to bypassing policy or guardrails when those guardrails create friction. That single number is the acid test for every definition that follows. A control concept that can be skipped, ignored, or rubber-stamped is not a control. It is a suggestion. Hold each term below to that standard.

Policy is the machine-readable specification of what an agent is permitted to do, under what conditions, and what must be true before an action proceeds. The operative phrase is *machine-readable*. A wiki page describing your change process is documentation, not policy. Policy is policy only when the system enforces it without a human remembering to.

The distinction matters because the failure mode is predictable. When the rules live in prose, a runbook, a checklist, a Friday change-advisory meeting, the 80% bypass rate is what you get, because friction always wins against memory. Encoding the rules as policy-as-code removes the discretion that gets exercised at 2 a.m. under deadline.

A real policy layer expresses authority along concrete axes, not vibes:

When you evaluate a vendor, ask to see a policy expressed as code, then ask what happens when someone tries to violate it. If the answer is "we send an alert," that is monitoring, not policy. Enforcement is the difference. Policy is change-aware only if it knows what a given change actually touches, which is why a live dependency map like a System Graph sits underneath any credible policy engine, and why Governance is treated as engineering rather than configuration trivia.

Approval is the act by which an authorized human grants an agent permission to apply a proposed change. It is the load-bearing half of "agents propose, humans authorize," and it is the term most often hollowed out.

A genuine approval has three properties. It is bound to evidence, the approver sees what was validated, against what, and with what result, before deciding. It is role-checked, the policy layer confirms the approver is permitted to authorize this class of change and is not the same identity that proposed it, preserving the maker-checker separation your auditors expect. And it is enforced, an unapproved change physically cannot reach the protected environment, rather than being merely discouraged.

The common counterfeit is the approval that has degraded into a reflex. If a typo fix and a settlement-logic change wait in the same queue with the same urgency, reviewers rubber-stamp both, and the rubber stamp is where control dies. The fix is not more approvals; it is *selective* approval. Tier the gates by risk so governed automation handles the safe majority and human attention concentrates on the genuinely dangerous minority. A defensible structure:

The right question for a vendor is not "do you support approvals" but "what can an agent do *without* one, and can I prove the gate held." Approvals that don't gate anything are theater.

Attribution is the system's ability to answer, for any change in production, who or what proposed it, on what evidence, who authorized it, and whether the governing policy was honored, provably, after the fact. It is the term most teams discover they lack only when an examiner or an incident asks for it.

Attribution is not logging. Logs tell you something happened. Attribution lets you prove *why* it was permitted to happen. The real audit test is not "do you have logs," it is "can you show this specific change was authorized by someone allowed to authorize it, on evidence that existed before approval, and that the control was not bypassed." Meeting that test requires the proposal, the validation evidence, the policy decision, and the authorization to be a single linked, immutable artifact, not four systems someone reconciles by hand weeks later.

The design rule is that attribution should be a byproduct of how the system runs, not a separate logging project bolted on. Zof's closed loop, Understand, Test, Reproduce, Remediate, Verify, produces this record at each stage because validation runs through Testing Fleets and fixes through governed Remediation Fleets, so the evidence exists by construction. Remediation is the hardest part to govern; letting agents fix code unsupervised is reckless, which is exactly why attribution on the fix path is non-negotiable, not a nice-to-have.

Blast radius is the set of everything that breaks, degrades, or becomes exposed if a given change is wrong, plus everyone affected. It is the single most useful risk signal in the whole vocabulary, and the one most often replaced by worse proxies.

The instinct is to gauge risk by surface signals: lines changed, files touched, whether a senior wrote it. These mislead. A 600-line change to an isolated internal tool is safer than a three-line change to a shared auth library that forty services depend on. Blast radius is computed from the dependency graph, not the diff, which is why a live, continuously reconciled System Graph is what lets a gate ask the right question: does this change reach a critical path, a regulated data store, or revenue?

A closely related term belongs here:

### Reachability

Reachability asks whether a flaw or change sits on a path actually exercised in your deployed system, rather than one that merely exists in the code. It is what keeps blast radius honest. Reachability-based prioritization, triaging what is genuinely exploitable instead of every theoretical issue, can mean 70 to 90% less exploitable exposure. Applied to governance, an unreachable vulnerability need not block a release, while a reachable one routes straight to the strictest tier. You stop spending human attention on theoretical risk and concentrate it on the real kind.

Turn the glossary into a procurement filter. In your next vendor conversation, ask four questions and listen for the difference between a mechanism and a marketing word:

If the answers collapse into "we notify a human," you are looking at oversight in name only.