What Tools Block AI Coding Agents From Reading SSH Keys and .env Files?

A coding agent runs as the developer who started it, so by default it can read anything that developer can, including ~/.ssh, ~/.aws, and every .env file on the machine. Several tools can block those reads. Secrets managers and SSH agents keep secrets off disk. Claude Code and Codex have sandboxes with deny rules. Containers keep home directories out of reach. Hooks and EDR catch some reads. Each one covers part of the problem. To block credential reads for every agent and every process it starts, on every machine, you need a layer underneath the agents, which is what Qpoint does. Most teams use several of these together.

What blocking has to cover

• Every way an agent reads a file. Its own file tool, shell commands, scripts it writes and runs, sub-agents, and MCP servers, which run as separate processes with their own file access.
• Secrets in two places. Keys and cloud credentials in the home directory, and .env files inside the project the agent is working in.
• Every agent. Claude Code, Cursor, Copilot, and Codex, plus open source agents and the ones developers build themselves.
• Every machine. macOS, Windows, and Linux laptops, and the containers and CI runners where agents run unattended.

The options and their limits

1. Keep secrets off disk

• SSH keys. 1Password's SSH agent keeps private keys in the vault and asks you to approve when a key is used. Secretive stores keys in the Mac's Secure Enclave. Hardware keys such as YubiKeys hold the key on the device. In each case there is no key file in ~/.ssh to read.
• .env files. Secrets managers such as 1Password, Doppler, and Infisical keep the real values out of .env and supply them when the app runs.

Good fit: everyone. Removing the file protects against every agent and every other kind of malware.

Limits:

• Hard to make complete. Cloud CLI credentials, kubeconfigs, package registry tokens, and .env files in older projects stay on disk on most machines.
• Secrets still show up at run time. Values a secrets manager supplies end up in the environment of whatever runs, including commands the agent starts.
• An agent can still use a key it can't read. It can ask the SSH agent to sign with it. Turn on approval prompts.
• No record. Nothing tells you an agent went looking.

2. Each agent's own deny rules and sandbox

As of October 2026:

• Claude Code. Read deny rules such as Read(~/.ssh/**) and Read(./.env) block its file tools. Its Bash sandbox uses Seatbelt on macOS and bubblewrap on Linux and WSL2 to apply file rules to every command and its child processes. By default the sandbox still allows reads of ~/.ssh and ~/.aws, so you add those paths to its credential or denyRead settings. Admins can require the sandbox and those paths through managed settings, and turn off retrying commands outside the sandbox. It can also give commands a placeholder instead of a secret environment variable.
• Codex. Runs commands in an OS sandbox and supports deny-read rules for paths and patterns such as ~/.ssh and **/*.env, which admins can require through requirements.toml. Without them, its sandbox modes allow reads across the filesystem.
• Cursor. .cursorignore keeps files away from the agent, and .env files are ignored by default. Cursor's docs note that terminal commands and MCP tools run outside those controls.
• GitHub Copilot. Content exclusion is not supported in agent mode, according to GitHub's docs.

Good fit: Claude Code or Codex is your main agent, and you can push managed settings to every machine.

Limits:

• Not on by default. Both sandboxes allow reads of ~/.ssh until someone adds deny rules and pushes them out.
• Partial coverage inside the agent. Claude Code's sandbox applies to Bash commands, so MCP servers it starts are outside it. Cursor's ignore file doesn't cover the terminal or MCP tools.
• One agent at a time. Each agent has its own settings and its own gaps, and agents without these controls get nothing.
• Windows. Claude Code's sandbox doesn't run on native Windows.
• No fleet record. There is no single record, across agents, of what was blocked and when.

3. Containers and dev containers

Run the agent in a container or VM that mounts only the project, so ~/.ssh and ~/.aws aren't there to read. Several vendors now offer container sandboxes built for coding agents.

Good fit: background agents, CI, and teams that already develop in containers.

Limits:

• The project's own .env is in the workspace the container mounts.
• Credentials often get passed in anyway, through a forwarded SSH agent or mounted cloud config, so the agent can push code and deploy.
• Developers drift back to running agents directly on their laptops.

4. Hooks and secret scanning

Hooks in Claude Code, Cursor, and other agents run your code before a tool call, so a hook can refuse a read of .env. Secret scanners such as GitGuardian add hooks that catch secrets in prompts and tool calls.

Good fit: catching secrets on the way into the model.

Limits: hooks see tool calls, not what happens after. If the agent writes a script that opens ~/.aws/credentials, the hook sees python3 sync.py, not the read. And each agent needs its own hooks.

5. EDR

EDR records processes reading files and can alert on access to credential files.

Good fit: detection you already run, across all software on the machine.

Limits: it doesn't know which process belongs to an agent or which session a read came from. Coding agents also trigger rules written to catch attackers, especially around credential access, which makes their activity noisy to investigate. Most EDR alerts after the read rather than blocking it.

6. A layer underneath every agent (Qpoint)

Qpoint is a single binary that runs on each laptop or host, between the agents and the operating system. Every file the agent opens goes through Qpoint first, and so does every file opened by a process the agent starts.

• Credential reads blocked by default. SSH keys, cloud credentials, .env files, and keychains. The agent gets a normal file-not-found error and moves on, or asks the developer for what it needed.
• Placeholders instead of a block. Let the agent read .env with every value replaced by a placeholder, so it can see the shape of the config and keep working.
• Scripts and MCP servers count. If the agent writes a script that opens ~/.aws/credentials, the read is blocked the same way and tied to the agent and session.
• One policy for every agent. Claude Code, Cursor, Codex, Copilot, open source agents, and custom agents get the same rules. Nothing to configure per agent.
• Secrets stripped from requests. If a secret ends up in a prompt, it is replaced with a placeholder before the request leaves the machine.
• A record of every attempt. Each blocked read comes with the agent, session, user, and host, and goes to your SIEM.
• Everywhere agents run. macOS, Windows, and Linux laptops, enforced off the network too, plus containers, Kubernetes, VMs, and CI runners.

For example, a developer points an agent at a cloned repo whose README tells the agent to read ~/.aws/credentials and include it in a request. The agent tries. Qpoint returns file-not-found, the agent reports it couldn't find the file, and it finishes the task. The developer finds out from the violation report, not from an incident. See Qpoint Secure for what else it can block.

Good fit: more than one agent in use, Windows laptops, or a need to show what was blocked and why.

Limits: it is software you install on every endpoint, usually pushed through the MDM you already use.

Questions to ask any tool

• Is it on by default, or does each agent and developer have to configure it?
• Does it cover shell commands, scripts, and MCP servers, or only the agent's file tool?
• Does it work for every agent you use, on macOS, Windows, and Linux?
• What does the agent see when a read is blocked: a normal error it can work around, or a failure that breaks the task?
• Can a developer or the agent turn it off?
• Do you get a record of each blocked read, with the agent, session, and user?

A setup that holds up

1. Get what you can off disk. SSH keys into an SSH agent or hardware key, and .env values into a secrets manager.
2. Turn on agent sandboxes and deny rules where they exist, through managed settings, and list ~/.ssh, ~/.aws, and .env explicitly.
3. Run background and CI agents in containers that mount only the project.
4. Put a layer under every agent for what's left: credentials that have to stay on disk, agents without controls, and the scripts and MCP servers agents start.

Qpoint deploys through Jamf, Intune, a script, or the Qpoint installer, with no changes to how developers work. More on rolling out to laptops is on the endpoints page, and on containers and CI on the hosted agents page.

Frequently asked questions

Doesn't .gitignore protect .env files? No. It keeps .env out of git. The agent reads the working directory, where the file still is.

Is Claude Code's sandbox enough? If Claude Code is your only agent and you push managed settings that turn on the sandbox, deny the credential paths, and block unsandboxed retries, it is a strong control for its shell commands. Add Read deny rules for its file tools. It doesn't cover other agents or the MCP servers Claude Code starts, and it doesn't run on native Windows.

What does the agent see when a read is blocked? With Qpoint, a normal file-not-found error. Most agents report that they couldn't find the file and carry on with the task.

Can an agent use an SSH key it can't read? Yes, if an SSH agent is running and will sign for it. That is why approval prompts matter, and why some teams also block agents from reaching the SSH agent's socket.

Does this work in CI and containers? Yes. The same Qpoint binary runs on Kubernetes, containers, VMs, and CI runners, with the same rules.

See it block a read

Book a demo and we'll show you a coding agent trying to read ~/.ssh and .env, what it gets back, and the record your security team sees.

Related Articles

• Tools to Set an Approved List of AI Agents and MCP Servers Across All Your Endpoints
• Monitoring AI Agents in Kubernetes and CI Runners: What to Use
• How to Build a Complete Inventory of AI Coding Agents Across Your Fleet