Solutions

Give an agent push or deploy access without giving it the credential

The agent needs the command to succeed, not the credential to be readable. Give the command the secret and the agent takes the outcome, while the value never enters its context.

The moment an agent stops writing code and starts shipping it, it needs real credentials. Pushing to a private remote, running a deploy, calling a paid API. The usual answer is to export the token in the shell or drop it in a .env, at which point the agent, its logs, its scrollback and its context window can all read the value, and you have traded a working setup for a standing exposure.

In Forkbench the secret lives on your Mac and is granted to one Thread, denied by default everywhere else. When an agent runs a command that needs it the push succeeds, the deploy runs, the API answers, and nothing readable is left in the prompt, the command line or the transcript. Tell it which host the command deploys to and a copy sent anywhere else is refused and recorded rather than delivered. One agent cannot borrow another agent's grant by pretending to be it. You can require Touch ID on every use, which turns a deploy into something that cannot happen while you are away from the machine, or grant a standing window while you work. The practical effect is that authorising an agent to deploy stops being a decision about trust and becomes a decision about scope: which credential, which Thread, for how long.

How it works

  1. 1Store the credential in Vault rather than exporting it or writing it into the project.
  2. 2Grant it to the one Thread whose agents need it. Everything else is denied by default.
  3. 3Have the agent run the command through Vault, for example: forkbench-secret exec DEPLOY_TOKEN -- ./deploy.sh
  4. 4Require Touch ID per use for anything that spends money or reaches production.
  5. 5Prefer a scoped, short-lived credential from the provider over a long-lived one: Vault limits who can read it, not what it can do. Vault is part of Pro.

Straight about the guarantee: This is an ssh-agent-grade guarantee: no accidental exposure during normal use. An agent you authorise to run a deploy can still run that deploy badly, and one authorised for an arbitrary shell command could print what it was handed. Brokering decides who can read the value, not what the command is allowed to do.