Sandboxing
Running a skill you didn't write means running a stranger's code with your permissions. Pound's sandbox shrinks what an active skill can reach, so a malicious or compromised skill can't quietly read your secrets or phone home.
The sandbox is automatic — there's nothing to configure. It switches on the moment you activate a skill and switches off when no skill is active.
How it works
When you run #<skill-name>, Pound records the active skill (its bundle directory and your current project directory). Three PreToolUse hooks — installed once into ~/.claude/settings.json — gate Claude's tools while a skill is active:
| Tool | Policy |
|---|---|
| Bash | Wrapped in a kernel sandbox (nono). Network is blocked; the filesystem is narrowed to the skill's workspace + /tmp (writable) and your project (read-only). |
| Read / Write / Edit / MultiEdit | Path-filtered. Your project and the skill's own files are allowed; credential stores and the rest of your home directory are denied. |
| MCP tools | Pass-through today — see Limits. |
When no skill is active, all three hooks are no-ops, so your normal Claude Code sessions are completely unaffected.
Requirement: install nono
The Bash layer is enforced by nono, a kernel-sandboxing tool (Landlock on Linux, Seatbelt on macOS). Its restrictions are irrevocable once applied — not even nono itself can widen them mid-run.
brew install nono
If nono isn't installed, Pound cannot kernel-sandbox shell commands. It will let them run but print a warning so you're never silently unprotected. Install nono to get the full guarantee — the CLI reminds you on install if it's missing.
What the sandbox protects against
With a skill active and nono installed, these common attacks are cut off:
- Credential theft — reading
~/.ssh,~/.aws,~/.config/gcloud,~/.gnupg,~/.netrc, or anything else in your home directory outside the project. - Data exfiltration over the network — a shell command that reads a secret and
curls it to a server is stopped, because the sandbox blocks network access. - Trashing your machine — a skill can't write outside its own workspace,
/tmp, and your project, so it can't delete your home directory or modify system files.
What the sandbox does not cover
The sandbox limits what a skill can reach. It does not judge what a skill writes, and it is not a defense against prompt injection. Specifically:
- Malicious code in your project. A skill's job is to edit your code, so writes into your current project are allowed by design. Pound cannot tell a legitimate edit from a backdoor, a weakened security check, or a poisoned
package.jsonpostinstall hook. Detecting malicious intent in code is an unsolved problem — so review skill output like a pull request from a stranger before you commit, build, or deploy it. - Non-shell exfiltration paths. Network blocking applies to Bash. Other tools (web fetches, MCP servers) aren't sandboxed yet, and a model can always print a secret it was allowed to read back into the conversation.
- Prompt injection itself. The sandbox contains the blast radius of a tricked agent; it doesn't stop the agent from being tricked.
In short: Pound is a blast-radius control, not a guarantee of safety. It meaningfully raises the cost of the most common smash-and-grab attacks while you still apply normal judgment to what a skill produces.
What's coming
Bundled scripts and MCP servers are next: Pound will launch a skill's MCP servers inside the same kernel sandbox at startup, closing the MCP pass-through gap. See Coming Soon.