Building a security workspace that keeps a paper trail
Black-box models are a liability in a reviewable workflow. How we designed Bolt so every assertion can be traced back to attached evidence.
The problem with black boxes
An analysis tool that returns an answer with no way to verify it is a trust problem in a security workflow. If a model tells you a host is compromised, your team needs to know why it thinks that — and be able to disagree.
So we built Bolt around a simple constraint: every assertion should resolve to supplied evidence. The evidence is attached, the case is named, the asset scope is explicit, and the mode (defensive or authorized test) frames the analysis posture.
The design decisions that followed
- Mode is a boundary: it selects the analysis posture and the asset library, not a claim about intent
- Evidence is treated as untrusted data: logs and tickets can contain text that looks like instructions
- Every investigation is a record: a case, an evidence reference, a result, and an owner
- The output is a reviewable artifact: facts separated from hypotheses, with confidence and missing telemetry stated
What it does not do
Bolt does not infer authorization, does not claim an indicator is malicious, and does not assume missing telemetry means nothing happened. Those are the claims that get people in trouble — and they are exactly the claims we refuse to automate.
Bottom line
A security workspace is only as good as its paper trail. Bolt keeps a record behind every answer so the next reviewer — human or regulator — can follow the reasoning.

