A Glossary of Enterprise AI Agent Governance: Control Plane, Policy-as-Code, Authority Scoping, and More

Control plane. The layer that decides what an agent is allowed to do, authorizes specific actions, and records what happened. It holds policy, authority, and the audit trail. It does not, by itself, run tests or write code. Its job is decision and accountability.

Execution plane. The layer that actually performs work: running validation, generating a fix, applying a change in a target environment. Agents live here.

The reason this split matters more than any other distinction in the glossary: most tools marketed as "AI reliability platforms" are pure execution. They run agents but have no first-class place to express what those agents may do or to prove what they did. A control layer is an architecture, not a feature you bolt onto an execution tool. Zof's control layer for software reliability is built around exactly this separation, with the control plane governing one or more execution surfaces.

Control layer. The broader category name for a system whose primary value is governance of autonomous action, not the autonomy itself. The thesis behind it: a serious enterprise doesn't want more AI, it wants control over the AI it already runs.

Governed autonomy. Agent autonomy bounded by policy, scoped capabilities, role-based access, and human authorization, particularly for production-impacting work. It is the opposite of unsupervised automation. The agent is genuinely autonomous within a defined boundary; it is not free to act outside it.

Agents propose, humans authorize. The operating principle of governed autonomy. Agents may plan, generate, test, and stage a change, producing a complete proposal with evidence attached. The transition from proposed to applied is a separate, policy-governed event with a named, accountable authorizer. This deliberately keeps the maker and the checker distinct, which is the separation of duties auditors expect.

A useful test for any vendor claim: ask whether the agent that *writes* a change is the same actor that *applies* it. If proposal and authorization are collapsed into one step, you do not have governed autonomy. You have unsupervised automation with a friendlier name.

Policy-as-code. Authority and constraints expressed as version-controlled, machine-enforced rules rather than prose in a wiki or a slide reviewed at a weekly change-advisory meeting. This matters because of a hard behavioral fact: industry research puts the share of developers who bypass policy or guardrails near 80%. That is rarely malice. It is friction. Governance that depends on people remembering to follow a document gets routed around at exactly the moment it matters. Policy-as-code cannot be skipped because the system enforces it inline.

A workable agent policy typically expresses authority along a few axes:

Authority scoping. The practice of defining precisely what an agent may do, where, and under what conditions, then enforcing it. Scoping has two halves often confused. *Capability scope* is what an agent is technically able to do (read this repo, run this suite, open a pull request). *Authority scope* is what it is permitted to do without further approval. A well-governed agent often has broad capability and narrow authority. It can do a lot, but it may only act unsupervised on a small, explicitly safe set.

Approval gate. A policy-defined checkpoint where a proposed action pauses for human authorization before it can proceed. The design goal is to put gates only where risk warrants them. If a typo fix and a settlement-logic change wait in the same queue, reviewers rubber-stamp both, and the rubber stamp is where control quietly dies.

System graph. A live model of applications, services, APIs, dependencies, tests, deployments, and CI/CD, used to determine what a given change actually touches. This is what makes validation *change-aware*: instead of re-running a fixed suite regardless of what moved, the system targets the surfaces a change can actually affect. You cannot scope authority by blast radius if you cannot compute blast radius, which is why the System Graph is upstream of policy enforcement, not a separate feature.

Blast radius. The set of components a change or failure can affect, computed from the dependency graph rather than guessed. It is the primary input to risk-tiering: low blast radius on a non-regulated path can justify governed auto-apply; a change reaching a critical dependency should not.

Reachability-based prioritization. Ranking issues by whether they are actually exploitable in the live system rather than treating every finding as equal. The payoff is concentration of effort: industry data suggests reachability-based prioritization can mean 70 to 90% less exploitable exposure to act on, which is also what makes it safe to automate the low-risk long tail and reserve humans for the genuinely reachable risk.

Testing fleet. A coordinated group of validation agents that plan, execute, observe, and maintain testing as the system evolves, sharing schedules, policies, and telemetry. The distinction from a test suite is that fleets adapt to change instead of rotting against it. Their output is a verdict the control plane can act on, not just a coverage number. See Testing Fleets.

Remediation fleet. A coordinated group of agents that reproduce failures, propose fixes, and verify results after explicit human authorization, never applying unsupervised production changes. Remediation is the hardest and most consequential part of the loop, which is exactly why it must be the most governed. The engineering effort is in the Governance around it, not in the fixing itself. See Remediation Fleets.

Closed-loop reliability. A cycle in which graph-aware testing, analysis, human-authorized remediation, and verification continuously improve reliability rather than producing one-off reports. Zof operates this as a five-stage loop: Understand, Test, Reproduce, Remediate, Verify.

Audit trail (as a byproduct). An immutable, linked record of what was proposed, what evidence supported it, who authorized it, what executed, and whether verification passed. The qualifier matters. The trail should fall out of how the system runs, not be a separate logging project. The real auditor test is not "do you have logs," it is "can you prove this specific change was authorized by someone permitted to authorize it, on evidence that existed before approval."

Edge runner / signed capsule. A signed, verifiable execution unit that runs inside a customer's secure enclave or perimeter and emits audit-ready evidence outward, so production data stays in place while the proof travels. This is how authority and data residency stop being a tradeoff in regulated environments. See Edge Runners and secure-enclave deployment.

The category is being defined in real time, and the stakes are concrete. Industry research indicates roughly 41% of codebases are now AI-generated and that around 45% of AI coding tasks introduce a critical flaw or security issue, against a backdrop where the cost of poor software quality is estimated near $2.41 trillion. The agents are already in the pipeline. The open question is whether the vocabulary your organization uses to govern them is precise enough to write into a policy, a contract, or an architecture review.

For a product manager, the practical move this week is to take any agent capability on your roadmap and run it through three of these terms: What is its authority scope? What approval gate sits between proposal and production? What audit trail does it produce by default? If you cannot answer cleanly, the gap is governance, not intelligence. For the longer argument, the AI code testing imperative whitepaper and the Zof glossary go deeper on individual terms.