A vault, a broker and a sandbox tend to get described as if they were three answers to one question. They are not. Each answers a different question about what an AI agent can do, and the question none of them answers is the one that decides whether you can explain what happened after something goes wrong.
Most teams running coding agents already have some of the three. Secrets live in a vault. A broker may hand out short-lived tokens instead of long-lived ones. The agent may run in a container. Keep all of it. This page is about what each piece covers, and the gap that stays open when they are all in place.
The four, in one line each
A vault decides where a secret is stored and who may fetch it.
A broker decides how a secret reaches the process that needs it, ideally without that process ever holding the long-lived value.
A sandbox decides what a process can touch: which files, which network, which devices.
node9 sits at the tool call. It decides whether a specific action is allowed right now, records that it ran, and keeps that record across every agent on the machine.
The questions each one answers
About the secret itself
| The question | Vault | Broker | Sandbox | node9 |
|---|---|---|---|---|
| Where is it stored? | yes | partly | no | no |
| Who is allowed to fetch it? | yes | partly | no | partly |
| Does the agent hold the long-lived value? | no | yes | no | no |
About the boundary
| The question | Vault | Broker | Sandbox | node9 |
|---|---|---|---|---|
| Which files can this process open? | no | no | yes | partly |
| Where can it send data? | no | no | yes | partly |
About the action
| The question | Vault | Broker | Sandbox | node9 |
|---|---|---|---|---|
| Was this specific action allowed? | no | no | no | yes |
| Did a credential leave inside an argument? | no | no | no | yes |
| Did a connected tool server change what it exposes? | no | no | no | yes |
Afterwards
| The question | Vault | Broker | Sandbox | node9 |
|---|---|---|---|---|
| What did every agent on this machine do? | no | no | no | yes |
| What did it cost? | no | no | no | yes |
A "partly" in the node9 column means the question is answered for what the agent asks to do, not for every process on the machine. node9 sees the agent's tool calls. It does not see a cron job the agent never touched.
The rows that matter are the last five. Nothing in the first three columns answers any of them.
Where each one stops
Each one stops where its design says it should.
A vault stops at retrieval. It can tell you a credential was fetched, by which identity, at what time. It cannot tell you why, or what happened in the second after. Once the fetch succeeds, the vault is done.
A broker stops at possession. A short-lived, narrowly scoped token is a smaller thing to lose, and that is worth having. But the action the token authorizes still runs. A broker does not ask whether pushing to this branch, in this repository, at this moment, is a reasonable thing for the agent to be doing. It manages who holds the key, not what the key gets turned in.
A sandbox stops at the boundary. That is the right tool when something unknown is about to run. The trouble is that most of the damage an agent can do happens inside the boundary you gave it on purpose. The agent is supposed to read the repository, run the build, and usually reach the network. Tighten the sandbox until those are blocked and you have blocked the work. Leave it loose enough for the work and you have left room for most of what goes wrong.
We wrote separately about running an agent native versus sandboxed, and why it is not an either/or choice.
The shape they share
All three are set up in advance, and then they are silent.
Each draws a line before the agent starts. Once the agent is working inside that line, which is the whole reason it exists, none of the three has anything further to say. They were configured. Now they are waiting.
That is how a boundary should behave; one that kept renegotiating itself would not be a boundary. It does mean a whole class of events happens somewhere none of them is looking.
The vendors say the same thing
You do not have to take that from us. It is in the documentation.
AWS logs the moment a role is assumed. For every API call the role then makes, CloudTrail records the user identity as "Role identity only (no user)". Those are AWS's words, in AWS's own table. The issuance record is exact. The usage record is not.
HashiCorp draws the line in Vault's security model: protecting against flaws in the clients that access Vault is out of scope, and a compromised client operates at that client's privilege. The Vault Secrets Operator threat model goes further and states that no secondary effects after disclosing secret material are considered.
The isolation tools tell the same story from the other side. Docker's logging documentation covers container stdout and stderr, which is output, not actions. Landlock, the Linux kernel's own sandboxing interface, logs denied accesses and is silent about permitted ones. Among the common isolation primitives only gVisor ships a per-action record, and it is off until you turn it on.
None of this is hidden. Each vendor documents what it enforces, and none of them claims to watch what happens once the thing it guards has been handed over.
The question that is left
Store the secret properly, hand it out carefully, confine the process, and one question is still open:
What is this agent doing right now, and should it be?
There is one place that question can be answered: at the tool call, before it runs, where the action and its arguments are both in view. Not at storage, not at issuance, not at the boundary. At the call.
Answer it there and you get things the other layers cannot produce. A decision with context, meaning not "may this process open files" but "may this action, with these arguments, run now." A record, meaning every call, every argument, every verdict, for every agent on the machine. And something to hand over afterwards: when someone asks what the agent touched during the window of an incident, the answer is a log rather than a reconstruction.
That is the layer node9 works at. It is not somewhere to keep secrets, and it does not replace a vault or a sandbox. It sits at a point in the sequence where the other three do not.
Where a broker fits
A broker is the one of the three that overlaps this layer, so it is worth saying how.
A standalone broker can condition a secret on who is asking. A broker sitting at the decision point can condition it on which action has already been judged allowable. Those are different guarantees. The first asks whether this process may hold the key. The second asks whether this particular use of it, right now, is justified.
That is why, for us, brokering belongs at the gate rather than beside it, and why we treat it as an extension of this layer rather than a separate product. A credential released only for an action that has already passed judgment is the closest thing to a credential that was never handed out at all.
The short version
Keep the vault. Keep the broker if you have one. Keep the sandbox for anything you do not trust. Then ask what is watching the agent in the space those three leave open, because that is where the failures are happening now.