How the review works · every phase, live
Seven phases. Three layers. One signed verdict.
Most scanners read files one at a time. Attestral runs a pipeline: it ingests everything the agent touches, builds one system model, traces what can actually reach what, sweeps the graph with typed rule packs grounded in current attack research, layers ML and an LLM judge on top, seals the evidence, and compiles the verdict into runtime policy. Press play to watch a whole review run, or step through any phase.
Ingest
attestral/ingest/rules/core_rules.yaml · the matcher, verbatim
- id: ATL-202 title: Tool fleet forms an exfiltration chain (lethal trifecta) severity: critical target: model # binds across components, not one file match: model_capability_combo: - [filesystem, database, saas_data, memory] # private data - [network, messaging] # an exit
Rules are pure data: five YAML packs (agentic and cross-boundary in the core pack, one pack each for AWS, Azure, GCP, and Kubernetes). Every matcher is a named, typed check over the model's attributes; there is no eval anywhere, and an unknown matcher never fires: the engine fails closed. Conjunctions compose real signals, so ATL-176 is a plaintext non-loopback endpoint AND provably-no-auth AND a shell capability on one server: remote unauthenticated RCE, stated as three facts.
Review layers · every finding labeled by origin
--ml, always offline, identical finding shape.
web-fetch tool description → injection score
+1 finding
--judge and your API key, an LLM re-examines each finding against the modeled system and votes confirmed / false-positive / needs-review. A confident false positive is auto-waived, never deleted: it stays on the chain with the judge's reasoning.
6 cross-examined
Separating the layers is the point: a regulated reviewer can accept the deterministic findings outright, weigh origin: ml as a score, and read the judge's reasoning as an opinion on the record. The review-layers deep dive.
Evidence chain · SHA-256 · verify offline
OFFLINE
The review becomes the runtime · compile → guard → drift
The same evaluator makes every decision: attestral guard vets each tools/call and resources/read in line, attestral drift diffs telemetry against the compiled policy, and the executed red-team (attestral pentest) plants a canary, measures whether it really left, and compile --close-loop denies any channel it proves. Runtime loop · Red-team.
Where the rules come from
Every check starts as research, and earns its way in.
The pack is not a backlog of hunches. A standing research radar sweeps the current agentic-security literature - OWASP's LLM and Agentic Top 10s, MITRE ATLAS, the MCP specification's security best practices, fresh CVEs and vendor incident write-ups - and every candidate check has to survive the same gauntlet before it ships.
Research sweep
OWASP ASI & LLM Top 10 (2026), MITRE ATLAS, the MCP spec, new CVEs, incident write-ups, arXiv.
A typed rule
The attack class becomes a fail-closed matcher over the system model, citing the real control.
Proof it fires
A config that triggers it, plus near-miss negatives that must stay silent. Both are committed.
Zero-FP gate
The detection benchmark runs in CI: every labeled finding fires, benign designs stay clean.
Into the pack
The rule lands with attestral explain docs. A check that would not change a decision is dropped.
Framework references are an audit artifact, not decoration: attestral explain ATL-176 prints the rule, its reasoning, and the controls it cites, straight from the pack.
Run the phases yourself
The whole pipeline is a handful of commands.
Everything above maps one-to-one onto the CLI. No account, no server; only the judge needs a key.