Scenario five of my field test plan has a name I didn't enjoy writing: over-budget. I built an agent with a single job — burn money — aimed it at my own control plane, and watched the run die the instant priced usage crossed its per-run ceiling.
I cheered. That was the moment "Kubernetes for agents" stopped being a tagline. I had put the sentence in my README six weeks earlier, and only now understood which half of it mattered.
If you run more than one agent anywhere near production, this is the story I wish someone had told me before I started.
Control planes keep finding me: a tool gatekeeper that 14 developers turned into a control plane, an MCP control plane, and now agents themselves. The series that led here started with the gate that says no — this piece is the thesis underneath it.
The sentence I wrote before I understood it
Kubernetes didn't win by running containers — it won by making desired state a contract and admission a gate. You declare, a controller reconciles, and an admission controller decides what is allowed to exist at all. I had built the declarative part: one workload manifest per agent — owner, tools, model identity, budgets, certification thresholds — and a loop to enforce it.
The ecosystem, meanwhile, is converging on the same substrate from the other side. kagent (CNCF Sandbox, from the founders of Istio) makes agents Kubernetes CRDs — GitOps, kubectl, RBAC, mesh mTLS. agent-sandbox (Kubernetes SIG Apps) gives them the Sandbox CRD: gVisor/Kata isolation, stable identity, warm pools.
Both are right, and both are the floor. One gives you placement. One gives you isolation. Neither asks the question that keeps operators awake:
Has this agent proven it is allowed to run — and who owns it when it goes wrong?
My field test turned out to be ten attempts to answer exactly that. The report came back 10/10, all 20 acceptance criteria, but the receipts that taught me something were the refusals.
What I threw at my own gate
I didn't test happy paths. I built deliberately bad agents and aimed them at the admission gate I'd written:
| Scenario | What I threw at it | What the plane did |
|---|---|---|
| S2 | An uncertified agent, submitted straight to production |
403 — "certification status 'uncertified' is insufficient for production; requires 'certified'"
|
| S3 | The same agent, certified — then its model quietly swapped |
403, because identity binds to the attestation, not the editable manifest |
| S4 | An agent that looked fine and wasn't | Benchmark caught the regression; status dropped, critical failure named |
| S5 | The money-burner | Killed at the priced-usage ceiling, mid-run |
| S7 | A tool dumping 40,002 bytes of output | Truncated to 16,384 before it ever reached the model's context |
The S3 moment deserves its own article (it's the next one in this series), because for an hour the attack worked — 201, admitted — and the post-mortem showed the gate was right and my test was wrong.
But S4 is the one that changed how I think. The agent hadn't changed its manifest, swapped its model, or exceeded anything. It had just quietly gotten worse at its job. No framework catches that, because no framework is watching. The benchmark did, because certification runs the agent's actual work as real runs and compares the verdicts.
tip: A gate that only fires on what changes is half a gate. The dangerous agent is usually the one that drifted, not the one that got edited — the same lesson as the checks AI will skip until you make them a gate.
The three things the field test taught me
The refusals are the product. Any platform can start runs. Mine earned my trust by refusing one with a reason I could act on. "Forbidden" is a dead end; 403: certification status 'uncertified' is a workflow.
Certification is a security control, not a quality metric. The moment production admission depends on a signed Ed25519 attestation bound to the exact model identity, a whole attack class — swap the model, edit the manifest, quietly regress — becomes blocked and auditable. The security audit is the boring part; the refusals are the interesting one.
Slow governance gets bypassed. S10 measured inspect-plus-stop at 0.04 seconds; scaffolding a new fleet at 0.24. If saying no takes longer than a Slack message to the agent's author, people route around you — and a bypassed control plane is an expensive dashboard.
What v0.1.0 doesn't do
- Two adapters ship — raw Python workers and LangGraph, behind one conformance suite. Broader coverage is deliberately deferred; if a control plane knows too much about one runtime, it becomes a framework wrapper.
- The drift detector ships next. Today re-certification is scheduled and change-triggered — it catches what changes, and S4 is my proof that what fades is the harder half.
- One model identity validated this cycle; the real-priced cloud run is the next field test.
- It's single-tenant. Tenancy is where the next release starts, and building that schema has already taught me the uncomfortable lesson — isolation is structural or it's imaginary — but that's a story for when it ships.
The rest of the operating model — triggers, multi-agent pipelines, desired-state reconciliation from Git — is roadmap, not release. I'll write about each piece when it's true.
References
-
HivePlane —
pip install hiveplane, Apache-2.0 - Field test report (10/10, 20 criteria) · Docker test report (25/25)
- v0.1.0 release notes
- kagent · agent-sandbox — the Kubernetes-native wave this article argues is the floor
If Kubernetes is the floor and frameworks are the runtime — what's your admission controller? When an agent goes wrong where you work, can you prove what it was allowed to do?
