Isolation

Isolation has two parts: containing the agent that carries out a run, and keeping one organization's data apart from another's.

The run container¶

Each run executes in its own container, created for that run and named after its engagement. The container has a memory limit of 4 GiB.

The container runs as an unprivileged user, with Linux capabilities dropped and limits on CPU, memory and the number of processes.

The agent holds no long-lived platform credentials.

Rules of engagement describes the rules a run is given and the ceilings enforced inside its container.

The scope guard¶

Inside the container, the scope guard checks each command and each URL the agent issues against the engagement's scope before it is executed. A command or request the guard refuses is not executed; the refusal is returned to the agent as the result of its tool call.

How the guard matches targets against the in-scope and out-of-scope lists, and where its checks stop, is set out in Rules of engagement and Scope.

Organization scoping¶

Each authenticated console and partner API request is resolved to one organization. The routes that read or change engagements, findings, reports, lockers, share links, assets, schedules, signing keys and webhooks act only on resources that belong to that organization. Authorization describes the credentials, the check, and the response a caller receives for another organization's resource.