The Extension Sandbox

A permission model an extension must declare, not assume

An agent-authored extension runs with least-privilege permissions it must explicitly declare — network access, listener emission, database access are each opted into, not granted by default. The default sandbox is Node's own node:vm; isolated-vm or opt-in Docker isolation harden it further for a deployment that wants a stronger boundary than the default. Code mode's own execution VM adds no ambient globals, a hard call cap, and a wall-clock timeout — explicitly framed as a capability governor for a trusted operator agent, not a hard security boundary against a genuinely adversarial one.

A concurrency ceiling exists specifically against a fork-bomb via prompt injection

A process-global cap bounds how many sandboxed extension executions can run concurrently at once. The threat model behind it is concrete: a prompt-injected agent looping extension.test or an invoke call could otherwise exhaust host memory, CPU, or process slots — a fork-bomb reached through the sandbox rather than around it. Built-in extensions are trusted, carry their own budgets, and are deliberately not gated by this cap; it exists specifically for the sandboxed, untrusted-code path. Cancellation is real, not cosmetic: aborting a running extension disposes its isolate outright and resolves honestly as EXTENSION_ABORTED, rather than leaving an orphaned process consuming resources in the background.

Continue