Solutions
Give someone a key they can use but not read
Updated
Check the secret into the Thread that person is working in and invite them. The commands that need the value get it when they run. The value itself never lands in their prompt, their command line or their transcript.
A teammate, a contractor, a client's engineer needs to run something that requires your credential: a deploy, a paid API, a database migration. The usual move is to send the value itself, paste it into a chat, drop it in a .env, read it out on a call. From that moment it exists in their shell history and their chat log, and it does not come back. Rotating it afterward is the only thing that actually undoes that, not asking them to delete the message.
A secret checked into a Thread stays live there, not a one-time copy handed over and then stale. Change the value in your Vault and every Thread carrying it re-seals with the new one, so whoever is working that Thread keeps working without you resending anything. Remove them from the Thread and its key rotates: what they already read while they had access is gone with the old key, and what is left behind is unreadable to them from that point on. And this governs what Forkbench holds, not the machine the command runs on. A person working in a terminal has whatever access to the filesystem their own account already has, so the boundary here is the credential's value, not what a command could otherwise do once it has succeeded.
How it works
- 1Store the credential in Vault instead of pasting it anywhere.
- 2Check it into the Thread the job lives in. It's granted to that Thread and denied everywhere else.
- 3Invite the person to that Thread. Being invited costs nothing, participating in a shared board is free.
- 4They run the command that needs the credential. Vault hands the value to that command, not to them.
- 5When the job ends, remove them. That Thread's key rotates and re-seals, so the secret is unreadable to them from then on.
Straight about the guarantee: Changing the secret's value re-seals every Thread carrying it, which is what makes rotation mean something instead of a note to update everywhere by hand. This still only governs what Forkbench holds: a person's own account and shell keep whatever access they already had outside of it, so scope the credential itself, a deploy token good for one host rather than one good for everything, instead of relying on this alone.
Related: Everything else an invited person can and can't see, How Vault knows which Thread is asking