Skip to content

Security: inaridiy/CF-Open-Agents-API

SECURITY.md

Security policy

Reporting a vulnerability

Do not post exploit details, credentials or tenant data in public issues.

GitHub Private Vulnerability Reporting is enabled: report through Report a vulnerability. The release procedure verifies that this link works before every npm publication.

Include the affected version or commit, configuration, a minimal reproduction, impact, and redacted logs. Allow the maintainer to investigate and coordinate a fix before publishing technical details.

Supported versions

The main branch and the latest 0.x tag are the supported line. Earlier snapshots are not maintained separately. There is no response-time SLA before 1.0.

Security boundaries

Models and workspace code are untrusted. Model credentials stay in the private gateway Worker. Deployment code controls presets, container images, tool registrations and provisioning. The harness container starts without Internet access and reaches only the Worker-side hosts its HarnessDO intercepts; the sandbox container has the network policy the environment configured, and under restricted every HTTP and HTTPS request it sends passes an allow-list in the Worker. Neither container holds bucket credentials: a sandbox reaches R2 only for the one backup object its current backup or restore grants. Service Binding callers are trusted to authenticate users and supply tenant IDs; HTTP callers are authenticated by the deployment's authenticate function.

Operators must configure authentication, resource budgets, permitted tool effects, network access and R2 retention for their deployment. Container isolation does not make external tools safe or undo their effects. A completed checkpoint records native history and files, not transactional completion of external operations.

Sandbox reuse

A session's sandbox is kept alive between turns while it holds the last committed workspace. State outside /workspace, including packages installed and files written by setup commands or by the agent, persists across those turns. It is discarded when the sandbox is restored after a cancel, a failure, a container loss or a fork. Treat everything a setup command or the model writes as visible to every later turn of that session, and do not place secrets in the sandbox: the environment's env variables are passed to every sandbox command by design, while MCP credentials for service-origin servers stay in the Worker, and environment-origin MCP servers cannot use Vault credentials for that reason.

Known limitations

  • Workspace code runs as root in the sandbox and can replace /usr/local/bin/sandbox-shim, the helper @cloudflare/sandbox 1.0 talks to for backups. A replacement can make a backup or restore fail, or make the SandboxDO allocate a large buffer for a frame it announces (the package checks a frame's size only for error frames). The effect stays within that session's own objects; it can fail the session's checkpoints, not reach another session.
  • Under restricted, the sandbox starts without Internet access, so only HTTP and HTTPS through the egress allow-list leave it; redirects are returned to the container and checked again. HTTPS clients must trust the per-container CA through the system bundle or the NODE_EXTRA_CA_CERTS, REQUESTS_CA_BUNDLE and SSL_CERT_FILE variables the sandbox sets; a client that pins its own certificates fails instead of bypassing the policy.

What to report

Tenant isolation failures, credential exposure (model or Vault), a sandbox reaching R2 objects beyond its current backup grant, unauthorized gateway or tool access, checkpoint or artifact path traversal, sandbox or harness container escapes, and any way for workspace content to alter Worker bindings or deployment policy. Bugs in upstream runtimes or Cloudflare components may need coordinated upstream fixes. See deployment and compatibility for the supported configuration and limits.

There aren't any published security advisories