Documentation
Plugins & MCP Apps
API Reference
SDK
An execution environment is compiled once per node and recorded. It replaces ambient inheritance from whatever process happened to launch the work.
Architecture contract
ExecutionEnvironmentV1 holds allowed_env_keys, secret_refs, cwd, tmp_scope, filesystem_scope, inherit_process_env and a network_policy_id. Raw process-environment inheritance is forbidden. Secrets are referenced, not embedded.
Why: without a fence, the strength of safety depends on which tool the executor happens to be. With one, the same limits can apply to every executor once enforcement is on for its path.
Current implementation
Resolution and recording are on the active path. On main, every node the work runtime spawns gets a resolved environment (working directory, environment-key allowlist, filesystem scope, network policy), and the resolved document, withinherit_process_env: false, is recorded in the ledger.
Stripping the process environment down to that allowlist depends on the fence profile. By default (decision Q25, “guardrails, not walls”) executors keep real machine access: they are not confined to the worktree, the process env is inherited, and the protection is an always-on blocklist plus a full audit trail. The blocklist denies network calls to cloud-metadata and link-local addresses and reads of private keys and credential stores unless the run declares that need; every allowed, denied or unresolved action is recorded in the ledger. A run can opt into the strict fence (fence: strict on its policy). Under strict, the env is stripped to the allowlist, writes are limited to the worktree and temp, and egress to private addresses is refused. Agency API runs always use the strict fence. ALLTERNIT_EXEC_ENV_ENFORCE=1 also forces env stripping for every work-runtime spawn.
Work-bound executor paths are being converged on the Allternit policy gate; direct interactive runtime behavior may differ from Agency/work-runtime execution.