Isolation
What separates your agent's code from your secrets, and from everyone else's runs.
The sandbox holds no provider key
The most common way an agent leaks a key is that the key was in its environment. opsen injects a session token instead: scoped to one session, capped by that session's budget, dead when the session ends, and useless anywhere else.
A leaked session token buys an attacker whatever budget remains on one run. A leaked provider key buys them your account.
Nothing else from the host
The sandbox receives an allowlist of ordinary variables —
PATH, HOME, LANG and the like —
and nothing more. Secrets belonging to the opsen deployment itself are
not reachable from customer code.
Isolation depends on the runtime
| runtime | boundary |
|---|---|
| e2b | Firecracker microVM |
| modal | gVisor |
| local | a process on the opsen host — development only |
local is not isolation. It exists so you can
develop without a runtime account, and a production deployment that
leaves it set is running customer code in its own container.
Egress
Outbound requests can be restricted per session, and lent credentials are only attached for the hosts they name. See Egress control.