A sandbox is not a tool policy

What is an agent sandbox?

An agent sandbox is an isolated place for the model to run shell, read and write files, and execute generated code. It runs without process.env, without your Node.js, and without a path back into the app. Eve's security model splits the world in two: the app runtime (tools, connections, secrets, durable state) and the sandbox (an isolated /workspace, on Vercel a Sandbox microVM).

The model never holds the Stripe key. A charge_card tool runs in the app runtime, reads process.env, calls Stripe, and returns { ok: true }. The built-in bash and write_file tools live in the app runtime too, and they proxy into the sandbox. Isolation is real. It isn't a policy on charge_card.

What does a sandbox stop?

A sandbox stops the failure mode people picture from "the model wrote a script": reading .env, touching the app file system, installing malware into your Node process, or taking secrets into a generated shell.

It can also stop sandbox exfiltration if you tighten egress. Eve's default sandbox network policy is allow-all. For production, Eve's own checklist says to set deny-all or an allowlist. It also says to use credential brokering, so that a git clone can authenticate without the token entering the sandbox process. That is a network policy on untrusted compute. It is the right control for that compute.

What does a sandbox not stop?

A sandbox doesn't stop a tool or connection that runs on the trusted side. Eve is explicit: authored tools and MCP and OpenAPI connections execute in the app runtime, with unrestricted network and full secrets. "We sandboxed the agent" doesn't apply to sendEmail, createPullRequest, or a Linear MCP that the user mounted.

They are your code, or a spec that you attached, doing exactly what the model asked. The sandbox never sees them. A deny-all sandbox with an open mail connection is a locked workshop and an unlocked loading dock.

This is why the lethal trifecta still applies to a sandboxed agent. Private data, untrusted content, and external communication can all live in the app runtime: the inbox tool, the Slack channel, the send. Isolating bash doesn't strip a leg.

How is this different from channel auth and human approval?

Eve already draws two other lines that people collapse into "security."

Channel auth verifies that Slack or GitHub actually sent the webhook. Eve checks signatures in constant time, and it doesn't trust body-supplied identity. That stops a forged channel. The body is still untrusted content.

Human approval (the AI SDK's needsApproval, or Eve's onAllow: "user-approval") parks a dangerous operation until a person clicks. That is a stop on the external action if the human sees enough context to refuse. Rubber-stamping every tool isn't a policy. See human approval gates.

Neither line decides whether this connection should fire. That decision sits at the action, in the app runtime, immediately before the side effect. AI agent runtime security is that job.

Where does an action gate sit on Eve?

On Eve, the gate isn't a sandbox setting and it isn't a hook. Hooks are observe-only. The Eve documentation page Vercel Eve agent guard is the map of the surfaces that can stop work:

• Inbound screening is the only place a turn can be declined before it starts.
• guardApproval with no authored tools is the gate on OpenAPI/MCP connections that have no local execute.
• Why Eve hooks can't enforce is the reminder that an audit trail isn't a deny.

Keep the sandbox and tighten its egress. Don't ask it to authorize send().