From Standard to Enforcement
Inside the ACR Control Plane
In March, I wrote about why AI governance is entering its enforcement era—why policy documents are no longer enough, and why enterprises need runtime control architectures that actually sit on the execution path.
That article introduced the ACR Standard and its six operational control layers. It argued that governance must move from intention to enforcement.
Today, I want to go deeper. Because the ACR Control Plane is now a working reference implementation—open source, deployable, and designed to prove that runtime AI governance is not theoretical. It is operational.
The Problem the Control Plane Solves
Most agent stacks are optimized for capability: better planning, better tool use, better memory, better autonomy.
Most are not optimized for control.
That leaves a dangerous gap. Agents can act faster than humans can review. Prompts and application logic are weak enforcement boundaries. Direct tool access can bypass governance entirely. And security teams often get telemetry after the fact—instead of a hard stop before execution.
The ACR Control Plane closes that gap. It is a governance gateway that sits between autonomous agents and the enterprise systems they want to touch. Every agent action request flows through a governed decision pipeline before it is allowed, denied, or escalated.
If your agents are going to reach customer data, ticketing systems, production infrastructure, payment flows, or regulated workflows, then logs and prompt rules are not enough. You need a real enforcement point on the execution path.
What Makes It Different
Most "agent governance" products stop at dashboards, evals, or prompt wrappers. The ACR Control Plane is opinionated in a more operational direction:
Fail-secure by default. If a critical dependency breaks, the safe answer is deny. Not allow. Not degrade gracefully into an uncontrolled state. Deny.
Policy as code. Enforcement is not trapped in prompts or UI rules. It lives in versioned OPA/Rego policy—auditable, testable, and deployable through a release pipeline.
Runtime-first. This is designed for live action requests, not offline evaluation. The decision happens on the hot path, before the agent touches anything.
Operator-ready. There is a console for approvals, key management, policy drafting, release activation, drift inspection, and containment actions. This is built for the people who actually run these systems.
Forensics included. Evidence bundles can be exported per correlation ID with manifest, events, and checksums—ready for incident response and regulatory audit.
Bypass-aware. Downstream executors can verify short-lived gateway authorization and brokered credentials before they run anything. Direct-bypass requests that were not explicitly authorized by the gateway get rejected.
The Six Control Pillars in Practice
The ACR Standard defines six operational control pillars. The Control Plane implements all six as a composable decision pipeline:
1. Identity and Purpose Binding
Every agent must be registered with a declared purpose and operational boundaries. The control plane issues short-lived JWTs that bind the agent's identity to its authorized scope. No registration, no token, no access.
2. Behavioral Policy Enforcement
Allow, deny, and escalate logic is evaluated against every action request before execution. Policies are written in Rego, versioned, and distributed through OPA. Policy changes go through a drafting and release pipeline—not ad hoc edits.
3. Autonomy Drift Detection
The system baselines expected agent behavior and scores deviations. If an agent starts requesting tools or resources outside its declared purpose, drift detection flags it before it becomes an incident.
4. Execution Observability
Every decision generates telemetry—action requested, policy applied, result, timing, and correlation IDs. Evidence bundles tie a complete run together with manifest, events, and integrity checksums.
5. Self-Healing and Containment
An independent kill-switch service can halt agent execution when containment is triggered. This runs on a separate port, separate process—so a compromised gateway cannot disable the off switch.
6. Human Authority
Risky actions are not just denied—they are routed into an approval queue. Operators can review, approve, or reject escalated requests with SLA tracking. The system supports both human-in-the-loop and human-on-the-loop patterns.
Architecture: What the Decision Pipeline Looks Like
The synchronous hot path is deliberately lean: identity verification, policy evaluation, output controls, response. Background tasks handle telemetry persistence, drift scoring, and approval lifecycle without bloating the decision path.
The stack is enterprise-shaped by design: JWTs for agent identity, OIDC-ready operator authentication, API keys for service integration, Redis for caching and rate limits, Postgres for persistent state, OPA for policy, and OpenTelemetry for observability. It ships with Docker and Kubernetes manifests.
What You Can Prove in Minutes
The repo includes a complete demo stack. With docker-compose up, you get the gateway, kill-switch service, OPA engine, Postgres, and Redis all running locally. A sample agent demonstrates the full lifecycle:
Register an agent. Issue a token. Make allowed requests that pass through. Attempt a dangerous action that gets denied. Trigger a high-risk action that gets escalated to approval. Inspect the telemetry. Export the evidence.
There is also a protected executor example that shows how downstream services can reject any request that was not explicitly authorized through the gateway—verifying both the execution token and brokered credentials before running anything.
Why This Matters for Enterprise Security Leaders
Here is the question I keep asking CISOs and CIOs:
If one of your agents tried to refund money, delete records, exfiltrate data, or hit a sensitive internal API right now—where would the hard stop actually live?
If the answer is "the prompt," "the app code," or "we'd catch it in logs," then you do not have governance. You have hope.
The ACR Control Plane proves that there is a better answer. A real enforcement point. A governed decision pipeline. Policy as code, not policy as PDF. Runtime control, not post-hoc review.
This is what operational AI governance looks like when it moves from framework to implementation.
Getting Started
The ACR Control Plane is open source under Apache 2.0. The full repository, documentation, and deployment guides are available on GitHub.
If you are building agentic products that take real actions—not just answer questions—this is the reference architecture for keeping them governed.
ACR Control Plane on GitHub
The ACR Control Plane is the reference implementation of the ACR Standard—a runtime governance gateway for AI agents that take real actions in enterprise environments.
Want more governance insights?