What bees can and cannot touch

After reading this page you'll know exactly what a bee can reach during a run, which boundaries enforce that, and which risks remain open. The contract underneath all of it: No human writes code. A human always reviews.

Where a bee runs

Every bee runs in its own container (a Fargate task in production, docker run locally) with an ephemeral temp directory that starts clean each run. Nothing is shared between runs and nothing persists when the container exits. In production, IAM roles are scoped per task, and agents cannot spawn more agents at the infrastructure level.

What a bee can reach on GitHub

Swarm authenticates as a GitHub App. The trigger services mint short-lived installation tokens (1 hour, cached per repo and refreshed near expiry) that carry only three repository permissions: Contents (read/write), Pull requests (read/write), and Metadata (read). The App only works on repos it has been explicitly installed on, so a bee cannot touch a repo nobody granted it.

The output boundary is the PR. Bees have submission authority, never merge authority: work lands as a branch and a pull request authored by cube-bees[bot], and the merge button is a human decision. High-blast-radius tool calls (destructive bee dispatch, pushes to protected branches, GitHub API calls that bypass PR review) pause for explicit human approval before they fire (ADR 0047). Keep branch protection on in your target repos; Swarm's contract assumes review happens, and branch protection is what makes skipping it impossible. See reviewing a bee PR.

How long a bee can run

Recipes are phased with action budgets (for example, support-bee: 15 actions to investigate, 25 to fix, the rest to ship). These budgets are instructions to the model, not enforced by code. The hard backstops are turn caps enforced by the runtime, GOOSE_MAX_TURNS (typically 100) on Goose runs and BEE_SDK_MAX_TURNS (default 80) on SDK runs, which force-stop a run that won't converge. Cost controls are covered in cost and limits.

Untrusted text and prompt injection

A bee's task text (Jira ticket bodies, READMEs, Slack messages, PR descriptions) can be written by anyone who can file a ticket or edit a file, so Swarm treats it as a prompt-injection surface. Three layers compose (ADRs 0047 and 0074):

• Trust tiers. Every trigger is classified from its provenance, never its content, into internal (Slack/dashboard/IDE with a resolved human identity), partner (Jira/GitHub/Zendesk/cron), or anonymous (fail-closed default). The tier hard-limits capability: partner runs can never do destructive operations even with operator approval, and anonymous runs are read-only. The model cannot raise its own tier.
• Approval gate. On internal runs, destructive calls still pause for a human.
• Input wrapping. Untrusted text is sentinel-wrapped and framed as data, with known break-out patterns neutralised. This layer is hygiene, not a boundary: a novel phrasing still reaches the model as quoted text.

The full picture, including what each tier may do, is in docs/security/prompt-injection-threat-model.md in the repo.

What gets recorded

Runs emit pipeline events (a denied capability emits a capability-denied event), and the dashboard's /audit page and CSV export read from the audit trail. Secrets are redacted at write time (ADR 0090): any payload field whose key looks credential-shaped (token, password, api_key, …) is masked before it reaches the database, so a leaked value never lands in the audit store. Redaction is key-name based and best-effort: a secret under an unrecognised key name is not caught.

Residual risk, honestly

• A well-crafted payload on an internal run could phrase a destructive call so the approval card reads as legitimate. Read the tool name and arguments, not the model's stated reason.
• Input sanitisation is pattern-based and bypassable by construction; containment relies on the tiers and the approval gate.
• Tier classification trusts the trigger envelope's source and identity fields; a trigger that lied about its source would be mis-tiered.
• Recipe action budgets are soft; only the turn caps are enforced.