| Version | Supported |
|---|---|
| 0.x | Yes |
Only the latest release on the current major version line receives security updates.
Do not open a public issue for security vulnerabilities.
Please report vulnerabilities privately through GitHub Security Advisories.
- Go to the Security Advisories page
- Click "New draft security advisory"
- Describe the vulnerability and include steps to reproduce it when possible
- Acknowledgment: Within 48 hours of your report
- Initial assessment: Within 7 days
- Fix or mitigation: Within 30 days for confirmed vulnerabilities
We will keep you informed of progress throughout the process.
Warren serves one operator or trusted team per deployment. The deployment, not an individual user account, is the trust boundary.
- Shared operator token.
WARREN_AUTH=token, the default, protects operator routes with one bearer token. The token has no expiry, scopes, or independent revocation. Rotate it by changing the deployment secret and restarting warren. Loss of the token grants operator access. - Optional public-read mode.
WARREN_AUTH=publicadmits unauthenticated spectators to an allowlisted, redacted projection. Mutations and operator-only fields still require the bearer token. A malformed supplied token returns 401 rather than falling back to spectator access. Only use this mode when every registered repository and exposed prompt is safe to publish. - No named users or per-user RBAC. Warren does not attribute operator actions to distinct people. A team that shares an instance also shares its deployment trust boundary. Put an identity-aware proxy in front when the deployment needs external access control.
- TLS stays at the edge. Warren serves HTTP. A reverse proxy or cluster ingress must provide TLS before exposing it outside a trusted network.
warren doctorwarns about unsafe non-loopback deployments. - Secrets follow the deployment boundary. A single-box install commonly reads secrets from
.env. Protect that file with host permissions. Kubernetes deployments should use cluster or cloud secret management. Run pods and containers do not receive the database credential. - Run sandboxes do not receive the operator token. Warren mints a run-scoped callback token for each live run. It reaches only that run's inbox, finalize, and salvage routes today, and the server rejects it after the run becomes terminal. The missing App-mode K8s credential-remint callback permission is tracked by
warren-5a5c.
Warren owns its sandbox and runtime implementations. It has no Burrow daemon, socket, or package dependency.
local. Warren creates a fresh worktree and runs the harness underbwrapon Linux orsandbox-execon macOS. The Linux container topology requires the security settings indocker-compose.ymlso nested user namespaces can start.docker. Each run uses a sibling container. The warren service mounts the Docker socket, which grants control of the Docker daemon. Treat the control-plane container as trusted operator infrastructure and never expose that socket to an agent container.k8s. Each run uses a pod as its isolation boundary. Kubernetes RBAC separates control-plane access from run-pod permissions. Resource and admission limits reduce the effect of runaway workloads, but operators still own cluster policy and secret configuration.
Isolation limits damage from an agent process. It does not make untrusted repository code safe to run with unrestricted credentials or network access. Review the selected runtime capabilities and project-specific agent image before dispatching against untrusted code.
GitHub access sits behind the Forge seam.
WARREN_FORGE=githubuses a static PAT fromGITHUB_TOKEN.WARREN_FORGE=appuses a GitHub App and mints short-lived installation tokens for forge and Git operations.
The control plane supplies Git credentials for clone, fetch, push, and pull-request operations. Configure the narrowest repository access that the deployment needs. Agent commit attribution is separate: set WARREN_GIT_AUTHOR_NAME and WARREN_GIT_AUTHOR_EMAIL to a dedicated machine-account identity.
The UI stores the operator bearer in the warren origin and does not provide separate CSRF protection. Strict CORS and the single-deployment-token model are part of this posture. Do not serve untrusted content on the UI origin.
Preview environments run repository code and therefore use a separate browser origin on supported TCP deployments.
- Path mode is the default. Warren serves previews from a dedicated listener on
WARREN_PREVIEW_PORT, normally the API port plus one. The main UI origin redirects/p/<run-id>/to that listener. Publish and proxy the second port. - Subdomain mode is opt-in.
WARREN_PREVIEW_MODE=subdomainrequiresWARREN_PREVIEW_HOST, wildcard DNS, and a wildcard TLS certificate. - Unix-socket exception. A unix-only deployment cannot create the dedicated TCP listener and retains legacy same-origin path behavior. Warren warns at boot. Use subdomain mode when previews can run untrusted code.
The preview proxy strips Authorization and Cookie before forwarding a request to the preview application. Signed preview cookies authorize browser access to a specific run and mode.
Core warren persists run state and structured events. Those records can contain prompts, tool inputs, file paths, costs, and repository metadata. Restrict database, backup, log, and API access accordingly. Public-read mode serves a narrower projection, not the operator record.
The append-only audit log and automated judge are optional, out-of-process extensions. A base installation does not launch them. Each extension owns its storage, credential, retention, and deployment security. Installing the judge can send run material to its configured model provider.
If you find a vulnerability outside this documented posture, report it through the process above and we will triage it.