User Guide

SiegePoint Verify

SiegePoint Verify is a detection-validation service: it fires real, safe attack techniques at your production environment and grades whether your monitoring saw each one. It reuses the SiegePoint attack platform — the Mangonel engine, the Authorization Gate, and the ATT&CK-mapped technique library — but inverts the scoreboard. Where the main SiegePoint user guide asks how deep an attacker could get, Verify asks whether you would have noticed.

Version v1.0Updated July 8, 2026Living document — kept in sync with the build
How to read this guide: Verify is In build. Where a capability is defined but not yet running, it is tagged as such and described as intended behavior. The Build Status table below is the source of truth for what is Live today.

What Verify is

Verify belongs to the Breach & Attack Simulation category. It runs the same techniques the SiegePoint attack service runs, but it does not grade the attacker — it grades your defenses. Each fired technique resolves to the highest defensive outcome it produced, on a five-rung scale from D0 Blind (executed, zero telemetry) up to D4 Prevented (a control blocked the action outright). That scale is the Detection Ladder, and it is the mirror image of the attack side's Surrender Ladder. Prevention, detection, and response are tracked as separate rates, so a control that silently blocks an attack scores prevention without being counted as one your team actually saw.

The inversion

A pentest halts at the first objective it reaches — it wants to know how far in an attacker can get, and it stops the moment it proves the point. Verify does the opposite. It does not halt; it loops the whole coverage set, firing every technique in scope so it can measure your monitoring against each one.

That is why the worst result on the Detection Ladder — D0 Blind, a technique that executed and produced zero telemetry — is also the most valuable finding. It is a gap you did not know you had.

The two-timer idea

A rung tells you whether you saw an attack; a timer tells you how fast. Every fired technique is stamped with two timers — MTTD (execution to first alert) and MTTR (alert to first response) — and they are always reported alongside the rung as a pair. A detection that fires an hour late is a different finding from one that fires in seconds, and Verify keeps that distinction visible.

What you get back

The deliverable is a coverage map over ATT&CK, not a pass/fail grade. Its core payload is a blind-spot list: every technique your stack graded D0 or D1, ranked, each mapped to the log source that would close the gap. In plain terms, it is a prioritized detection-engineering backlog — "here are the techniques your stack is blind to, and here is what would fix each one." Because detection coverage is perishable (rules get retired, tools get swapped, staff turns over, and the ATT&CK matrix itself moves), Verify is built to be re-run on a schedule so it can report the delta over time.

An honest limit

A green coverage score is evidence that the tested techniques were seen under test conditions. It is not a guarantee against a novel or deliberately evasive adversary. Verify measures the controls you have against the behaviors you chose to fire — and it states that limit in every report rather than overselling the result.

Relationship to the SiegePoint attack service

Verify is not a separate product bolted on; it is the same platform pointed at a different question. It inherits the Mangonel engine, the ATT&CK-mapped technique library, and the full Authorization Gate from the attack side — signed authorization reference, fail-closed scope and platform allowlists, and a named approver and window for anything above passive execution. Because it fires at production, it runs only the safe, reversible subset of techniques: benign markers, read-only or self-cleaning actions, hard caps — enough to emit a signal, never enough to cause impact. For the design rationale and the data model behind all of this, see the /verify-architecture-guide.html.

Build Status

ComponentStatusNotes
Client portalLivesiegepoint.apintelligence.ai/portal — multi-tenant, per-client isolated.
Mangonel engine (shared)In buildReused from the attack side; passive S0–S1 external-recon plugin built and self-tested.
Authorization Gate (shared)In buildBuilt and self-tested on the attack side; inherited by Verify.
Observation connectors (read-only SIEM/EDR/XDR)In buildBeing scaffolded; read-only into the client environment by design.
Scoring (Detection Ladder + MTTD/MTTR)In buildGrading and signal-attribution logic being scaffolded.
White-labeled coverage reportIn buildReporting plane being scaffolded.

The Verify service and its architecture are defined; the engine it reuses is itself in build on the attack side. The client portal is the only Verify component Live today — connectors, scoring, and reporting are still being built.