Why isolation is the feature
As agents get more capable, so does their potential blast radius. An agent that can spin up servers, drive a browser, and rewrite your templates on its own initiative is enormously useful — and running that unsandboxed is a genuinely bad idea. The engineering question isn’t whether to let agents act; it’s how to cap what a bad turn can touch.
Forge’s answer is isolation at every layer that matters.
Prove it in a throwaway environment
Before a change merges, the QA character deploys the full service matrix to an isolated, single-use stack — its own <run-id>--app subdomain — smoke-tests the live endpoints, and then always destroys it. The verdict is based on actually-serving-traffic evidence, not “CI was green.” Because the stack is single-use and swept, leaving one up is impossible by design.
Scoped credentials, not god tokens
Each run executes under a per-invocation JWT root scoped to its (session, turn) — a narrow trust boundary, separated from the encryption key. A run can reach exactly what its manifest allows and no further. Combined with scoped secrets
, a compromised or confused agent simply doesn’t have the reach to do broad damage.
Tenant isolation, audited
Multi-tenant from the ground up: one organization’s workers, sessions, and data are invisible to another’s, enforced at the worker and RBAC layers and audited across every cross-org access path. The isolation isn’t a promise in the docs — it’s checked.
For the deeper story, read Relentlessly proactive agents need relentlessly isolated stacks .