AI in your terminal: where secrets hide in agent workflows

You invited an agent into your terminal. It reads your shell history to “understand your workflow,” checks your git config, greps your project for credentials, and runs commands whose output becomes part of its context. Everything your terminal has ever touched is now something the agent can see — and send to a model API.

Before you can protect secrets, you have to find them. Here is the map of where secrets hide in terminal-centric agent workflows.

Shell history

~/.bash_history and its zsh and fish equivalents record command lines — and command lines contain tokens. curl -H "Authorization: Bearer ...", export AWS_SECRET_ACCESS_KEY=..., docker login -p <password>. An agent that reads history for context has just been handed your credential history. Prefer commands that take secrets from files or the environment instead of argv, and audit history for embedded values.

Environment variables and .env files

Exported variables are the default way to pass secrets to processes, and the agent lives in the same environment. env, printenv, and set -x in any script echo them into tool output. Worse, .env files are the standard project convention — agents routinely read them as “context,” which is exactly wrong. A credential belongs in a password store, not in a file the agent treats as documentation.

Git configuration and remotes

~/.gitconfig can hold credential helpers and tokens, and remote URLs like https://user:token@github.com/... store the token in plain sight. git remote -v prints them, and so does any error message from a failed push. Audit your remotes for embedded credentials and switch to credential helpers or SSH keys.

Credential stores in plain sight

SSH keys, ~/.aws/credentials, ~/.config/gh/hosts.yml, GPG keys, and the token caches of language package managers all live in dotfiles that a helpful agent may read to “understand your environment.” Access to these files is the difference between an agent that can push code and one that can impersonate you. On a shared machine or a CI runner, they are the crown jewels — an agent with read access has effectively been given your identity.

Session logs and tool output

Terminal multiplexers and agent session databases persist output — including output that contained secrets — long after the command finished. Cleaning them up takes more than deleting rows: indexed copies and free pages retain the bytes, so erasure needs a real scrub.

Closing the hiding spots

Order matters. Removing the secret from the environment — history, .env files, remotes — reduces exposure at the source. Restricting what the agent can read shrinks the attack surface. Scrubbing and DLP are the safety nets for what slips through anyway. Most teams start at the last step and skip the first two.

The pattern is consistent: secrets are exposed when the agent can read them, and exfiltration happens when they enter the model request. The fixes are structural. Keep secrets out of command lines and history; store them in a password store; resolve them outside the agent and inject at use time; scrub tool output before it reaches context; and run a DLP layer over outbound model traffic so anything that slips through is masked before it leaves the machine.

That structural layer is what trustless provides: a zero-dependency Go binary that reads your existing pass or Bitwarden store, injects credentials into subprocess and HTTP flows without the agent seeing them, scrubs encoded variants from output, and can retroactively scrub leaked values from session databases. The command reference is in the documentation.

Pick one hiding spot from this list and check your own machine. What did you find?