Vercel eve: Sandboxing and Approvals for AI Agents

Vercel released eve as an open-source framework for building AI agents that carry out real actions on real systems: writing code, calling APIs, modifying databases, deploying services. What sets it apart from a generic agent SDK is that it solves, out of the box, two problems almost no internal team solves well on its own: where the agent runs when it executes something (sandboxing), and who decides whether an action actually gets executed (approvals). Most of the AI automations we've audited in Spanish SMEs have neither: the agent runs with the same credentials as a senior developer and executes whatever it decides without anyone reviewing it first. That works fine 95% of the time, until the agent misreads an ambiguous instruction and drops a table, sends hundreds of test emails to real customers, or pushes straight to production. You don't need to adopt eve literally for this to be useful — what's worth copying is the pattern, not the tool.

Sandboxing isolates the agent's execution environment — typically an ephemeral container or microVM destroyed once the task finishes — so a code bug, an infinite loop, or a privilege-escalation attempt never touches the host system or other processes. It's the same logic we've applied for years in pentesting with disposable environments: if something goes wrong, you throw away the environment and nothing bad has happened. The problem is that isolation protects nothing outside the process itself: if the agent holds a CRM API key, a Slack token, or access to a payment gateway, it can cause real, entirely legitimate damage from inside a perfectly sealed sandbox. The container can be flawlessly isolated and the agent can still overcharge a customer, wipe an entire Slack channel, or blast an email campaign to the whole database. That's where the second piece — approval — comes in: it doesn't protect the operating system, it controls the business-side consequences.

What an 'approval' actually means in these frameworks

A well-designed approval isn't a generic 'are you sure?' pop-up: it's a synchronous interrupt point that pauses the agent's execution right before an action classified as irreversible or high-impact, displays the exact payload about to run, and waits for explicit human confirmation before continuing. The technical key is that the classification of which actions require approval is not decided by the agent at runtime — that would be letting the fox decide whether it enters the henhouse — but by a fixed policy set by whoever deploys the system. Reading data, drafting a document, or querying an API needs no approval; deleting records, sending external communications, or modifying production config does. That decision trail is also audited: who approved what action, when, and on what basis — something that has helped us demonstrate effective human control over automated data processing in more than one GDPR audit.

Across the 12 AI-agent automation projects we deployed for Catalan SMEs in the first half of 2026, 9 of them had no defined list of which actions required human approval before we started working together — they simply hadn't thought about it, because the agent 'only did small things for now.' The pattern repeats: it starts with an agent drafting documents or classifying tickets, works well, gets handed more permissions without anyone reviewing the earlier ones, and within months has write access to systems nobody remembers formally authorizing. You don't need Vercel's framework to fix this. At minimum you need to separate the agent's credentials from human credentials with role-scoped permissions, define in writing which action types require a human OK before executing, and log that approval somewhere other than a Slack thread that scrolls out of view in two weeks.

• Audit which credentials each active agent uses and whether they exceed what's actually needed
• Classify agent actions in writing as 'automatic', 'requires approval', or 'forbidden'
• Run the agent in an isolated environment (container, sandbox, or separate service account) apart from the rest of the infrastructure
• Log every human approval with who, when, and why — not in an ephemeral chat
• Review granted permissions quarterly to confirm they're still needed

Where this infrastructure isn't worth building

Here's the part not every AI services provider says out loud: if your internal automation is three workflows that read data and generate a PDF report, building dedicated sandboxing and an audited approval system is over-engineering that costs more to maintain than it saves. Agent governance matters when the agent can write, delete, or communicate externally — not when it only reads and summarizes. We ourselves, on several projects, have advised the client NOT to add that layer yet and to wait until the agent moves from 'reads and suggests' to 'executes directly', because building control infrastructure before you need it tends to be obsolete or miscalibrated by the time it's actually required. The right question isn't 'do we have sandboxing and approvals?' but 'what can our agent do today that a human couldn't undo in five minutes?'

Most AI agent incidents we've seen didn't come from the AI 'going rogue' — they came from permissions nobody reviewed since the day they were granted.

• The agent holds credentials with write access to production, not just read access
• The agent can communicate with customers or third parties without prior review (email, WhatsApp, tickets)
• The agent handles personal or financial data subject to GDPR
• No one on the team can say, without checking the code, what actions the agent can execute unsupervised