The AI agent governance stack

A platform agent can't tell you where it ran, what secrets it accessed, or whether the completion it reported was real.

If you're running more than a couple of agents, that sentence should bother you. Not because your agents are malicious. Most of the time they're doing exactly what you asked. It bothers you because you're being asked to trust work you can't see, done by a worker you can't fully account for, using access you didn't scope. And as you go from one agent to a fleet, the gap between "it said it was done" and "I know it was done" stops being a curiosity and starts being a cost.

For most of the last year the conversation around that gap was one word: accountability. Who is responsible when an agent does something wrong? It was a good question. But it turns out "accountability" was hiding three separate questions inside it, and over a couple of weeks this summer the market pulled them apart. Credential confinement, run isolation, and run attribution each showed up as its own problem, with its own tooling, from independent directions at the same time.

That's what a governance stack is. Not a single feature you buy, but three layers that answer three different questions about every piece of work an agent does:

1. Where did it run, and what could it reach? (the isolation layer)
2. What secrets did it touch, and could it leak them? (the credential layer)
3. Was the completion it reported actually real? (the attribution layer)

Miss any one and the other two don't save you. A perfectly sandboxed agent with a shared credential pool still leaks secrets. A vault-backed agent that reports false completions still corrupts your board. This is why it's a stack, and why the interesting question is no longer "is anyone accountable?" but "what does the full trust stack look like, and where are my gaps?"

Let me walk through the three layers the way an operator actually hits them.

Layer 1: Sandbox isolation

The first thing you lose when you scale past one agent is a clear answer to "where did this run and what could it touch?"

A single agent on your laptop has the run of your machine, your network, and whatever credentials happen to be in your environment. That's fine for one agent you're watching. It's not fine for ten agents you're not. The default posture of most agent setups is ambient access: whatever the process can reach, the agent can reach. Your filesystem, your local services, the open internet, package registries, internal APIs, all of it, all the time, for every task.

Agent sandbox isolation flips that default. Instead of ambient access, each run gets a confined environment with a default-deny network policy, and the specific access a task legitimately needs is granted per job rather than left open for everything. A task that needs to pull from a package registry or hit a GitHub API can be given exactly that reach, task-scoped, not namespace-wide.

This is the layer where the vocabulary is moving fastest right now. "Agent jails," microVM sandboxes, copy-on-write snapshots for cheap disposable runs, the economics of spinning environments up and down. A whole category is forming around the cost of running agents safely. Most of that discussion skews toward platform builders and security researchers. The operator translation is simpler and more useful: you should be able to grant an agent task-scoped access per job, and deny everything else by default. If your setup can't express "this run may reach the internet, that one may not," you don't have an isolation layer; you have hope.

The reason this matters commercially isn't compliance theater. It's that isolation is what makes it safe to delegate more. The better your answer to "what could this run reach," the more real, credentialed work you can hand a fleet without lying awake about blast radius.

(Deeper dive: AI agent sandboxing is the layer your fleet needs after the audit trail.)

Layer 2: Credential confinement

The second question is the one that keeps operators from handing agents anything valuable: what happens to a secret after you give it to an agent?

The honest answer, in most setups, is: you don't know. You put an API key in an environment variable, or paste a token into a prompt, and from that moment it lives wherever the agent decides to put it. Maybe it's logged. Maybe it's written to a file. Maybe it ends up in a completion the agent reports back. That uncertainty is the single biggest reason people keep their agents on toy problems instead of trusted ones.

Credential confinement closes that gap by changing when and how a secret reaches the agent. Instead of secrets sitting in a shared, always-on pool, access becomes run-bound: the credential is delivered scoped to a specific run, audit-logged, and referenced by alias rather than sprayed across the environment. Pull it from a real vault, specifically the kind of Bitwarden or 1Password integration that's now shipping natively in agent tooling, and the secret never has to live in the agent's world as a raw, persistent value at all.

The shape operators want here is specific, and it's worth stating plainly:

• Secrets accessible run-by-run, not fleet-wide
• Every access audit-logged, so "what did this run touch" has an answer
• Vault-backed, so the source of truth is a system built to hold secrets, not a .env file and good intentions

This is the layer where the market is converging hardest. Two platforms shipped toward the same problem in the same stretch. When two independent actors build the same thing in parallel, it's usually because the pain became undeniable. Here it did: you cannot responsibly give a fleet real work if you can't confine what it can leak.

(Deeper dive: Getting AI agent credential security right in production.)

Layer 3: Run attribution

The third layer is the quietest and, at scale, the most expensive. It's not about what an agent could do wrong. It's about whether you can trust what it says it did.

Here's the failure mode that makes this concrete. A clean process exit does not prove the assigned work is done. An agent can stop, report done, and be wrong: the work was actually blocked, or unverifiable, or never happened. That gap turns unfinished work into a false completion and hides the real next action from your board. Multiply that across a fleet and your ground truth quietly drifts from reality.

It gets worse when attribution itself is wrong. Consider a run that writes something to your system but gets logged as if a human did it, not an agent. Now your control plane can't tell operator intent from agent action, and in one real case that exact confusion created a self-sustaining wake loop that burned compute doing nothing but re-triggering itself until someone noticed. Attribution stopped being a correctness nicety and became a line item on the bill.

Run attribution is the layer that answers "who actually did this, and did the reported outcome match what happened?" It's the difference between a board you can read and a board you have to re-verify by hand. Concretely it means:

• Every action stamped with who or what performed it: agent vs. operator, unambiguously
• Completions that reflect verified state, not just a process that exited cleanly
• A control plane where "blocked" stays blocked until the work is genuinely unblocked

The encouraging part: this is a solvable, closing class of problem. The failures above are being systematically fixed at the platform level. False-completion and attribution-loop variants are closing out one after another. But you only get the benefit if your setup treats attribution as a first-class layer, not an afterthought you reconstruct from logs when something goes wrong.

The stack, not the checklist

It's tempting to read those three layers as a checklist: sandbox, secrets, attribution, tick, tick, tick. They're not a checklist. They're a stack, and the order compounds.

• Isolation decides what a run could touch.
• Confinement decides what secrets it may touch within that.
• Attribution decides whether you can believe what it reports about any of it.

Each layer assumes the one beneath it. Attribution is worth little if credentials are shared, because "who did it" blurs the moment the whole fleet shares one identity. Credential confinement is worth little if the run has ambient network access, because a confined secret still escapes through an open pipe. Isolation without attribution just means your untrusted work is neatly contained and completely unverifiable.

This is why "AI agent governance stack" is the right frame and "agent security" isn't. Security suggests a wall you build once. A governance stack is the standing infrastructure that lets a governed agent company delegate real work: the trust infrastructure underneath every task, not a gate at the edge.

What this means if you're running a fleet

If you're an operator moving from a couple of agents to a fleet, the practical takeaway is a diagnostic, not a purchase:

1. Isolation: Can you say, per run, what it was allowed to reach? If the answer is "whatever the process could reach," that's gap one.
2. Confinement: Can you say, per run, which secrets it touched, and are those secrets run-bound and audit-logged rather than pooled? If secrets live in a shared environment, that's gap two.
3. Attribution: When an agent reports done, do you trust it without re-checking? If not, that's gap three, and it's the one that scales into real cost.

The good news is that none of this is aspirational anymore. Every layer has shipping proof in the market: run-bound, audit-logged secret access; native vault integration; attribution fixes landing at the platform level. The building blocks exist. The work, and it is real work, is wiring them into a coherent stack instead of three disconnected features.

That wiring is exactly what I'm building toward with pre-configured, governed setups: the three layers assembled and attributed by default, so an operator doesn't have to become a governance engineer to safely hand agents work that matters. More on that soon.

Following the governance-stack work? The two companion pieces go a layer deeper on isolation and credentials, read those next.

— Kimmo