Watching Isn't Enough: The Case for a Runtime Control Plane for AI Agents
Observability tells you what went wrong. Governance stops it from happening. They're not the same thing — and most agent stacks are missing one of them.
Last week I wrote about the AI agent observability crisis — the fact that your agents can fail catastrophically while every traditional monitoring metric stays green. The response in the comments surfaced a question I've been thinking about since: okay, so now I can see my agent drifting. What do I do about it?
The honest answer is: with observability alone, not much. You can see the problem. You can page an engineer. You can roll back a deployment. But by the time you've done any of that, the agent has already sent the wrong tone of email to 10,000 customers, leaked a user's PII to a third-party tool, or — as happened last week — processed a financial transaction it shouldn't have.
Observability is the smoke detector. What teams are now reaching for is a sprinkler system.
That's the problem Galileo's Agent Control, released last week as open source, is trying to solve. And whether you adopt their tool or not, the concept behind it — a runtime control plane for AI agent behavior — is something every team running agents in production needs to understand.
What Is a Runtime Control Plane for AI Agents?
A runtime control plane is a centralized layer that enforces behavioral policies across all your agents in real time, without requiring code deployments or agent downtime. Think of it as a policy engine that sits between your agents and the world, intercepting actions and applying rules before consequences happen.
This is distinct from:
- Guardrails at the prompt level — rules baked into system prompts that the LLM can (and does) ignore
- Observability — monitoring that records what happened, post-facto
- Static configuration — environment variables or feature flags set at deploy time
The key word is runtime. When a policy changes — because regulations shifted, a new attack vector was discovered, or a customer segment needs different behavior — you update the control plane once and every agent fleet picks it up immediately. No redeploy. No rollback. No 3am incident.
Why Is This Suddenly Urgent?
Two numbers explain the urgency: 10x and 1000x. By 2027, G2000 enterprise agent deployments are projected to grow 10x, while token and API call volumes will grow 1000x. You cannot manually supervise what you cannot humanly track.
Today's agent governance problem is still manageable for most teams — you have 5 agents, you know what they do, you can eyeball the logs. In 18 months, you'll have 500. At that point, per-agent configuration becomes a maintenance nightmare, and anything baked into prompts is a security liability you can't patch without touching every single agent.
There's also a liability angle that's getting harder to ignore. Last Monday, Santander and Mastercard completed Europe's first live end-to-end payment executed by an AI agent — a real financial transaction, processed through Santander's live payment infrastructure, initiated by an AI acting on a customer's behalf. Agentic commerce is not a future-state thought experiment. Citi, US Bank, Westpac, DBS, and Visa are running similar pilots right now.
When your agent can spend your customer's money, "we'll update the prompt" is not a risk mitigation strategy.
What Does Agent Governance Actually Enforce?
Agent governance policies can intercept and control six categories of agent behavior: content safety, data handling, tool access, cost, tone, and approval routing. Each maps to a class of production failure that observability can detect but cannot prevent.
| Policy Category | What It Prevents | Example Rule |
|---|---|---|
| Content safety | Hallucinations, false claims, harmful output | Block responses with unverified medical/legal claims |
| Data handling | PII leakage, unauthorized data access | Strip or redact PII before tool calls to third-party APIs |
| Tool access | Agents calling tools they shouldn't | Restrict write operations to explicitly approved tool list |
| Cost control | Runaway token spend, expensive model misuse | Route simple queries to cheaper models, cap daily token budgets |
| Tone enforcement | Brand violations, inappropriate responses | Flag responses outside approved sentiment/formality range |
| Human approval | Irreversible high-stakes actions | Require human confirmation before financial transactions or data deletion |
The last category is the one most teams discover they needed after an incident, not before.
How Does Galileo Agent Control Work?
Agent Control is an open-source control plane — Apache 2.0 licensed — that lets teams write behavioral policies once and enforce them across every agent they build or buy. It works as a server your agents route through, with an SDK for integration and support for custom evaluators alongside third-party guardrails.
The architecture has three parts:
Policy definitions — Written once, version-controlled, portable across agent frameworks. Policies define what behavior to check (e.g., "does this response contain PII?") and what to do when a check fails (block, redact, reroute, escalate to human).
Evaluators — Pluggable components that run the checks. Galileo ships built-in evaluators for common cases; you can add custom enterprise evaluators for domain-specific rules. Initial framework integrations include CrewAI, Strands Agents, Glean, and Cisco AI Defense.
Runtime enforcement — Policies are applied at execution time, not deploy time. When you update a policy, all running agents pick it up immediately. No restarts.
The open-source choice is deliberate and worth noting. As Galileo's CTO Yash Sheth put it: "Runtime governance for AI agents should be infrastructure, not a product moat." That's the same argument that drove SSL/TLS and OAuth to become open standards — when something is critical enough to the ecosystem that vendor lock-in actively harms everyone, it tends to get commoditized.
How Does a Control Plane Differ from Prompt-Level Guardrails?
Prompt-level guardrails fail for the same reason security-by-obscurity fails: the enforcement mechanism is inside the thing you're trying to constrain. A control plane enforces from outside the agent, which means it can't be overridden by the model, can't be jailbroken via prompt injection, and doesn't degrade when the context window fills up.
Consider what happens to a "be professional and never share PII" instruction in a system prompt under these conditions:
- A long conversation where the system prompt gets compressed by the model
- A tool call response that injects conflicting instructions (MCP prompt injection is a known attack vector)
- A model update that subtly shifts compliance with the instruction
In all three cases, the guard fails silently. The control plane, sitting outside the agent, is not affected by any of them.
| Mechanism | Location | Overridable? | Runtime updates? | Scales across agents? |
|---|---|---|---|---|
| System prompt rules | Inside the model | Yes (model decides) | Requires redeploy | No — per-agent copy |
| Application-layer filtering | After LLM, before output | No | Requires redeploy | Partially |
| Runtime control plane | External enforcement layer | No | Yes, instantly | Yes — write once |
What About Agent Identity and Authorization?
Governance doesn't exist in isolation. An agent fleet needs to know who each agent is, what it's authorized to do, and whose behalf it's acting on — before behavioral policies can be meaningfully enforced.
I covered the identity side in depth two days ago: enterprises already average 144 machine identities per human employee, and 97% of agent identities carry excessive permissions. A control plane without a solid identity foundation is like a bouncer who doesn't check IDs.
The practical sequence for production readiness:
- Establish identity — who is this agent, and what is it authorized to do? (identity layer)
- Monitor behavior — is it doing what it should, and failing gracefully when it shouldn't? (observability layer)
- Enforce policy — prevent it from taking actions it shouldn't, regardless of what the LLM decides (governance layer)
Most teams have fragments of layers 1 and 2. Almost none have layer 3.
Key Takeaways
- Observability and governance solve different problems. Observability tells you what your agent did. Governance prevents it from doing it in the first place. You need both.
- Runtime policy updates are the critical capability. Anything requiring a redeploy to update a guardrail is too slow for production. When an attack vector is discovered or a regulation changes, you need instant enforcement across your entire fleet.
- Prompt-level rules are not governance. They can be overridden by the model, degraded by context window pressure, or bypassed by prompt injection. External enforcement is the only reliable layer.
- The scale math makes this urgent. 10x more agents and 1000x more token volume by 2027 means manual supervision is structurally impossible within 18 months.
- Agents are already executing financial transactions. Santander and Mastercard completed Europe's first live AI agent payment this month. The "we'll figure out governance when agents do real things" window is closed.
The Bottom Line
The AI agent stack has three layers that matter for production: identity (who is this agent and what can it do), observability (what is it doing and is it failing), and governance (enforce what it's allowed to do at runtime, regardless of what the model decides).
Most teams have invested heavily in identity, started building observability, and treated governance as a future problem. Given the rate at which agents are being handed real authority over real actions, that sequencing is becoming a liability.
Galileo releasing Agent Control as Apache 2.0 infrastructure is the right call at the right time. Whether you adopt their implementation or build your own, the control plane pattern — write policies once, enforce everywhere, update without downtime — is not optional at scale.
The sprinkler system, not just the smoke detector.
AI Agent Digest covers AI agent systems, frameworks, and infrastructure for practitioners who build with these tools. No hype, no vendor bias — just what actually works in production.
Top comments (0)