Coding agents and your SSH keys

Coding agents are among the most useful AI tools available to developers right now. Point one at a repository, describe a change, and it will read the code, run the tests, edit files and often open a pull request. To do that, it needs real access to your machine. The uncomfortable part is that "real access" usually means the same access you have, and on a developer laptop that includes some of the most sensitive files you own.

Agents run as you

When you start a command-line agent from your terminal, or enable an agent mode in your editor, the operating system treats it like any other program you launched. It inherits your user account, your environment variables and your working directory. Every child process it starts, whether a shell, a test runner or a package manager, inherits the same.

That means that unless the tool deliberately restricts itself, or you run it inside something that restricts it, it can read anything your account can read. On a typical developer machine that list includes:

• ~/.ssh/: private keys such as id_ed25519 or id_rsa, plus known_hosts and config, which together describe which servers you can reach.
• Cloud CLI credentials, for example ~/.aws/credentials, the gcloud configuration directory or an Azure profile.
• ~/.gitconfig and Git credential helpers, along with tokens for your code host.
• .env files in projects, which often hold database URLs and API keys.
• Package registry tokens in files such as ~/.npmrc or ~/.pypirc.
• Shell history, which sometimes contains secrets typed on the command line.

Even if the key files themselves are never read, a running ssh-agent lets any process started by you use your loaded keys to authenticate. An agent that can run git push or ssh can use those keys without ever seeing them.

Why this is not paranoia

None of this means coding agents are trying to steal keys. Mainstream tools are built by teams who take this seriously, and many have permission prompts, allow-lists and sandboxing modes. The risk comes from three more ordinary directions.

Context that is too broad

To be helpful, agents gather context. If a task leads the agent to read a configuration directory, or it greps the home folder for a setting, the contents of a credential file can end up in a prompt sent to a model provider. That is a leak even if nobody misuses it.

Prompt injection from the code you work on

Agents read text written by others: README files, issue descriptions, comments, dependency documentation. A carefully written instruction hidden in that text can try to persuade the agent to run a command or send data somewhere. Defences exist and keep improving, but the safest assumption is that any content an agent reads might be adversarial.

Extensions and tool servers

Agents become more capable through plugins and tool servers, such as the Model Context Protocol servers that give them access to databases, browsers or ticketing systems. Each is additional code running with your permissions. A compromised or careless one sees everything the agent sees.

Practical ways to narrow the reach

You do not have to choose between using agents and protecting your keys. A few habits go a long way.

Use the tool’s own guardrails

Most coding agents offer some combination of approval prompts for commands, a list of allowed and denied commands, and restrictions to the project directory. Leave approvals on for anything that touches the network, the shell or files outside the repository, at least until you trust the workflow. Read what the "auto" or "yolo" modes actually allow before enabling them.

Protect private keys with a passphrase, or move them to hardware

A passphrase-protected key is useless to anything that copies the file. Hardware-backed keys, such as FIDO2 security keys supported by modern OpenSSH (the ed25519-sk key type) or keys held in a platform secure enclave, cannot be copied at all and usually require a physical touch to use.

Be deliberate about ssh-agent

Keys loaded into ssh-agent are usable by any process you start. Consider loading keys only when you need them, using a lifetime with ssh-add -t, or enabling confirmation with ssh-add -c so each use requires approval. Avoid agent forwarding to machines you do not fully trust.

Give agents their own, smaller credentials

Instead of letting an agent push with your personal account, create a fine-grained token scoped to one repository with the minimum permissions it needs. Do the same for cloud access: a separate profile or role with read-only or narrowly scoped rights. If something leaks, you revoke one small credential instead of rotating everything.

Keep secrets out of the working tree

Move secrets from .env files into a secrets manager or the system keychain where practical, and make sure your agent’s ignore rules exclude any that remain. Agents that respect .gitignore or their own ignore file will skip what you list there.

Isolate when the stakes are high

For unfamiliar repositories or long unattended runs, use a container, a development VM or a separate user account. The agent then sees only what you mount into it. This is the single most effective control, and also the one with the most friction, so save it for the cases that warrant it.

Watching what actually happens

Guardrails reduce risk; visibility tells you whether they are working. The behaviours worth noticing are specific: an AI-connected process starting a shell, a process opening files under ~/.ssh or cloud credential folders, and large uploads to an AI service shortly afterwards.

GreyArm flags those patterns directly. When an agent that is connected to an AI service spawns a shell, you see it. When it touches credential material, that is raised as a higher-severity finding. If it then sends an unusually large amount of data to an AI endpoint, that is called out too, with the process, the host and the volume. You can approve the agent if it was expected, or contain it if it was not.

Checklist

• Keep command approvals on for shell, network and out-of-project file access.
• Passphrase or hardware-back your SSH keys; limit how long they stay loaded.
• Give agents scoped tokens instead of your personal credentials.
• Keep secrets out of project folders, or out of the agent’s view.
• Isolate unfamiliar or long-running jobs.
• Watch for shells, credential access and big uploads from AI-connected processes.