Skip to content
Bugb Docs

Authorization and blast radius

A verify run sends real exploit traffic at a running application and lets a coding agent edit the repository it is testing, unattended. This page states exactly what that means, where the boundaries are, and which are enforced rather than only intended.

Read it before the first bugb auto, not after.

Three blast radii

Section titled “Three blast radii”
Reach Bounded by
The target real exploit traffic, under every captured identity your attestation and the plan you approved
Your repository an agent edits it every round a bugb/run-<id> branch, one commit per phase
Your machine a coding-agent CLI runs with its approval prompts disabled the per-phase argv in $BUGB_HOME/config.toml

The third is the one people do not expect.

The agent runs with approvals bypassed

Section titled “The agent runs with approvals bypassed”

As shipped, bugb launches each agent with the flag that turns its permission prompts off — --dangerously-skip-permissions for claude, --dangerously-bypass-approvals-and-sandbox for codex, --approval-mode yolo for gemini. That is a deliberate choice: an unattended loop cannot stop at a prompt.

The consequence is stated in bugb’s own source, as a guardlink annotation on the configuration that does it:

Agents run with permission prompts disabled, so a prompt-injected repository could induce arbitrary local command execution during the annotate phase.

The argv is per-phase configuration rather than code, so it can be narrowed to an allowlist for any phase without touching the product. That is the mitigation the same annotation claims, and it is opt-in: nothing narrows it for you.

The attestation

Section titled “The attestation”

Any run that sends traffic or edits code requires --attestation, unless it came from a plan you approved:

Terminal window
bugb auto /path/to/repo --target http://127.0.0.1:9054 \
  --attestation "Authorized self-test, Jane Doe, 2026-08-18"

It is recorded in the run manifest and in cxg’s audit log, and it appears in the run’s summary report:

- Authorized under: Authorized whitebox pentest of OWASP NodeGoat dogfood target on local Docker (web.nodegoat.orb.local), owner-run via Claude Code, 2026-08-18.

Approving a plan is the same consent in a different form — the plan carries the target, the identities and the depth you reviewed, so approval is what authorises the run rather than a repeated flag.

The attestation does not check anything. It records what you asserted, so that a run’s own artifacts say under whose authority it happened.

What touches your repository

Section titled “What touches your repository”

Two things, on the verify tier:

  1. A branch, bugb/run-<run-id>, checked out at the start.
  2. Commits on it — one per phase — carrying annotations the agent wrote.

Nothing else. Verified on a model-tier run: git status --short was byte-identical before and after, and the only change was the new branch.

--no-checkpoint skips the branch and the commits; annotations are then left uncommitted in your working tree, which is worse to review, not better.

The write-back phase writes @confirmed annotations next to the vulnerable line and — per the product’s design — verifies them by re-parsing the model rather than by trusting what the agent reported.

What lives outside your repository

Section titled “What lives outside your repository”

Everything else, under $BUGB_HOME (default ~/.bugb): run manifests, journals, event logs, ledgers, generated probe templates, cxg logs, reports, and environment recipes.

That is not tidiness. guardlink status and guardlink validate rewrite several agent-instruction files on every call, so in-repo state would churn inside the very commits used as diff baselines.

Two consequences worth planning for:

  • $BUGB_HOME is sensitive. It holds live session state for the identities a run used. An environment recipe stores passwords as '***', but a captured session is a working credential.
  • <codebase>/.bugb/ does receive a mirror of a run’s probe templates, unless you pass --no-local-session. That is what bugb replay re-runs.

The one execution path

Section titled “The one execution path”

The dashboard and the MCP server can read runs and hand you a command. Neither starts one. Verified: bugb dashboard binds 127.0.0.1 only, and every MCP tool but generate_model — which builds a threat model and sends no traffic — declares itself read-only.

The CLI stays the only thing that executes a scan, so there is no second path that can drift from it, and no surface where an agent or a browser tab can start one on your behalf.

Section titled “Related”