Handing an AI agent real power over your live apps only works if you can see what it did. Not a vague feeling that it behaved, an actual record you can read. Burrow keeps one: an append only audit log of every guarded, mutating operation, whether an agent or you kicked it off. It is the quiet feature that turns "I hope the agent behaved" into "I can see that it did." Here are seven things that record tells you, and why each one matters.

You read it with one command:

burrow audit

and narrow it with filters as we go.

1. What actually happened, in order

The first and most basic thing: a chronological list of the operations that touched your infrastructure. Deploys, rollbacks, scales, deletes, exposes, DNS writes, addon changes, the actions that matter. Not every idle read, the operations that change something.

So when you sit down after a busy day, or come back to an app you have not looked at in a week, you do not have to reconstruct what went on from memory or guesswork. The sequence is written down. This is the raw material for everything else on this list.

2. Whether an action ran, held, or was refused

This is the column people underestimate. Each entry records not just what was attempted but how it resolved. An operation can have executed, held for your confirmation, or been refused outright by a guardrail.

That means the log is a record of your guardrails working, not just of things that happened. You can see the moment an agent reached for a prod delete and got denied. You can see the deploy that held for your sign off and then went through once you approved. The refusals and holds are as informative as the successes, because they are the evidence that the boundaries you drew are actually being enforced. Filter to just the ones that did not simply run:

burrow audit --outcome held
burrow audit --outcome denied

3. Who asked

Every entry records the principal behind it. Was this you, driving the admin tool directly, or the agent, operating through its scoped channel? When more than one actor can touch your infrastructure, that distinction is the difference between a clear record and a pile of anonymous events.

It also means you can answer "did the agent do this, or did I?" without ambiguity. If a change surprised you, the log says whether it came from your own hand or from the agent, which is usually the first thing you want to know.

4. Which app, host, or addon it touched

Operations are tied to their target, so you can zoom in on one app and see only its history:

burrow audit --app web

That is the view you want when you are investigating a specific service. Everything that happened to web, in order, with outcomes, and nothing about the other apps cluttering it up. When a particular app is misbehaving, its slice of the audit log is often where you find the "oh, that deploy" moment.

5. Exactly which operation, when you are hunting

Sometimes you are looking for a particular kind of action across everything: every rollback, every delete attempt, every deploy. Filter by operation:

burrow audit --operation rollback
burrow audit --operation deploy

This is how you answer questions like "how many times did we roll this back this week?" or "when was the last time anything was deleted?" The log is not just a scroll to eyeball, it is something you can query for the specific thing on your mind.

6. What changed, when something looks off

Put the filters together and the audit log becomes your first stop in an investigation. Something is wrong with an app right now, and the most useful question is usually "what changed recently?" The log answers it directly:

burrow audit --app web

There is the recent history of that app: the deploy an hour ago, the config change before it, the scale last night. More often than not, the cause of a fresh problem is the most recent change, and the audit log puts that change right in front of you instead of leaving you to piece it together from logs and memory. Recovery starts with knowing what moved, and this is where you find out.

7. That you never have to trust blindly

The seventh thing is less a field and more the point of the whole feature. When you let an agent operate production, the reasonable worry is that you are trusting a thing you cannot fully predict. The audit log is the answer to that worry. You are not trusting blindly, because you can always check.

Nothing the agent does in the guarded space is invisible. It proposed, a guardrail decided, and whichever way it went, it was written down: what, who, which target, and how it resolved. That record is what makes delegation to an agent acceptable rather than nerve wracking. You set the boundaries, the agent works inside them, and the log proves it did. Trust, but verify, except you barely have to trust, because verifying is one command.

Combining filters to answer a real question

The filters compose, which is where the log stops being a scroll and becomes a tool. Stack them and you can ask a pointed question and get exactly the rows that answer it. "Did anything get denied on the web app recently?" is a combination of a target and an outcome. "How did our deploys to this app resolve this week?" is a target and an operation. You narrow from the whole history down to the handful of entries you actually care about, instead of reading past everything else.

That composability is what makes the log useful in the two moments you reach for it: during an investigation, when you want the recent changes to one specific app, and during a review, when you want to see whether the guardrails held over some stretch of time. Both are just filters over the same honest record.

It covers you too, not only the agent

One thing worth being clear about: the audit log is not a surveillance tool pointed only at the agent. It records guarded, mutating operations regardless of who ran them, which means your own actions are in there next to the agent's. That is the right design. The question the log answers is "what happened to this infrastructure," and the honest answer includes everything that changed it, whether the request came from your fingers or from the agent working alongside you.

In practice this makes it more useful, not less. When something breaks, you do not want a record that only shows half the changes. You want all of them, in order, so the actual cause is in the list whether you or the agent made it. A log that flattered you by hiding your own mistakes would be worth nothing. This one shows everything, which is exactly why you can rely on it.

What each entry actually carries

It helps to know the shape of a single row, because that is what all the filters slice. Every entry pins down a few things at once: which operation it was (a deploy, a rollback, a delete), which target it touched (an app, a host, an addon), who the principal was (you at the admin tool, or the agent through its scoped channel), which environment it happened in (staging, prod), how it resolved (executed, held, denied), and when. There is one more field that is easy to overlook: the acting client's version, the exact build of the tool that made the request.

That version field earns its place the first time a behavior changes between releases and you are trying to work out which version was in play when something happened. Most of the time you skim past it. When you need it, nothing else answers the question. Together these fields are why the log can answer such pointed questions: every dimension you might filter on is written into the row itself, so narrowing is just picking the fields that matter for the question in front of you.

Reading it through your agent

The audit log is not only your tool. The agent can read it too, through a read only view, and this turns out to be genuinely useful rather than just symmetric. When you ask "what did you change on the web app today?", the agent does not have to reconstruct from its own memory of the conversation, which could be wrong or incomplete. It reads the same honest record you would:

burrow-agent audit

That is deliberately read only. The agent can look at the trail, summarize it, and reason over it, but it cannot write to it, edit it, or remove an entry, any more than you can. The record's integrity does not depend on trusting the agent, because the agent has no more power over the log than to read it. So when the agent tells you "I deployed web twice and rolled it back once, and the prod delete I proposed was denied," it is reading that off the same append only trail you can check yourself. The agent summarizing the log is a convenience; the log being the source of truth is the guarantee.

Reading the environment on each row

Every entry records which environment the operation happened in, so a prod deploy and a staging deploy are never confused in the log. If you run a separate cluster per environment, the trail is already scoped to whichever environment you are pointed at, so switching to prod and then reading the log gives you the production view on its own:

burrow env use prod
burrow audit

That is the view for a focused question like "what happened in production this week?", with staging's noisier, lower stakes activity left out. Because prod is where the guardrails are strictest, its slice of the log is usually the one you most want to skim during a review: it is the shortest list and the one where every hold and denial carries the most meaning. Even when staging and prod share a cluster, the environment sits right there on each row, so you can pick out the production lines at a glance.

Why it is append only

One design detail worth calling out: the log is append only. Entries are added, never quietly edited or removed. That is deliberate, because a record you can change is not really a record. The value of an audit trail is that it reflects what happened, faithfully, including the parts someone might prefer to forget. An operation that was refused stays in the log as refused. A deploy that held for approval stays as held. The history is the history.

A habit worth forming

The audit log is most valuable when looking at it is routine rather than something you only do in a panic. A quick glance at the end of a busy session, especially a session where you handed a lot to your agent, turns the record from an emergency tool into a steady sense of what is going on with your infrastructure.

It takes seconds. Run burrow audit, or narrow it to the app you were working on, and skim the resolutions. Did the deploys execute? Did the risky things hold and wait for you, as they should have? Was anything denied, and if so, was that the guardrail doing its job? You are not auditing in the heavy, formal sense, you are just staying oriented. Over time this builds real trust in the delegation, because you are not taking it on faith that the boundaries hold, you are casually confirming it, again and again, until it is simply how things feel.

That is the quiet payoff of an honest record you can read in one command: not that you pore over it, but that you can, whenever you want, and knowing you can is most of what makes handing work to an agent comfortable.

The bigger picture

Guardrails decide what is allowed to happen. Warm rollbacks give you a fast way back when something slips through. The audit log is the third piece: the record that ties it all together and lets you look back. Set the boundaries, recover quickly, and see everything that happened. Those three together are what "let an agent operate my infrastructure" can actually mean without it being reckless.

A short FAQ

Does the log record my own actions, or only the agent's? Both. It records guarded, mutating operations regardless of who ran them, so your own deploys and rollbacks sit right next to the agent's. That is the right design: the question the log answers is "what happened to this infrastructure," and the honest answer includes everything that changed it. A log that hid your own mistakes would be worth nothing.

Can the agent tamper with the log to cover a mistake? No. The agent's access is read only, and the log is append only for everyone: entries are added, never edited or quietly removed. A refused operation stays in the log as refused. A deploy that held for approval stays as held. Neither you nor the agent can rewrite the history.

Does it log every little read? No. It records the operations that change something (deploys, rollbacks, scales, deletes, exposes, DNS writes, addon changes) and how each resolved. Idle reads and status checks are not the point; what moved is.

How do I answer a specific question fast? Stack filters. "Did anything get denied on web recently?" is a target plus an outcome (burrow audit --app web --outcome denied). "How did our deploys resolve this week?" is an operation filter (burrow audit --operation deploy), and the environment recorded on each row tells you which were prod. You narrow from the whole history down to the handful of rows that answer the question, instead of reading past everything else.

What does a held entry mean? That a guardrail paused the operation for your confirmation. If it later went through, you approved it; if it did not, it stopped there. Holds and denials are as informative as successes, because they are the evidence that the boundaries you drew are actually being enforced.

So the next time you wonder what your agent, or you, did to a live app, you do not have to wonder. Run burrow audit, filter to what you care about, and read it. The whole story is there, in order, honest, and one command away.