Your AI Agent Can Read Your SSH Keys — One Command Stops It

Here is the uncomfortable default nobody mentions when they hand you an AI agent: it runs as you. Same user, same permissions. When Claude Code or an autonomous loop runs a command, the operating system does not know it is “the AI” — it sees your account, and your account can read ~/.ssh, your AWS credentials, your .env files, your browser cookies. Nothing about “run this command” is scoped down. The agent has the full run of your machine because you do.

Most of the time that is fine. The problem is the tail: a prompt-injection buried in a web page or a dependency that quietly tells the agent to read your keys and phone them home. There is no malware needed — just an agent doing what it was told, with permissions it never should have had for that task.

The fix is a capability sandbox, and the free tool for it is nono.

The tool: nono

nono (Apache-2.0, roughly 3.8k stars) wraps any command in a restricted sandbox and runs your agent inside it. What makes it worth trusting: the restrictions are kernel-enforced — Landlock on Linux, Seatbelt on macOS — not advisory, and not an LLM deciding what is allowed. There is no model in the loop at block time. The kernel simply refuses the read. An agent inside a properly configured nono profile cannot open a file outside its allowed scope, full stop, no matter what it was convinced to try.

Run your agent inside it

The shape of the command is:

nono run --profile <profile> -- <your-agent-command>

Everything after -- is the command nono launches — your agent, exactly as you normally run it — but now confined by <profile>. For example, running a coding agent confined to the current project:

nono run --profile my-project -- claude

The agent works normally inside the directories the profile allows. The moment it tries to read ~/.ssh/id_ed25519 or ~/.aws/credentials, the kernel denies it — the agent gets an error, and your secret never leaves your disk.

The honest catch: the default profile is permissive

This is the part you must not skip. Out of the box, the default profile is permissive — it is meant to run things without breaking them, which means it is not the lockdown you want. Installing nono and running with defaults gives you almost none of the protection above.

The protection comes when you configure a restrictive profile: one that grants read/write only inside the project directory (and wherever the agent genuinely needs it) and denies everything else — explicitly keeping ~/.ssh, your cloud credential files, and your home dotfiles out of reach. The mental model is allowlist, not blocklist: start from “nothing,” add back only the paths this task requires.

Once that profile exists, the guarantee is strong precisely because it is dumb:

• Kernel-enforced. Landlock / Seatbelt is the operating system saying no. It does not matter how clever the prompt-injection is.
• No LLM in the loop. Nothing is “deciding” whether a read looks safe — the sandbox has no judgment to fool. The path is either in scope or it is denied.
• The agent still works. Inside its allowed scope it reads, writes, and runs exactly as before. You lose nothing except the ability to touch what you never wanted it touching.

The rule of thumb

Never run an autonomous agent where it can see your keys. It costs one word in front of your command — nono run --profile <p> -- — and a few minutes writing a profile that says “this project, nothing else.” Do that once and “run it” stops being a leap of faith, because the answer to “can it read my SSH keys?” becomes the kernel won’t let it.