Please do not open a public issue or pull request for security reports.

Email security@orcs.to with:

• A description of the vulnerability
• Steps to reproduce (or a proof of concept)
• The affected component(s) — package name, version, commit SHA if possible
• Your assessment of the impact

We will acknowledge receipt within 3 business days and aim to provide an initial assessment within 10 business days. Coordinated disclosure timelines are negotiated per-report; we default to 90 days from initial report to public disclosure, shorter if the issue is being actively exploited.

If you would prefer encrypted communication, request our PGP key in the first message.

orcs is pre-1.0. We support security fixes for the most recent minor release on the default branch. Patches are published to npm under the affected @orcs-to/* packages and tagged with a GitHub Security Advisory.

Once we cut 1.0, the support window will expand and be documented here.

In scope:

• All packages under @orcs-to/* published to npm
• The @orcs-to/orcs CLI and the Docker Compose stack it generates
• The apps/api, apps/web, apps/worker deployable surfaces in this repo
• Reference adapter implementations under packages/adapters/*

Out of scope:

• Third-party services orcs talks to (Temporal, Postgres, MinIO, OpenRouter, GitHub, Anthropic, OpenAI, etc.) — report those upstream
• The hosted SaaS (when it launches; report through its own disclosure channel)
• Vulnerabilities that require physical access to the host running orcs
• Denial-of-service through unbounded resource consumption when the operator has not configured the documented Mission budget / Sandbox TTL controls

orcs is an agent control plane. We treat the OWASP LLM Top 10 and the OWASP Agent Cheat Sheet risk classes as first-class architectural concerns, not afterthoughts. The mitigations below are baked into the tech-stack.md decisions and the sacred interfaces; reports against these surfaces are especially welcome.

• Mitigation: every agent run executes inside a Sandbox with a constrained ToolProvider surface. Tools have a declared risk class; tools above an org's risk threshold trigger a Checkpoint that requires human approval before invocation. The Receipt records every tool call with its arguments and provenance.
• Boundary: orcs is not in the business of preventing the model from saying anything in particular. We are in the business of preventing the model's output from causing irreversible side effects without an audit trail and a human approval gate.

• Mitigation: every Mission ships with explicit budget, deadline, risk class, and approval policy. The policy engine is the gatekeeper for tool invocation, network egress, and write-scope. Default approval policy is deny-by-default for write-class tools — operators opt specific tools in.

• Mitigation: outputs flow into the Receipt (append-only, schema-validated). Tool inputs are Zod-validated at the ToolProvider boundary. Adapters that wrap unsafe shells (filesystem writes, network calls, code execution) must declare their risk class accurately; misdeclaration is a security bug.

• Mitigation: SandboxProvider is the egress boundary. The OSS DockerSandboxProvider defaults to a deny-all egress network policy; the operator opts in to specific egress allow-lists per orc.

• Mitigation: mission state is scoped per MissionRun by default. Cross-mission memory is opt-in via an explicit Skill with a declared memory scope, persisted through the StorageProvider interface, and visible in every Receipt that reads from or writes to it.

• Mitigation: orcs is multi-tenant from day one. Postgres Row-Level Security policies enforce tenancy at the database layer (not just the application layer). The AuthProvider interface centralizes session, org, and membership resolution. Service-to-service calls within the stack carry signed, scoped tokens — never raw operator credentials.

• Mitigation: Dependabot is configured for npm + GitHub Actions. The release flow uses Changesets and Conventional Commits, with provenance attestations enabled when published to npm. Upstream pinning is enforced by the pnpm-lock.yaml.

We do not claim orcs makes prompt injection impossible. It cannot. What it can do is ensure that every agent action is observable, attributable, budget-bounded, and reversible — the same guarantees you'd expect from a CI pipeline running untrusted code, applied to non-deterministic agent work. If you find a way to make an agent action unobservable, unattributable, unbounded, or irreversible, that is the kind of report we want.

We will credit reporters in the GitHub Security Advisory and in the changelog of the patched release, unless they request anonymity.