Vercel moves AI SDK HarnessAgent harness out of the sandbox into the host process

Vercel has rearchitected the fx adapter for the AI SDK's HarnessAgent: the agent harness and the model calls it makes now execute in the same process as the application itself, while filesystem and shell operations built into the toolset continue to run only inside the sandbox. According to a changelog post on the Vercel blog dated October 28, the change arrives through a rewrite built on libfx, the TypeScript library behind fx.

What the rewrite removes

Under the earlier design, running a sandboxed agent meant standing up machinery that straddled the host-sandbox boundary. Vercel says the new adapter no longer installs fx within the sandbox, no longer runs a sandbox bridge, and no longer exposes a sandbox port. Instead, the harness sits in the host process and dispatches the risky work, meaning file access and shell commands, into the isolated environment.

One security-relevant consequence is that model credentials remain with the host process instead of being passed into the sandbox. The environment that executes untrusted tool activity therefore no longer holds the keys to the model provider.

New capabilities in the adapter

Alongside the architectural change, Vercel lists several feature additions:

• Built-in tool filtering, which lets developers select which of the bundled tools an agent is permitted to use.
• Mid-turn steering, allowing new instructions to reach the agent while a turn is still running.
• Structured output, for responses that conform to a schema.
• Image tool results, returned to the model through toModelOutput().
• Session persistence, so a session can be saved and later resumed inside a fresh host process.

The session resumption detail is worth pausing on: because the harness now belongs to the host rather than the sandbox, a saved session can be picked up by an entirely new host process, which is the kind of primitive needed for agents that outlive a single deployment or process lifetime.

How to adopt it

The change ships in the @ai-sdk/harness-fx package. Vercel says updating the package to its latest version is what is needed to move onto the new adapter, and the company directs readers to the fx harness documentation for further detail.

Why it matters

Sandboxed agent architectures live or die on where they draw the line between trusted and untrusted code. The previous arrangement needed a bridge and an open port precisely because the harness effectively lived on the far side of the sandbox boundary, and it required provider credentials to be forwarded into that environment. The new design puts only the genuinely dangerous operations, the filesystem and shell tools, behind the isolation wall.

That yields a smaller attack surface and less infrastructure to operate: no fx installation inside the sandbox, no bridge process, no exposed port, and no provider keys within reach of tool execution. The accompanying features point in the same direction. Tool filtering tightens what an agent may do, mid-turn steering and session resumption address control and durability over long-running turns, and structured output and image results widen the range of tasks the harness can express. For developers building agents on the AI SDK, this is a meaningful simplification of the deployment story; for anyone designing sandboxing for agentic systems more broadly, it is a useful reference point for which components belong on which side of the boundary.