User Guide
Authorization, Modes & Safety
SiegePoint Verify fires real attack techniques at your production environment, because a lab cannot tell you whether your SOC is awake. That power is bounded on every side: the same Authorization Gate that governs the attack platform governs Verify, and Verify runs only the safe, reversible subset of techniques — enough to emit a signal your monitoring should catch, never enough to cause impact.
Verify is a detection-validation service — it grades whether your monitoring saw each attack, not how deep an attacker could go. It reuses the SiegePoint attack platform (the Mangonel engine, the Authorization Gate, and the ATT&CK-mapped technique library) and inverts the scoreboard. For how outcomes are graded, see the Detection Ladder. For the full technical treatment, see /verify-architecture-guide.html.
The same gate, no exceptions
Because Verify executes against live production rather than a sandbox, it inherits the full Authorization Gate. Nothing runs above passive activity until every one of the following is satisfied, and the gate fails closed — if a check is missing or ambiguous, execution does not proceed.
- A signed
authorization_ref— a specific, recorded authorization tied to the engagement, not a verbal go-ahead. - A scope and platform allowlist that fails closed — only the systems and technique classes explicitly listed are eligible; anything outside is refused.
- A low rung ceiling by design — Verify carries only the safe, reversible subset; there is no configuration that lets it escalate into destructive behavior.
- A named approver and a defined window — a specific person authorizes the run, and it is bounded to an agreed time window.
In build Verify's connectors, scoring, and reporting are being scaffolded. The Authorization Gate and the Mangonel engine it depends on are built and self-tested on the attack side (passive activity, In build for the Verify-specific scoring path). The client portal is Live at siegepoint.apintelligence.ai/portal. Statements below describe intended behavior where tagged.
Safe by construction, not by promise
Verify is non-destructive by design. Every technique it fires is drawn from the safe, reversible subset and is shaped so that it emits the signal your controls should observe while remaining harmless:
- Benign markers. Each technique carries a distinctive but harmless execution marker — a tagged process or command token, a canary host or account, a labeled user-agent, or a synthetic filename — woven into what the technique naturally emits.
- Read-only or self-cleaning. Actions either observe without altering state or remove their own artifacts after execution.
- Hard caps. Volume, rate, and blast radius are capped so a technique cannot run away.
The observation side is equally constrained. Verify's Observation plane is read-only into your world: it pulls events and alerts from your SIEM, EDR, or XDR and accepts push-confirmations from your SOC. It never writes to, tunes, or silences your controls. Grading measures your stack as it actually runs; it does not touch it.
What a green score does and does not mean
Verify reports an honest limit, and so should you. 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. That framing is stated in every report and should never be oversold.
The three modes
Verify runs in one of three modes. They differ only in who on the defensive side is told the test is happening — the technique set and the safety envelope are identical across all three. The choice trades signal purity against coordination cost.
| Mode | Who knows | What it measures | Best for |
|---|---|---|---|
| Blind | The blue side is not told | The truest signal — tooling, rules, and the human analyst all under realistic conditions | An honest baseline; highest coordination cost |
| Coordinated | The SOC knows the window | Tooling and detection rules, with the human factor held constant | Rule and tooling tuning |
| Multi-party | Client and MSSP both consent | The outsourced SOC itself, which is the subject of the test | Measuring a managed-detection provider |
The multi-party consent rule
Multi-party mode exists for one specific situation: your detection is delivered by a third party — an MSSP or MDR provider — and that provider is the thing being measured. In this case the outsourced SOC is the subject of the test, not merely a bystander to it, so both parties must consent before the run proceeds:
- The client, who owns the environment and authorizes attack activity against it.
- The MSSP, whose detection performance is being graded and who is entitled to know they are being measured.
Both consents are recorded through the Authorization Gate, and the run writes to a shared, tamper-evident audit that both parties can see — the same HMAC-chained audit log used across the SiegePoint platform. Neither side can quietly alter the record of what was fired or what was observed. This keeps the measurement fair: the provider is graded on evidence both parties witnessed, not on a report one side could shape after the fact.
Grading itself is attribution-based, which is what keeps the modes sound. A result above the lowest rung requires a positive tie-back — the observed alert must carry the technique's execution marker (or match its pre-declared expected-signal map) inside a bounded, clock-normalized window. An alert that merely happened nearby does not count; that is coverage inflation, the failure mode Verify is built to avoid. Silence is a real finding, not an error. See the Detection Ladder for how each outcome is resolved.
Why safety and repeatability go together
Detection coverage is perishable — rules get retired, tools get swapped, staff turn over, and the ATT&CK matrix moves underneath you. Verify is therefore structured as a subscription: it re-runs on a monthly or quarterly cadence and reports the delta and trend over time. Every run is isolated per client and per tenant, pins the ATT&CK matrix version it graded against, and records the mode, window, and matrix version alongside its results. The safety envelope described here applies identically to every re-run, so repeating the test never widens the blast radius.
For where Verify sits within the broader platform and how it relates to the attack side, see the SiegePoint user guide.