Skip to content
BreachPilot

Safety model

Built for authorized security testing.

Layered controls, not a single switch — with honest language about what each layer does and doesn't do. The attack path is unrestricted but target-locked; recon stays fully gated.

Only test systems you own or have explicit written permission to assess.

The layers

Eight controls, no single point of trust

Each layer narrows what the agent may do — scope, risk, routing, and audit all have to agree.

Disposable execution sandbox

The isolation boundary: hardened per-run container, default-DROP network containment authorizing only the effective target allowlist. Sandbox failures fail closed — host execution is never an automatic fallback.

Mission authorization

mission.yaml declares allowed / disallowed assets, forbidden actions, rate limits, testing modes and risk profile.

Scope gate

Answers whether an action may touch a target: exact domains, wildcards, IPs, CIDRs, explicit denies, forbidden action types, third-party detection, per-target rate limits.

Risk + budget enforcement

Action risk classification, per-session command budgets and human-approval requirements for high-risk actions.

Tool routing controls

Which tools may run, where outputs land, how secrets are redacted.

Exploit permission modes

read_only (propose-only recon) · approve_only (operator approves sensitive actions, denials audited) · full_access (lab attack posture — see below).

OPSEC advisory layer

Target-aware, advisory-only — pacing and noise suggestions, never a gate. The command always executes.

Audit + evidence

Evidence store, state-transition audit log, exploit-session timelines, encrypted credential handling.

Full-access mode

Attack posture, stated plainly

For authorized lab targets only — what stays enforced when approvals are relaxed.

In full_access, the policy auto-approves every in-scope action with no command-content inspection — destructive commands, egress, reverse shells, credential dumping, Metasploit and Python write/run are all allowed against authorized targets. The two safeties that remain:

  1. The target-IP allowlist lock — enforced at the MCP tool layer. Every destination is extracted from every command (URL authorities, /dev/tcp hosts, LHOST/RHOST, scanner targets, bare IPs, hostnames, Python script bodies, MSF RHOSTS and pivot hosts). Anything off-allowlist is BLOCKED. It is a destination guard, not a complete sandbox.
  2. The mission scope gate — tools mapped to forbidden-action categories, or assets outside allow rules / inside disallowed assets, are denied with a SCOPE_DENIED audit row.

The operator-box filesystem is unrestricted by design — run on a throwaway lab box. Every target-touching action, denial and scope event lands in the tamper-evident SHA-256 audit chain.

Further reading

What to read next

Safety model

Scope checks, risk checks, permission modes, audit records, secure dev rules.

Read

Sandbox

Disposable worker architecture, network containment, fail-closed posture, residual risks.

Read

Outcomes & evidence

Outcome taxonomy, truth-vs-claim, finding verification, report generation.

Read

Full source: docs/safety-model.md