Solutions
How does a tool know which agent is asking for a key?
Updated
It asks the operating system, not the caller. When a command asks the Vault for a value, Forkbench resolves which pane it came from using the kernel's audit token. A process claiming to be a different pane is not believed, so a key granted to one Thread — one job's plan, notes and keys — cannot be pulled from another.
Scoping a credential to one piece of work only means something if the scope cannot be talked around. Most tools that hand out secrets locally take the caller's word for who it is — a session id, an environment variable, a name in a config file — and every one of those is a string the caller supplies, which means anything running as you can supply it too. At that point the scope is a filing convention rather than a boundary, and it is worth knowing which one you have.
The audit token is the kernel's own record of which process is on the other end of a connection. It is not something the caller sends, so there is nothing in the request to forge: a script that declares itself a different pane is answered as the pane it actually is. The same resolution governs the notebooks and the board, not only the Vault, which is what makes an agent's whole reach follow from where it is running rather than from what it says about itself. The practical consequence is the one worth carrying: granting a key to a Thread is a real grant. An agent in a different Thread on the same Mac, running as the same user, with the same tools installed, asks and is refused — and the refusal is recorded, so a scope you set is a scope you can later audit.
How it works
- 1Grant each secret to the one Thread whose work needs it. Everything else is denied by default rather than by convention.
- 2Open agents in that Thread as normal. They inherit the grant because of where they are running, with nothing to configure.
- 3Have the agent run the command through the Vault rather than reading a value, so the credential reaches the command and not the transcript.
- 4Check the access log when you want to know what was used, by which Thread, and what was turned away.
Straight about the guarantee: This settles who is asking, which is a different question from what the answer may then be used for. A command you authorise to use a credential is a command that can use it — containment is not the same as restricting authority, and /security sets out where each one stops.