The cage holds where the agent runs. Not what it can take.

Six months ago, coding agents triggered under 3% of everything that shipped on Vercel. This week the company's CEO put the number at more than half, out of six million deployments a day, with over a trillion AI tokens moving through their gateway in the same window. Agents did not creep into production. They took it over, in two quarters.

So Vercel built the runtime for it. Their new Sandbox drops each agent's shell commands and file operations into an isolated VM, in a separate security context from the harness driving it. Every run is logged, every tool call traced, on a principle they state plainly: no trace, no trust. That instinct is right, and the audit half of it is exactly right. If an agent acts and you cannot see what it did, you have nothing.

Now the half a sandbox does not touch. Isolation controls where the agent runs. It says nothing about what the agent can reach. The whole reason you deployed the thing is to do real work, which means you handed it real credentials: an AWS key, a database password, an API token, a deploy secret. Those sit inside the cage with it, because it needs them. So the sandbox stops the agent's shell from escaping to the host, and it does nothing at all when a prompt-injected or hijacked agent picks up the credential it was legitimately given and spends it on exactly what that credential allows. The cage contains the blast. The credential is the payload. You isolated the actor and left it holding the keys.

And agents get hijacked. We watched it this month: an agent conditioned through a game to hand over the SSH keys and tokens sitting in its environment. No exploit, no escape. The agent just did what it was talked into, with what it already held. A sandbox would have logged every second of that and changed none of it.

The fix is not a stronger cage. It is not putting the keys in the cage at all. An agent does not need to hold your credentials. It needs the use of one, for one action, at the moment it acts. Broker it then: scoped to the single resource the task needs, bound to the machine it was issued to, expired on a clock measured in minutes, gone after. Nothing sits at rest in the sandbox for a hijacked agent to grab, because the secret was never stored there. When the agent is turned against you, and half your production is agents now, so assume it will be, what it can reach is one expiring key for one job, not your keyring.

None of that makes a hijacked agent harmless. For the window it holds a live credential, it can misuse that credential for whatever it permits, and no design rewrites that. What changes is the size of the loss. Vercel's sandbox shrinks where a bad agent can run. Scoped, brokered, ephemeral credentials shrink what it can take. You want both, and they solve different halves. The industry is racing to build the runtime. The other half is deciding the agent never holds the keyring, and right now that half is still shipping standing secrets straight into the box.

The winning layer, Vercel argues, is not who has the best model. It is the agent runtime. They are half right. The other half is the credential layer inside it.

We keep a short list of things a credential system should never do. Near the top: a secret should never sit where the code that uses it runs. The list is here.

Clavitor (@clavitorai) is the credential vault built for AI agents, and against them. clavitor.ai

Sources

Vercel (@vercel), via CEO Guillermo Rauch (@rauchg): the eve agent framework and Vercel Sandbox launch, with the disclosed scale, agents now drive more than half of Vercel's deployments and commits, up from under 3% six months ago; 6M deployments a day; 1T+ tokens a day through the AI Gateway. [1]

TechCrunch (@TechCrunch): "Vercel CEO Guillermo Rauch on the fight to split off models from agents," the models-versus-agents decoupling thesis and the enterprise-risk framing. [2]