Your coding agent can read your SSH keys. Here is how to fence it in

When a coding agent runs ls, cat or npm install on your laptop, it runs them as you. Not as a guest, not as a limited service account: as your user, with your home folder, your SSH keys, every .env file in every project you have ever cloned, and whatever git and cloud credentials are sitting in your config. That is the part people skip when they wire an agent into a terminal, and it is the reason GitHub's news on 2026-10-07 matters more than its size: local sandboxing for Copilot is now generally available.

The risk is the text the agent reads, not the agent

This part is general, not specific to any product. An agent decides what to run from what it reads, and it reads a lot that you did not write: a README in a repository you just cloned, an issue someone opened, a web page it fetched, a comment inside a dependency. If any of that text tells it to print a file or send something somewhere, the agent may follow it, because to the agent the instruction looks like part of the job. That is prompt injection. You cannot review every line an agent reads, so the useful question is not "will it be tricked" but "what can it reach when it is".

What GitHub's sandbox restricts

According to GitHub, the sandbox is available in Copilot CLI, the Copilot app and VS Code sessions that use Agent Host, at no extra cost on top of Copilot. Tools and commands that Copilot starts run with restricted access to the filesystem, the network, credentials and other system capabilities, following policies set by the developer or the organisation. GitHub lists what you can control: which files and folders those commands can read or change; access to the internet, the local network, Git credentials and GitHub CLI credentials; and sandboxing for local tools such as local MCP servers and language servers, where supported. Enterprises can require the sandbox and lock policies so a developer cannot weaken them.

Under it is what GitHub calls Microsoft eXecution Container (MXC), which turns one sandbox policy into the native controls of Windows, macOS and Linux. GitHub also makes a point I agree with: the model and the tool sandbox are separate concerns, so the policy applies to what gets executed whichever model is driving.

Layers you can copy for any agent

Whatever agent you use, these are general habits, not settings from GitHub's announcement, and each one closes a different door:

• Project folder only. The agent reads and writes inside the repository it is working on, nothing above it.
• No ambient credentials. Do not let it inherit your personal tokens. If it needs access, give it a short-lived token scoped to that one job.
• A network allow-list. Package registries and the APIs the task needs, not the whole internet.
• A human approves anything destructive. Deleting, force-pushing, dropping a table.
• Untrusted repositories go in a container or a VM, never straight onto the machine that holds your keys.
• Read the diff before it leaves your machine, and never hand an agent production credentials.

The next step takes ten minutes: open a terminal the way your agent does and list what that user can read, starting with ~/.ssh, your cloud config folder and the .env files across your projects. Everything on that list is in the agent's reach today. If you use Copilot, turn the sandbox on and start with the filesystem and credentials rules; if you use another agent, build the same fence with a dev container and a scoped token. Source: GitHub changelog, local sandboxing for GitHub Copilot.