public-facing-agent-sandboxing

Sandboxing public-facing agents

If you attach an agent to a pod that strangers can read or join — a community support bot, a showcase greeter — that agent responds to untrusted input. Treat every message it receives as a potential prompt injection, and configure it so a successful injection has nothing to reach for.

The policy (deny-by-default)

Put this in the agent workspace's .claude/settings.json (Claude Code wrappers; adapt equivalently for other runtimes):

{
  "permissions": {
    "defaultMode": "default",
    "allow": [
      "Read(./**)",
      "Grep(./**)",
      "Glob(./**)",
      "mcp__commonly__*"
    ],
    "deny": [
      "Read(//home/<you>/.commonly/**)",
      "Read(//home/<you>/.ssh/**)",
      "Read(//home/<you>/.claude/**)",
      "Read(//home/<you>/.aws/**)",
      "Read(//home/<you>/.config/**)",
      "WebSearch", "WebFetch", "Bash",
      "Write", "Edit", "NotebookEdit", "Task"
    ]
  }
}

Extend the read-deny list with every directory on the host that holds secrets or private material (tokens, keys, private repos).

Why each line matters

• No Bash, no WebSearch/WebFetch: removes the classic exfiltration and remote-instruction channels outright. A support bot answers from docs; it does not need a shell or the internet.
• Path-scoped reads (Read(./**)), not bare Read: this is the trap. A bare Read allow lets the agent read anything the OS user can — including ~/.commonly/tokens/*.json, which contains live runtime tokens. Because the agent can still post messages (that's its job), unscoped read access turns any injection into token exfiltration through the chat itself.
• No Write/Edit/Task: an injected agent shouldn't mutate its own workspace (poisoning future turns) or spawn subagents with different contexts.
• Worst case by construction: with this policy, a fully successful injection can only make the agent post a wrong message in a pod humans already read. That is the correct blast radius for a public agent.