# Oracle Verification Technique > Machine-oracle verification for security findings: promote a finding to VERIFIED only when a named oracle re-runs the exploit N/N against the live target AND a negative control fails on a safe surface, then package a portable proof capsule the client can replay. Use before reporting web/API/auth findings, when triaging scanner output (nuclei/nikto/zap/sqlmap), when an LLM or sub-agent asserts a vulnerability without proof, or when a report must separate proven findings from candidates. Tool-agnostic; pairs with web-exploit, vuln-exploit, and report-generation techniques. - Skill: `aeondave/oracle-verification-technique` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add aeondave/oracle-verification-technique` - Raw SKILL.md: https://api.skillmd.com/api/skills/aeondave/oracle-verification-technique/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - License: MIT - Author: AeonDave (https://skillmd.com/u/aeondave) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/aeondave/oracle-verification-technique --- # Oracle Verification Technique **Goal**: A finding is a *candidate* until a **named machine oracle** reproduces it against the live target N-out-of-N times AND a negative **control** fails on a safe surface. Only then is it **VERIFIED**, shipped with a **proof capsule** anyone can replay. An LLM assertion, a scanner hit, or a single lucky exploit is never proof on its own. ## When this technique applies - Before reporting any web/API/auth/injection finding as confirmed. - Triaging third-party scanner output (nuclei, nikto, zap, sqlmap, dalfox) — hold it back until re-proven. - An LLM or delegated sub-agent claims a vulnerability without a reproducible receipt. - A report must split **VERIFIED** from **candidate**, or a CI gate must break only on proven findings. - Multi-step chains where each hop must be independently proven before the chain is claimed. Do not use this to *find* bugs — it only decides whether a suspected bug is real. Discovery stays with the web-exploit / vuln-exploit / recon techniques; this gates their output. ## Core rule (enforce, don't just intend) > **No verdict without a named oracle.** A `VERIFIED` badge that cannot name the oracle that earned it is rejected and downgraded to `candidate`. The model coordinates; the oracle decides what is true. Encode this as a hard check in your workflow and in report generation, not as a hope. ## The verification loop For each candidate finding, run these gates in order. Fail any gate → stay `candidate`. ### 1. Name the oracle Pick a deterministic oracle for the vuln class — a check that returns a machine-decidable positive/negative from the target's *actual response*, not a pattern match on a scanner label. If no oracle exists for the class, the finding cannot be `VERIFIED` (report it as `candidate — no oracle`). Load `references/oracle-catalog.md` for per-class oracles and their positive signals. ### 2. Re-run N/N against the live target Re-execute the exploit recipe **N times** (default N=3) against the real target. Every run must produce the positive signal. Any miss → `candidate` (flaky / not reliably exploitable). Fresh session/token each run where auth is involved — a replay that only works with a stale cached token is not proven. ### 3. Negative control must fail on a safe surface Run the *same* oracle against a surface that must be safe: a non-vulnerable endpoint, a patched route, a benign parameter value, or a control payload that should do nothing. The control **must fail** (no positive signal). If the oracle fires on the safe surface too, the oracle is broken or the signal is ambient — the finding is **not** proven. This is what stops false positives; do not skip it. ### 4. Separate proof from impact A bare signal (an out-of-band callback, a reflected marker) proves *reachability*, not *harm*. Rate reachability-only findings **medium** until an impact oracle reproduces real impact (data read, auth bypass, RCE). Do not assume impact from a probe. ### 5. Package the proof capsule Emit a portable, replayable capsule (see `references/proof-capsule.md`): oracle name, exact recipe (request/command + payload), positive signal, the N/N run log, the failing control, and a one-command replay. The client/dev replays it against the live target **without trusting your tool**. Multi-step chains bundle every proven hop into one capsule. ## Scope safety during verification - Host-lock active oracles (sqlmap, dalfox, raw HTTP) to the declared engagement target. Never feed third-party URLs scraped from page content into an attack oracle. - Re-running exploits is active testing — respect engagement posture (pentest vs red-team vs lab). Confirm before any oracle that is destructive or irreversible. - If an aggressive discovery sweep knocked the target over, **wait for it to answer again** before running oracles, or every gate fails and you falsely report zero. ## Output contract Report each finding with an explicit status: - `VERIFIED` — oracle named, N/N passed, control failed, capsule attached. - `candidate` — suspected but not (yet) proven; state which gate it failed. - `candidate — no oracle` — no oracle exists for this class; manual verification required. Never let a scanner-labeled or LLM-asserted finding reach the `VERIFIED` column. ## Pair with sibling skills - `offensive-techniques/web-exploit-technique/SKILL.md` — supplies the exploit recipes this skill gates. - `offensive-techniques/vuln-exploit-technique/SKILL.md` — impact validation for the impact oracle (gate 4). - `offensive-techniques/report-generation-technique/SKILL.md` — consumes the VERIFIED/candidate split and the capsules. - Behavioural gates `evidence-before-claims` and `verification-before-completion` — this skill is their enforced, machine-checked form for findings. ## Resources ### references/ - `references/oracle-catalog.md` — per-vuln-class oracles: positive signal, recipe skeleton, and the negative control to run. Load when choosing or building an oracle (gate 1–3). - `references/proof-capsule.md` — the proof-capsule schema and replay contract. Load when packaging a VERIFIED finding (gate 5).