BRA is an AI-augmented security assessment framework — an extension to the operator, not a replacement. The operator drives the engagement and owns the decisions. An LLM agent works alongside as force-multiplier — running reconnaissance, capturing evidence, drafting findings, generating the report — but every action it takes is gated, anonymized, and recorded by a governance layer the operator controls.

Before any agent is launched, BRA runs you through a multi-step scope intake wizard: privacy posture (what gets anonymized before reaching the model), target name + version, in-scope IPs / CIDRs / URLs / file paths / device addresses, out-of-scope exclusions, time window, written-authorization attestation, active-testing permission, and a per-engagement safety-approvals matrix. The framework then auto-detects identifiable values in the scope (IPs, hostnames, credentials), shows them to you for review, and anonymizes the approved set before anything reaches the LLM.

From there, the agent runs reconnaissance, captures evidence, and files leads and findings. Every request, response, tool call, and command flows through multiple layers that:

As the engagement runs, three living records are built up — Intel (services, endpoints, infrastructure facts), Leads (investigation threads worth pursuing), and Findings (confirmed vulnerabilities).

When the operator ends an engagement and selects which findings to include, the governed schema is used to generate a full engagement report with executive summary, per-finding detail, remediation roadmap, and vendor disclosure timeline.

A scoped, read-only summary of the active engagement: governance posture, scope, lifecycle, statistics, and recent findings. Operator network identifiers are redacted in this screenshot.

The Operations tab is the live engagement workspace — the operator sees the agent's reasoning, proposed commands, and decision options inline, with three independent gates riding every action:

• Tool approval — first-time use of any tool (Bash, Write, Edit, etc.). Per-call: Allow Once, or Allow + Override to record a rule that suppresses repeats of the same pattern.
• Target scope — every host / IP / URL in the command must match the approved scope. Subdomains and unrelated targets prompt a modal with Full / Limited / Deny before anything runs.
• Governance token — destructive ops, active testing, framework writes, etc. each require their own token to be active. The prompt offers Once / Session / Engagement / Deny scoping.

Scope check — out-of-scope subdomain, operator chooses Full / Limited / Deny

DESTRUCTIVE-APPROVAL token gate — Once / Session / Engagement / Deny

An override is an approval rule the operator records during an engagement so the agent doesn't ask again for the same pattern. They are visible in Loadout → Overrides and can be enabled / disabled / reviewed there. The framework keeps a per-decision history so every Allow / Deny remains auditable after the fact.

Override management itself is governed: writes require the OVERRIDE-APPROVAL token. Without it, the panel is read-only and existing overrides apply but new ones cannot be created.

Three living records are built up as the engagement runs:

• Intel — services, endpoints, technology facts the agent confirms (e.g., open ports, DNS / mail infrastructure, framework fingerprints).
• Leads — investigation threads worth pursuing (e.g., a softfail SPF record, a misconfigured cookie, a suspicious header) before they become findings.
• Findings — confirmed vulnerabilities. As the agent identifies them they are emitted to a queue for documentation by a dedicated subagent; the main thread keeps running so the operator can drive forward while the queue drains.

Pending Queue: 2 — F-001/2/3 documented, F-004/5 still incomplete

All 5 documented with full schema records

Leads tab — investigation threads captured during recon

End the engagement, fill in the disclosure intake form (researcher / vendor / CNA fields, report types: pentest / vendor / research), select which findings make the report, and the framework generates a structured report.

End Engagement Intake — required disclosure metadata

Findings Selection — operator chooses what makes the cut

The report includes an AI-enhanced executive summary, technical summary covering methodology and intelligence highlights, per-finding detail with CVSS, a phased remediation roadmap, and a disclosure timeline ready to send to the vendor.

Executive Summary — engagement overview, key findings table, risk summary, recommendations

Technical Summary — methodology, intelligence highlights, tools, coverage

Findings Summary by severity + phased Remediation Roadmap

Distribution log + Disclosure Timeline + Vendor Submission draft

Slim activates a small core set of governance tokens. Premium unlocks the rest of the catalog and adds session/engagement scoping.

Incomplete list — additional tokens are introduced and rotated as the framework evolves; the rows below are representative, not exhaustive.

• You own the binary. No calls home, no telemetry, no license server.
• You own the API traffic. Requests go from your host directly to Anthropic.
• Anonymization happens locally. The map is generated on your disk; the agent never sees the real values until after rehydration.
• Control in Depth. Engagements follow the Control in Depth principle. The agent is mechanically contained, ensuring scope and rules of engagement are law, not suggestion.
• Replacement-resistant. The control boundary survives replacement — model, tool, interface, and operator agnostic.