You want your AI coding agent to do more than write code. You want it to deploy, read logs, roll back, and keep your app running. The moment you think about actually giving it that power, though, a sensible worry shows up: this thing is going to have access to my production infrastructure. What exactly can it reach, and what stops it from reaching too far?
Burrow's whole answer is to give the agent real operational power without giving it the keys. This guide explains how that works, because the how is what should let you relax. It comes down to a few deliberate boundaries, each one enforced in code rather than requested in an instruction.
The core move: the agent holds no credentials
Start with the thing that surprises people. Your agent never holds your cluster credentials.
When you wire up an agent, it drives a scoped command surface called burrow-agent. That surface talks to the part of Burrow you installed on your cluster, and that part is what holds the credentials and talks to Kubernetes. The agent is a thin client. It can ask Burrow to do things, and Burrow decides whether to do them, but the agent itself cannot reach the cluster directly, because it has nothing to reach it with.
This matters because it changes where the security boundary lives. It is not sitting inside the agent, depending on the agent behaving. It sits in the part you own and installed. A confused agent, a bad prompt, a step that goes sideways, none of them can cross a line the agent has no ability to cross in the first place.
You set this up with one command:
burrow agent claude install
That gives the agent permission to run burrow-agent and denies it the full admin CLI. So the agent operates through the guarded path and cannot pick up the unscoped tool that would go around it.
Boundary one: the agent's tool literally cannot express the dangerous verbs
Here is a boundary that is easy to miss and worth dwelling on. The admin commands, installing Burrow, bootstrapping a cluster, setting guardrail policy, writing credentials, are not part of the agent's command surface at all. Not denied by policy, not hidden behind a flag. Structurally absent. The burrow-agent binary cannot express them because they were never built into it.
That is a stronger guarantee than a rule. A rule can be misread. A command that does not exist cannot be run. The agent operates the app level verbs, deploy, rollback, scale, logs, and the destructive ones are guarded, but the "change the rules themselves" verbs live only in the admin tool that you use, and the agent does not have.
Boundary two: your code never travels through the agent
The second worry people have is their source code streaming through an agent's connection, sitting in a conversation, getting sent again on every later message. Burrow's design rules that out.
Burrow deploys by image reference. The agent builds an image with its own tooling and pushes it to your registry, exactly as you would, then deploys by naming the reference. The only things that cross the agent's channel are the reference and small metadata. Your code takes the registry path, the same path it always takes. The channel is the remote control, the registry is the conveyor belt, and they never mix.
So "the agent can deploy my app" does not mean "my code flows through the agent." It means the agent can point Burrow at an image and say run this. Your source stays where it belongs.
Boundary three: secret values never route through the agent
Config and secrets are handled differently on purpose, and the difference is a boundary you should know about.
Ordinary config, an app can have the agent set it, that is fine. But secret values, an API key, a database password, deliberately never travel through the agent's channel. There is no "set secret value" command in the agent's tool at all. You set secrets yourself, at your own terminal:
burrow app secret set web STRIPE_SECRET_KEY=sk_live_...
That value goes straight to Burrow over an authenticated connection, gets stored safely for the app, and is never logged. The agent can confirm the key exists:
burrow-agent secret web
but that only lists the key names, never the values. So your agent can know that STRIPE_SECRET_KEY is set and wire your app to use it, without ever seeing what it is. Never paste a secret into an agent prompt, and with Burrow you never have to, because the safe path is the built in one.
Boundary four: guardrails decide, per environment
On top of all that sits the policy layer. Guardrails let you gate the risky actions, deleting an app, deploying to prod, exposing something publicly, changing DNS, touching addons, per environment. Each can be set to allow, hold for your confirmation, or deny outright.
burrow guard set --env prod app.delete deny
burrow guard set --env prod app.deploy confirm
Because this policy lives in the part of Burrow that holds the credentials, the agent cannot route around it. A denied action never runs. A held action comes back to you, and only your explicit approval lets it through. The agent proposes, you decide, and it cannot self approve. That last rule is not a suggestion to the agent, it is enforced: a held operation stays held until a human confirms.
Boundary five: everything the agent does is written down
Finally, none of the agent's guarded, mutating operations are invisible. They are recorded in an append only audit log: what happened, who asked, and how it resolved, whether it executed, held, or was refused.
burrow audit --app web
So you never have to take it on faith that the agent behaved. You can read that it did. That record is also your answer to "what changed?" when something looks off, and it covers both the agent's actions and your own.
The worry answered: what if the agent just goes wrong?
Every boundary above is designed around one honest assumption: the agent might misbehave, whether through a bad prompt, a confused chain of reasoning, or a genuine mistake. The whole model is built so that a misbehaving agent still cannot cross the important lines, because the lines do not depend on the agent being well behaved.
That is the difference between an instruction and a control. "Be careful with prod" is an instruction. An agent can read it, agree with it, and then do something reckless anyway, because an instruction is a wish about behavior. A guardrail that lives in the part of Burrow holding your credentials is a control. It does not ask the agent to behave, it makes the unwanted action not happen, regardless of what the agent intended. Same with the missing admin verbs, the code that never crosses the channel, the secret values it cannot read. None of those rely on trust. They are true even on the agent's worst day.
So the reasonable answer to "what if it goes rogue?" is: it can still only do the things on the near side of your boundaries, at full speed, which is exactly what you wanted it able to do anyway. The blast radius of a misbehaving agent is bounded by the policy you set, not by the quality of its judgment in the moment.
Wiring any agent, not just a favored one
None of this is tied to one specific agent. Burrow's command surface for agents is deliberately neutral: it is a plain command that outputs plain, structured results, which means any agent that can run a command and read its output can drive it. If your agent has a built in setup, one command wires it up. If it does not, you point it at the same command surface by hand. Either way it gets the same scoped access, under the same guardrails, with the same boundaries. You are not locked into a particular assistant to get safe operation, you bring the agent you already use.
What a guarded moment actually looks like
The boundaries above are easier to trust once you have seen one in motion, so here is the shape of a guarded exchange end to end. Say you have told Burrow that prod deploys hold for your confirmation:
burrow guard set --env prod app.deploy confirm
Later the agent has a fix ready and reaches for prod. Instead of the deploy going through, it comes back as a structured result the agent can read and relay:
outcome: held_for_confirmation
operation: deploy
code: app.deploy
message: guardrail holds prod deploy for confirmation
The agent tells you, in its own words, that it wants to ship this version to prod and is waiting on you. You look at the change, and if it is sensible you approve. Only after your explicit approval does the agent retry with confirmation attached. It cannot supply that approval itself: the confirm is a signal that a human said yes, not a flag the agent is free to set on its own, and a held operation stays held until that happens. Deny works the same way but harder, a denied action never runs at all, no confirmation available.
You can always check the current dispositions before you act, so there is no guessing about what is gated:
burrow-agent guard
That lists which operations are set to allow, confirm, or deny, per environment, which is the map of where the agent moves freely and where it has to stop and ask.
Boundary six: the environment target is explicit and sticky
One more line worth calling out on its own, because it prevents a whole class of accident. A mutating operation always runs against an explicit environment, and that target is sticky: it does not silently drift from staging to prod between commands. So the agent cannot accidentally land a staging fix on production because it lost track of where it was. Prod is a deliberate destination, and reaching it trips prod's own guardrail on the way in. The credential the agent is given is scoped and least privilege from the moment it is minted at install time, so even its reach across environments is bounded by what you granted, not by what it decides in the moment.
Common worries, answered plainly
If the agent has no credentials, how does anything get deployed? The control plane you installed holds the credentials and does the deploying. The agent asks it to act through burrow-agent, and the control plane decides whether to. The power is real, it just lives in the part you own rather than in the agent.
Could the agent read my database password to "help"? No. There is no command in its surface that returns a secret's value. It can confirm a key is set (burrow-agent secret web lists names only) and wire the app to use it, but the value itself never crosses the channel. You set secrets at your own terminal with burrow app secret set.
What stops the agent from just turning off a guardrail? Guardrails are set with the admin CLI (burrow guard set), which is not part of the agent's tool at all. The verbs that change the rules live only in the tool you use. The agent operates within the policy, it cannot rewrite it.
How do I know later what it actually did? Every guarded, mutating operation is written to an append only audit log, the agent's actions and your own alike:
burrow audit --app web
You read the record rather than trust a promise.
Does this only work with one specific agent? No. The surface is a plain command with structured output, so any agent that can run a command and read the result can drive it. A built in setup wires up in one line (burrow agent claude install); anything else you point at the same command by hand.
Putting the boundaries together
Step back and look at the shape. The agent holds no credentials, so the boundary lives in the part you own. The dangerous admin verbs are not in its tool at all. Your code never crosses its channel. Secret values never cross it either. Guardrails you set gate the risky actions, per environment, and the agent cannot get past them or approve itself. And everything guarded is logged.
That is a lot of "cannot," and it adds up to something freeing rather than restrictive. Because the agent genuinely cannot cross these lines, you can let it do everything on the near side of them at full speed. You are not choosing between a useful agent and a safe one. The boundaries are what make it safe to let the agent be useful, on your real infrastructure, with the keys still in your pocket.