Security model

The main controls enforced outside the agent.

Project code runs in a Linux container with restricted capabilities.

The worker uses a restricted Linux capability set and no-new-privileges, preventing executables from gaining additional privileges through setuid or file capabilities. Managed runtime tools are mounted read-only. Root inside the worker does not grant control of the host or the separate proxy network namespace.

A separate rootless Docker daemon runs outside the worker container on its single-use node; it is not shared across customer tasks. The worker receives the API filter socket, which checks operations, container options and mount sources and blocks privileged containers.

A warm node is an unused machine; after its operation it is deleted, never reassigned.

After the operation, the platform revokes runtime authorization, removes containers, stops the separate Docker daemon and schedules node deletion. Residual volumes, build cache, workspace, /tmp and local database files end their lifecycle with node deletion. Cleanup failure does not return the node to the pool.

Reuse applies to versioned AWE images and caches stored for that project. Task isolation relies on disposable nodes, not wiping and reassigning a used machine to another task or customer.

The proxy adds managed authentication to permitted requests.

Managed model and publication tokens remain outside the agent workspace. For supported operations, the proxy obtains authentication from the credential service and inserts the required headers into requests to the configured destination hosts. Authentication can be refreshed there without giving the agent the underlying token.

Before injecting a token, the proxy requires the HTTP host to match the client and upstream TLS names over HTTPS on port 443. It also checks the URL, headers and raw request body for known credentials, including URL-encoded and Base64 representations. Attempts to send them to an unauthorized destination receive HTTP 403. Each redirected request is checked again. This protects known proxy credentials, not arbitrary project data.

Publication uses separate platform credentials, rather than granting the worker direct publishing authority. This separation covers managed credentials; it does not hide secrets already present in source files, issue text or command output.

Worker and nested-container HTTP(S) traffic passes through the proxy.

The network boundary is enforced outside the worker, regardless of the UID running a command. HTTP(S) is intercepted at the proxy; DNS is restricted to configured resolvers, other forwarding is blocked and IPv6 is disabled. Nested Docker containers use the same egress boundary.

The proxy checks the HTTP method and destination. Write methods are restricted to an explicit host allowlist; read requests have broader access for fetching dependencies and context. Data can still travel in URLs or requests to allowed services, so this filtering is not a guarantee against exfiltration.

The worker’s GitHub token is scoped to the task’s repository.

The worker’s GitHub App installation token is restricted to the task’s repository. It does not grant access to other private repositories, even if they belong to the same app installation. Public repositories remain accessible through permitted network requests.

The publication service writes changes only to the task’s target repository. Private dependencies and submodules in other repositories require separate authorization; the worker’s token does not provide it.

A separate service publishes the patch and rejects changes to protected CI paths.

The publisher checks changed paths before writing the result. A patch touching .github/workflows/, .github/actions/, detected local action directories, or action.yml / action.yaml files is rejected in full. The agent is also instructed to refuse tasks requiring CI configuration changes.

CI security analysis reports findings but does not block tasks. Protecting workflow files does not prevent existing builds, tests or install scripts from executing changed application code. The platform opens a pull request for review and leaves the merge decision to you.

OpenAI is currently the only model provider used by Codebase.run.

Codebase.run currently uses OpenAI as its only model provider. Issue content, selected source code and tool results are sent to OpenAI as context for the agent’s work. The OpenAI authentication credential is supplied by the proxy rather than exposed in the agent workspace.

Pull requests and progress messages are published to the target repository. Container isolation does not keep model context local. Data retention and use for training depend on the applicable OpenAI service terms and configuration; this security model does not promise a separate retention or training policy.

These controls reduce the agent’s authority, but the following risks remain.

Data exfiltration: code or tool output can be included in request URLs or sent to allowed services. Network filtering does not inspect every piece of data for confidentiality.

Malicious instructions: an issue, repository file, dependency or external page can steer the agent into unintended actions within its available permissions, including harmful code changes. Separating credentials does not guarantee that the agent will follow the intended task.

Secrets in project content: credentials already present in source files, fixtures or command output can be read by the agent and included in model context or generated output. Proxy credential handling does not sanitize project content.

Execution in CI: existing tests, builds and installation scripts can run changed application code with the CI job’s permissions, potentially accessing secrets or external services. This can happen when a PR opens, before review or merge, even if workflow files remain unchanged.

Incorrect or unsafe changes: passing tests can miss regressions, vulnerabilities and malicious behavior. Review the diff and verification evidence before merging, especially changes to dependencies and executable scripts.