AI agents need access, not keys: the principle behind credential brokers

Software has always been handed secrets the same way: put the key where the process can read it. Export the token, drop a .env file, write the API key into config. That model worked because we trusted the process to use the secret and nothing else. AI coding agents broke that assumption, and they broke it in two directions at once: they read everything on your machine, and they send most of what they read to a third-party model API. Giving an agent a key is no longer giving a process a key. It is putting the key in front of the most exposed software you run.

The principle: access, not keys

The access-not-keys principle restates least privilege for the agent era. A caller does not need to know a secret; it needs to be able to use it. The agent is an untrusted caller with legitimate access needs, so treat it like a contractor. The contractor gets a badge that opens the doors they work in, not the master key to the building. The badge can be scoped, revoked, and audited. The master key cannot.

Applied to agents, the difference is concrete. A credential broker resolves a secret by name at the moment it is needed: the agent says “I need the database URL” and the broker injects the value into the subprocess environment at spawn time. The agent’s context never contained the value. It used the credential; it never held it.

Why holding keys fails

If the key does land in the agent’s hands, three properties of agent architecture amplify the damage. First, context: anything the agent reads becomes model input, and model input goes to a third-party API where you have no retention guarantees. Second, inheritance: every subprocess the agent spawns inherits its environment, so a build script that echoes DATABASE_URL leaks to stdout and into the transcript. Third, persistence: session logs and history files keep the value around long after the task ends, in plaintext. None of this requires malicious intent. It is the ordinary operation of a tool that reads files and runs commands.

How brokers implement the principle

The principle maps onto four layers. At the process layer, trustless run -s <key> -- <cmd> injects secrets into the subprocess environment and sanitizes stdout and stderr, including base64 and URL-encoded variants. At the transport layer, a local proxy injects per-host headers and query parameters, so the agent talks to a proxy rather than to a vault. At the egress layer, a DLP filter masks secret patterns in outbound traffic before they reach the model API. At the storage layer, retroactive scrubbing removes values that already leaked into session databases and logs, with dry-run and backup defaults so cleanup stays reversible.

OAuth tokens follow the same principle. The device flow gives the agent short-lived credentials it can use but not redeem again: single-use refresh-token rotation means a token stolen from context is a token that has already been consumed. The audit log records that access happened — which secret, which event — without ever containing the value.

The shift

Adopting this model changes what you configure. Instead of exporting variables into a shell that an agent will inherit, you wrap the agent invocation so secrets are resolved per run. Instead of trusting the agent to ignore the .env file sitting in the repo, you assume it will read it, and you plan for what happens when it does.

trustless is an implementation of this principle: a single static binary that reads your existing pass or Bitwarden store, so there is no migration and no new vault format. The commands documentation covers each layer in detail.

Your agent will get access to your secrets either way. The only question is whether it ever gets the keys — how are you drawing that line today?