Give agents the cluster. Keep every receipt.
An MCP server that lets an assistant inspect and change services in your cluster the way a developer would — wrapped in RBAC, policy enforced at admission, and a complete recording of everything it touched.
Fast enough to be worth it. Governed enough to be allowed.
Every enterprise is being offered the same two bad options
Option one
Let it move fast
Hand an agent broad credentials and hope. It is genuinely productive, right up until nobody can reconstruct what changed, or something reaches an environment it should never have touched.
Option two
Lock it down
Route everything through the existing change process. Safe, and slow enough that developers stop reaching for the tool, which means you paid for a capability nobody uses.
The third option
The choice only looks binary because, on most platforms, the guardrails live in the tool. Move the guardrails into the cluster — permissions in RBAC, constraints enforced at admission, an immutable record of every mutation — and speed stops being the thing you trade away for control. An agent moving quickly inside boundaries it cannot cross is not a risk you are tolerating. It is the design.
Explore fast, then make it permanent
The exploratory path and the governed path are the same path at different stages, which is why nothing has to be redone by hand to become official.
01
Explore in-cluster
A developer or an assistant drives the platform through MCP: change a service, sync code into a dev-mode pod, run a pipeline, read the telemetry back. Iteration is seconds, against real infrastructure.
How dev mode works →02
Stay inside the lines
RBAC scopes what is reachable. Policy is evaluated at admission, so a change that violates it is rejected by the cluster rather than by the agent choosing to behave.
Policy administration →03
See what actually happened
Every mutation is recorded as it occurs, and full-fidelity telemetry shows the effect. Not a summary the agent wrote about itself — the actual before and after.
Cluster history →04
Codify the delta
What worked becomes declared state: the difference between where you started and where you ended, turned into policy and configuration you review as a diff and merge through Git.
Promotion path →Most teams run step one and step four as separate systems and reconcile them manually, which is exactly where the drift comes from.
The guardrails aren’t the agent’s to respect
Every control here is enforced by the platform, below the tool. It holds the same whether the actor is an assistant, a script, or a person in a hurry.
Scoped by RBAC
An agent gets an identity with an explicit permission set, the same as a person. What it may read, change, or deploy is a decision you make once and enforce everywhere, not a prompt you hope it honours.
Constrained at admission
Policy is evaluated by the cluster when the change is submitted. An agent cannot talk its way past a constraint, because the constraint is not part of the conversation.
Recorded, always
Every create, update, and delete is captured as it happens, with the body content-addressed. You can diff any two moments and see precisely what an agent changed, including changes it did not mention.
Reversible
Because the record includes what things looked like beforehand and how resources depend on each other, undoing a bad session is a restore rather than an archaeology project.
Observed at full fidelity
The effect of a change is visible in complete telemetry rather than a sample. An agent cannot quietly degrade something that nothing was watching, because everything is watched.
Blast radius, before the blast
The dependency graph answers what else consumes a resource, so the consequences of a change can be examined before it is made rather than discovered afterwards.
An agent reasoning over sampled data is guessing confidently
This is the part most platforms will not be able to fix. If your observability vendor discarded 95% of your traces to control their storage costs, then every assistant you point at that data is reasoning from a sample — and will tell you what usually happens with the same confidence it would tell you what did happen.
Rare events are exactly the ones sampling drops and exactly the ones worth asking about. Keeping everything is not a nice-to-have for agentic workflows. It is the precondition for them being trustworthy.
Your code gets to production faster, better, and cheaper
Kubernetes is usually sold as a trade: control and compliance in exchange for slowing your developers down. We think that trade was always a symptom of where the guardrails were placed.
Faster
Iteration in seconds against real infrastructure, with no rebuild between an idea and seeing it run. Developers keep the tool because it is genuinely quicker than not using it.
Safer
Permissions, policy, and a complete change record enforced by the cluster. Your compliance story gets stronger when agents are involved, because the evidence is automatic rather than remembered.
Cheaper
No image build to try a change, no throwaway registry tags, no idle environments waiting to be used. The fast path is also the one that provisions the least.
You do not have to handcuff your developers to a slow process to satisfy an auditor. You have to put the constraints somewhere they cannot be bypassed, and then get out of the way.
Frequently asked questions
- What does the MCP server actually let an agent do?
- Inspect and mutate services in the cluster: read state, change configuration, sync code into a dev-mode pod, run a pipeline, query telemetry, and read back what happened. It is the same surface a developer drives from the CLI, exposed so an assistant can drive it too. What any given agent may reach is scoped by platform RBAC, so the surface is narrower than the API it sits on.
- Isn't giving an AI agent cluster access exactly what security teams are worried about?
- Yes, and they are right to be, when the only options are unscoped access or none. What makes it acceptable here is that the guardrails are not the agent's to respect. RBAC decides what it may touch, policy is enforced at admission by the cluster rather than by the tool, and every mutation is recorded whether or not the agent mentions it. An agent operating on this platform is not on its honour.
- How does an experiment become something I can actually ship?
- The changes made in-cluster are a delta against declared state, and that delta can be codified into policy and configuration you review as a diff and merge through Git. The fast, exploratory path and the governed, declarative path are the same path at different stages, rather than two separate systems you reconcile by hand.
- Why does zero sampling matter for agents specifically?
- An agent reasoning about your system can only be as good as what it can see. If 95% of your traces were discarded before it looked, it is inferring from a sample and presenting the inference with confidence. Full-fidelity telemetry is the difference between an agent that can answer what happened and one that produces a plausible story about what usually happens.
- Can I let agents into some environments and not others?
- Yes. Scoping is by namespace and cluster, so a common arrangement is broad latitude in development, tighter constraints in staging, and human review on anything reaching production. Because the constraints are policy rather than convention, the boundary holds regardless of which tool or which agent is on the other side of it.
Let your developers use the good tools
Bring us the objection your security team raised. It is usually the most productive conversation we have.