ENGINEERING INDEX / ENTRY 05
CASE 05 / DEFENSIVE SECURITY / SCOPE CONTROL
A target name is not permission.
Security tooling needs more than a polite instruction to stay in bounds. HackBot's scope layer checks recognized targets against an engagement list, including explicit exclusions, before a command is treated as allowed.
How does a defensive assistant keep a command inside an explicitly approved target set?
Where the handoffs happen.
The enforcer defaults to deny when it cannot extract a target. A separate guard can return dry-run or require a second confirmation for designated targets. A regression test covers multi-label hostnames so a parser mistake does not silently change which target is being checked.
- 01Operator-defined scope
- 02Target extraction
- 03Inclusion and exclusion check
- 04Allow, deny, or confirm
What the record earns.
27 scope and defense tests passed in the latest focused run.
- Observed receipt
- On September 25, 2026, 27 focused tests passed across scope extraction and defense. The tests include a three-label hostname allowed only when explicitly added, a sibling hostname refused, dry-run behavior, and two-stage confirmation.
- Source and scope
- HackBot's scope enforcer, defense scope guard, and focused scope/defense tests. The checked files were inspected in the current repository state; this case does not claim every execution route has been audited.
What this does not prove.
These are local policy and parser tests. They do not prove a real scan was authorized, that every HackBot tool passes through this gate, or that production targets were tested.
Where the work goes next.
Trace one approved tool call end-to-end through the gate and retain a redacted decision receipt without exposing real targets.