An AI agent control plane is the layer that governs AI agents from outside the model: it gives each agent an identity, decides what it may do and spend, stops it for a person before actions that matter, and keeps a verifiable record of everything it did.
Agent frameworks are good at making agents capable: they connect a model to tools, memory and other agents. A control plane is what makes those agents safe to run in an organisation. It sits between the agents and everything they touch, and it does not trust the model to police itself, because a model reads text and text can be written by anybody.
Why agents need one
An agent that reads a web page, an email or a support ticket can be steered by instructions hidden in it. That is prompt injection, and no prompt fully prevents it. Once agents can send email, change records, call internal APIs or spend money, the question stops being "is the model clever enough?" and becomes "what is it allowed to do, and who decided?"
At the same time, regulators and security teams ask for the same things a control plane provides: an inventory of AI systems, human oversight, logs that cannot be quietly changed, and evidence that the controls work.
What a control plane does
| Job | What it means | In Quilzo |
|---|---|---|
| Identity | Every agent is a known principal that somebody answers for | A sponsor and an end date for each agent; it stops when the sponsor leaves |
| Policy | What each agent may read, call and change | A declaration per agent, enforced by one gate on every action |
| Budgets | Limits on steps, time, tokens and money | Per run, and per caller per day or month at the model gateway |
| Human oversight | A person decides the actions that matter | Ask-first capabilities, the exfiltration breaker and an approvals inbox |
| Gateways | One governed route to models and tools | A model gateway with privacy masking, and an MCP gateway for your tool servers |
| Audit | A record that can be trusted later | A hash-chained log signed with Ed25519 and ML-DSA, and receipts per run |
| Inventory | Knowing every agent and AI service in use | The Fleet map, and shadow AI found in the logs you already collect |
How Quilzo works
A declaration, not a prompt
Each agent is one reviewable document: its purpose, the capabilities and content it may use, its tools by host, its budget and how much autonomy it has. The model chooses from that list and cannot add to it.
{
"name": "page-tidier",
"purpose": "Draft small fixes to pages, asking before each change",
"capabilities": ["list_pages", "read_page", "write_page"],
"autonomy": "draft",
"ask_first": ["write_page"],
"budget": { "steps": 25, "tool_calls": 15, "duration": "10m0s" }
}
One gate for every action
Whether the next step is chosen by a model, by the agent's own program running in a sandbox, or by another vendor's agent arriving over MCP or A2A, it passes the same gate. A hijacked agent can still only do what its declaration allowed before anybody talked to it.
Autonomy is earned
An agent runs on its own only after evaluations, with attacks planted in what it reads, show it is not steered. If it follows a planted instruction, it drops back to asking.
Every action is provable
Runs come with receipts: each record with an inclusion proof against a log head signed with Ed25519 and post-quantum ML-DSA, so anybody can check what happened against published keys.
Who it is for
- Teams putting AI agents into production who need them to act without being able to go rogue.
- Security teams who must answer "what can this agent do, and what did it do?"
- Organisations that need EU AI Act, ISO/IEC 42001 or NIST AI RMF evidence for their AI systems.
- Anyone who wants to keep prompts, data and logs on their own infrastructure.