The ssh-agent lesson: why AI agents should use credential brokers

If you use SSH keys, you already know the most important secret-management pattern in software. The ssh-agent daemon holds your private key in memory, and no other process is ever allowed to read it back. When a tool needs to authenticate, it sends the agent a signing request and receives the signature — never the key material. Keys stay in one place, and every other process on the machine, however compromised, cannot extract them. That design decision is why SSH keys survive for years on laptops that run arbitrary code every day.

AI coding agents have quietly reintroduced the problem that pattern solved. They load .env files, read environment variables, and inspect config files, because that is how tools discover credentials. Everything they read lands in the context window, and the context window is sent to a third-party model API as part of every request. Worse, every subprocess the agent spawns inherits its environment, so a diagnostic printenv or a build script that echoes configuration dumps the same secrets a second time. A key that used to live only inside one process now travels through model providers, session transcripts, and logs. The credential is no longer confined to the software that needs it.

The lesson: separate possession from use

ssh-agent works because it separates possession from use. Software can use the key without ever possessing it — the agent performs the cryptographic operation itself and returns only the result. The equivalent for API keys, database passwords, and OAuth tokens is a credential broker. The agent references a secret by name; the broker resolves the actual value at the layer where it is needed: process environment, HTTP header, or request body. The defining property is that plaintext never enters the model’s context window, because the model never sees the value at all.

The broker performs the operations agents cannot do safely

A broker implements the same separation for modern credentials. With trustless run -s <key> -- <cmd>, secrets are injected into the subprocess environment and stdout and stderr are sanitized — including base64 and URL-encoded variants — so even a chatty build script cannot print a key into the transcript. For OAuth, the broker holds the refresh token, rotates it after a single use, and hands the agent only short-lived access credentials. For HTTP tools, a local proxy injects the right header or query parameter per host, and the agent talks to a normal endpoint that never reveals the token.

Objections, addressed

“The agent is my own code” — so is your shell, and ssh-agent still protects your key from it. “The sandbox contains it” — containment limits what the agent can do, not what it can read; a key that enters context still leaves the machine in the next model request. “I rotate keys often” — rotation limits damage after a leak, but it does not prevent the leak itself. The ssh-agent lesson is not about distrusting your tools. It is about minimizing the number of places a secret exists at all.

The ssh-agent for the agent era

A credential broker is that pattern applied to AI agents: one store, names not values, injection at the last responsible layer. trustless is a single static Go binary with zero runtime dependencies and 321 tests under -race, reading your existing pass or Bitwarden store with no migration and no new vault format. The command reference walks through each injection and scrubbing mode.

If your agent can read the key, ask yourself: can you say where that key is right now — and what would ssh-agent have done differently?