Tool SandboxEvery tool execution. Isolated and scoped.
Brokered Tool Execution
Every tool call gets an ephemeral micro tool sandbox, scoped to only the files, network routes, arguments, and credentials it needs. Every decision is auditable.
How nono's tool sandbox works: a coding agent runs a tool invocation, for example gh issue view. The nono supervisor resolves and verifies the executable, evaluates argv policy for the caller and arguments, and on approval creates a fresh, invocation-scoped micro sandbox around the tool with only its selected capabilities: read-only workspace, no filesystem writes, no host secrets, bounded stdout and stderr, and network access only through the nono proxy. The sandbox receives a phantom GH_TOKEN; the real credential stays with the supervisor and never enters the child. The proxy validates the phantom token, evaluates HTTP method and path policy, injects the real credential at the boundary, and forwards over TLS to api.github.com. If an action falls outside the provided policy, the policy engine can route it to a human approval decision to approve, deny, or time out. Security-relevant events are hash-chained into an audit record sealed with a SHA-256 Merkle root, and the sandbox is destroyed when the invocation exits. Four scenarios: Allowed read — gh issue view runs, POST /graphql is allowed by the proxy, and output returns to the coding agent. Human approval — gh pr merge matches no argv rule, so the exact invocation pauses for a human decision and, once approved, executes inside a scoped sandbox. Argv denied — gh issue comment is refused at argv authorization; no sandbox or outbound request is ever created. L7 denied — gh api passes the broad argv rule, but the POST to the repository comments endpoint is denied at the proxy; nothing reaches GitHub.
The agent never talks directly to the isolated tool. Requests, credentials, network traffic, stdio, and audit events cross the supervisor boundary.