How to govern enterprise agents at runtime with the CrewAI Agent Control Plane

Why having an Agent Control Plane?

In March 2025 I wrote that within three to five years enterprises running thousands of agents would realize the value isn't in the individual agent.

A few months later, on the Chain of Thought podcast, I talked about the wall companies hit when they scale without control: you end up with a thousand agents and nobody who can properly manage them, and that wall shows up fastest the moment teams want the rest of the company to build.

When governance is a manual review after engineering builds, teams get stuck between two bad options:

1. IT or security blocks business units from building and the engineering backlog stretches for months

2. Engineering and Business units build anyway in disconnected tools and you get shadow AI, surprise token bills, and unvetted data access.

When we launched Crew Studio in July as a new agent building layer, we promised that what business users and engineers build would run on centrally governed infrastructure. Today, the Agent Control Plane (ACP) is generally available on CrewAI AMP. It is the other half of that sentence.

Low-code does not mean low-risk, so governance has to live in the runtime

A low-code agent is not intrinsically low risk because the real governance object is the degree of agency delegated to the system.

Placing practical security in the execution runtime rather than the harness and model alone is the big unlock, allows you to truly enforce least privilege, tool restrictions, execution boundaries, and clear human accountability, while keeping that removed from building infrastructure itself. In the end of the day critical decisions must be enforced through deterministic controls.

Some companies try to solve citizen development by putting business users in walled low-code zones, but to unlock true value there is got to be a combo of progressive autonomy with centralized policy. But that can't come at the cost of separating where business users build from where engineers write code. When a business user builds in a walled environment with its own artifact format, you recreate the translation tax and the handoff bottleneck the moment that agent becomes important enough to need engineering work.

That is why Crew Studio and open-source code share the same building blocks and deploy to the same runtime on CrewAI AMP wit governance attached to the runtime, regardless of how the agent was built.

External gateways cannot see inside the agent loop, and code guardrails break at fleet scale

Once teams agree they need a control plane, the next mistake is putting it only at the network perimeter or burying it inside individual repositories.

If you put guardrails inside agent code, every policy update becomes a software release, makes it extra hard to re-use and to monitor, but the alternative many enterprises reach for is an external transport gateway, don't get me wrong they are useful for network routing and API reuse, and they have a real place in defense-in-depth but won't be able to assess deep into the harness to control more specific behavior that could be guarded against. An external HTTP proxy cannot see inside an agent's execution loop, they cannot inspect internal state transitions, cap reasoning iterations, pause and resume a run mid-loop, or enforce business-hours execution windows.

To govern how an agent actually runs, the control plane has to live inside the execution runtime.

The Agent Control Plane is now live on CrewAI AMP

And that is why I'm excited to share that starting today, the Agent Control Plane is generally available across CrewAI AMP.

Instead of chasing settings across individual repositories and deployments, engineering, IT, platform and security teams get one place on AMP to see how automations run, what they spend, and which policies they follow.

You start with visibility across the fleet. Before you write a single rule, you can see how every deployed automation on AMP is performing, how steps interact, and what each deployment spends across models and providers.

From the same surface, platform administrators get 13 out-of-the-box policies they can configure once and toggle on or off across AMP deployments. Rather than reviewing every agent one by one, the catalog covers the five areas that usually stall security sign-off.

• Data handling (PII detect-and-mask): Detect and redact sensitive personal data in-flow before it leaves your boundary or lands in downstream traces.

• Allowed models and tools: Enforce approved models, version gates, and tool blocklists so builders cannot wire an unvetted endpoint into a production run.

• Execution windows and frequency: Govern when and how often agents are allowed to run, including business-hours gates that an external API proxy cannot enforce.

• Content filters: Screen inputs and outputs against safety and compliance rules inside the execution loop.

• Cost limits: Set organization-wide cost thresholds that track consumption across automations and notify operators when spend crosses your threshold, without unexpectedly pausing, throttling, or killing an active production run.

When the 13 built-in policies do not cover a company-specific rule, teams can write custom policies that evaluate at runtime without asking engineers to edit code or redeploy their Crews.

What a control plane governs, and what still belongs to your systems of record

If you hand a CISO or security architect a slide that claims a control plane solves every risk by magic, you lose the room, a control layer only works when its boundaries are clear.

First, be clear about the runtime boundary. ACP governs automations running on the CrewAI AMP runtime, whether they were built in Studio without code or written in Python with CrewAI open source and deployed to AMP. It does not claim estate-wide governance over third-party agents running on external clouds or raw scripts running outside AMP.

Second, separate notifications from blocks. Security teams need to know which rules deterministically block an action or redact data in-flow, such as PII masking, tool restrictions, and execution windows, and which rules are notify-only alerts, like cost limit notifications that alert your team without stopping a run mid-flight.

Third, a control plane does not replace your identity layer or your systems of record. In AMP, ACP policies pair directly with workload identity and secret providers so credentials are never hardcoded into prompts or repositories.

Finally, runtime policies only hold if builders cannot turn them off, so in ACP, authoring, altering, and toggling policies is gated by dedicated platform permissions. And when a workflow carries irreversible side effects, runtime policies work alongside deterministic Crew Flows and human-in-the-loop approvals bound to specific actions.

Platform and security teams should set the boundaries for identity, data, tools, schedules, and spend once in the runtime, and unlock the rest of the company to build.