Agent Governance Control Plane: Runtime Policy for LLM Tool Execution

Most AI agent tutorials treat safety as a prompt engineering problem: add a system prompt telling the model to be careful, maybe run an output classifier. That approach fails the moment an agent can call tools with real-world side effects. The critical gap is between the model deciding to call a tool and the call actually executing. If nothing sits in that gap, the agent's autonomy is unconstrained, and a single hallucinated argument, prompt injection, or poisoned tool description can trigger irreversible damage.

Runtime governance is the deterministic control plane that evaluates every tool invocation against policy before execution. It answers three questions in sub-millisecond time: Is this tool allowed for this agent? Are the arguments within permitted bounds? Does this action require human approval? The answers come from policy-as-code, not from the model itself, because models are probabilistic and policies must be deterministic.

The industry has converged on this pattern. Microsoft's Agent Governance Toolkit (AGT) enforces YAML, OPA/Rego, and Cedar policies at sub-millisecond latency across 20+ agent frameworks. The OWASP Agentic Top 10 (2025) lists excessive capabilities (ASI-02), identity abuse (ASI-03), and uncontrolled code execution (ASI-04) as top risks — all addressed by a policy engine that sits between intent and action. Anthropic's agent-building guidance explicitly separates decision intelligence from execution authority. Without this layer, security audits fail, compliance teams block deployment, and incidents from tool misuse become existential business risks.

Governance also affects retrieval and generation planes directly. If an agent uses RAG, the governance layer must validate that retrieval tool calls stay within permitted data scopes — preventing the agent from querying unauthorized document collections. On the generation side, response inspection policies catch cases where the model's output contains data exfiltrated through poisoned tool flows, stopping it before it reaches the user.

The interview mistake is describing guardrails as output filters. Strong answers design a control plane with explicit policy evaluation, privilege boundaries, and audit trails that operate independently of the model.