Pillar · Sandboxed Agents

Approval Is Not Confinement.

A coding agent that runs unattended needs a boundary that does not depend on someone watching. Anvaya enforces a declarative read/write/exec/network policy across every tool, and keeps --yolo from widening it.

Direct answer

A sandboxed coding agent constrains what an autonomous agent can read, write, execute and reach, independently of whether a human approves each action. Anvaya enforces one declarative policy across its whole tool surface: three profiles (project, computer, strict), sanitized child environments that strip API keys, and a single shell check shared by all execution paths. The critical property is orthogonality, --yolo auto-approves tool calls but never widens confinement, so an out-of-scope command is refused even when nobody is watching. Kernel enforcement uses macOS Seatbelt and Linux Landlock where available, reports refusals explicitly on unsupported platforms, and stays opt-in until the default allow-list passes a build fixture. The active policy is published in the system prompt, and refusals name the missing capability rather than degrading silently.

Mechanisms

Eight Boundaries, Shipped.

Policy at the tool layer is the default; kernel enforcement is an opt-in upgrade with an honest refusal path.

01One policy: every toolA single declarative policy governs reads, writes, execution, network and environment across the whole tool surface, file tools resolve paths through it, and every execution path (run_command, run_script, monitor) shares one shell check. There is no side door for a tool that forgets to ask.

02Three profilesproject: read and write inside the project, the default for a normal repo. computer: read your home directory and work root, write only to the work root, state and temp. strict: network denied, shell refused until a kernel backend is active.

03Approval and confinement are orthogonalAuto-approval is not a permission escalation. --yolo skips the prompt but does not widen the sandbox: a command that violates policy is still refused, and the refusal is reported rather than silently retried.

04Environment sanitized by defaultChild processes inherit a sanitized environment: API keys, tokens and secrets are stripped before exec. Explicit passthrough is opt-in per variable, so a curious command cannot read the agent's provider key from its own process.

05Kernel backends where availablemacOS uses the system Seatbelt sandbox; Linux uses Landlock, gated by kernel ABI so older kernels get fewer guarantees, not silent ones. Windows reports an explicit refusal instead of running unconfined.

06Fail-closed capability reportingWhen a policy demands enforcement the OS cannot provide, the action is refused with the missing capability named, never downgraded quietly. Kernel enforcement itself is opt-in until the default allow-list passes a build fixture, so tool-layer policy is the shipped default.

07Backups before mutationFile tools take timestamped backups before destructive edits, independent of the sandbox. Sandboxing limits what is possible; backups limit what is costly.

08Published in the system promptThe active policy is written into the system prompt, so the model knows its own boundaries instead of discovering them through failures, fewer wasted rounds and fewer refusals to explain.

Three Lines Of Defense

Prompt, Policy, Kernel.

Each layer answers a different question, none of them is sufficient alone.

QuestionApproval promptTool-layer policyKernel enforcement

What it decidesAttempt this action?Is this action in scope?Can this process do it at all?

Who can bypassHuman presses yesPolicy configNothing inside the process

Under --yoloSkippedStill enforcedStill enforced

CoversAll tool callsReads, writes, exec, network, envOS-level process confinement

Failure modeRubber-stampingRefusal with reasonMissing capability, named

Questions

Asked About Confinement.

Is --yolo mode safe to use?

It is a decision about attention, not confinement. --yolo auto-approves tool calls, so you stop reviewing each one, but the same sandbox policy still blocks out-of-scope reads, writes, exec and network. Use it where revert is cheap (clean git trees, narrow scopes, tests gating merges), never as a way to unlock capability.

What is a sandbox profile?

A named policy preset: project keeps the agent inside the repository, computer lets it read your home directory while writing only to the work area, and strict refuses shell execution and network until kernel enforcement is available. Profiles decide what is possible; approvals decide what is attempted.

Does the sandbox slow the agent down?

Tool-layer checks are path and argument evaluation with no I/O, so the overhead is negligible next to model latency. Kernel enforcement adds process-level restrictions (Seatbelt, Landlock) applied at spawn time, not per syscall from the agent.

Which platforms are enforced?

macOS Seatbelt is live-verified: home-directory escapes denied, in-project writes allowed, network denial confirmed. Linux Landlock is compile-verified and ABI-gated, with runtime verification pending broader Linux testing. Windows has a refusal path, unsupported rather than unconfined.

Can I see what the policy is doing?

Yes. The active policy is printed in the system prompt, refusals name the missing or violated capability, and session logs record every tool call and decision. The sandbox is a policy you can read, not a black box.

Run Agents That Fit On Your Laptop.

25.6 MB median RSS. 25 agents ran in parallel on a Core 2 Duo with 4 GB RAM. Hundreds on your machine. Zero cloud required on the Ollama path.

Get Started →Read the FAQ

Requires Rust/cargo to build from source. Linux and macOS today, Windows not yet supported. Pre-1.0, public beta. Pricing TBD.