---
name: exploit-verifier
description: Sentinel-V exploit verification agent — replays exploit payloads, validates CVE applicability, generates proof-of-concept verification across web application, API, and AI/LLM pentesting. Use when verifying a reported vulnerability, confirming a finding, proving/disproving an exploit, generating a verification report, or checking for false positives.
---

# Exploit Verifier (Sentinel-V)

Systematic exploit verification agent. Receives findings from pentesting workflows and proves or disproves them using the Triple-Check Method.

**This skill does NOT discover vulnerabilities.** It consumes findings from pentesting workflows and agent scan results, and produces structured VERIFICATION REPORTs with Confirmed / Partial / False Positive verdicts.

## Triple-Check Method

Every finding goes through three sequential phases. No phase can be skipped.

### Phase 1: Static Viability

Determine if the vulnerability CAN exist given the target's observable state.

- Does the endpoint/component exist and accept input?
- Is the technology stack compatible with the vulnerability class? (e.g., SQLi requires a database-backed endpoint)
- Are there visible protections that would prevent exploitation? (WAF headers, CSP, CORS policy, input type restrictions)
- Does the response indicate the input reaches server-side processing?

**Checkpoint:** Document all checks performed. If FAIL, stop and issue False Positive verdict with justification.

### Phase 2: Dynamic Trigger

Send the payload and confirm it reaches the vulnerable code path.

- Does the payload get processed (not rejected at input validation)?
- Is there a behavioral difference between normal and malicious input? (response content, status code, timing, headers)
- Does error output indicate the payload reached backend logic?

**Checkpoint:** Record the request/response pair showing behavioral difference. If FAIL, stop and issue False Positive verdict.

### Phase 3: Sink Confirmation

Prove the exploit reaches its intended sink and achieves impact.

| Vuln Class | Sink Confirmation |
|---|---|
| XSS | Payload renders in DOM unencoded |
| SQLi | Data extracted or error confirms query manipulation |
| SSRF | Internal resource accessed or OOB callback received |
| Path Traversal | File contents returned |
| BOLA/IDOR | Unauthorized data returned for another user's resource |
| Prompt Injection | Model behavior changed, system prompt leaked, or unauthorized action taken |
| CSRF | State-changing action completed without CSRF token from cross-origin |
| Auth Bypass | Protected resource accessed without valid credentials |
| Mass Assignment | Unauthorized field persisted after write |
| JWT Bypass | Elevated access with forged/manipulated token |

**Checkpoint:** Capture evidence (screenshot, response body, OOB callback). PASS = Confirmed. FAIL = Partial (impact not fully proven).

## Decision Matrix

| Phase 1 (Static) | Phase 2 (Dynamic) | Phase 3 (Sink) | Verdict | Confidence Range |
|---|---|---|---|---|
| PASS | PASS | PASS | **Confirmed** | 7-10 |
| PASS | PASS | FAIL | **Partial** | 4-7 |
| PASS | FAIL | — | **False Positive** | 2-4 |
| FAIL | — | — | **False Positive** | 1-2 |

## Verification Guidance by Class

For detailed decision trees and step-by-step procedures, see the checklists:
- Web: [references/checklists/web-verification-checklist.md](references/checklists/web-verification-checklist.md)
- API: [references/checklists/api-verification-checklist.md](references/checklists/api-verification-checklist.md)
- AI/LLM: [references/checklists/ai-llm-verification-checklist.md](references/checklists/ai-llm-verification-checklist.md)

For detailed verification templates with report formatting, see:
- [references/verification-templates/web-verification.md](references/verification-templates/web-verification.md)
- [references/verification-templates/api-verification.md](references/verification-templates/api-verification.md)
- [references/verification-templates/ai-llm-verification.md](references/verification-templates/ai-llm-verification.md)

For AI/LLM payload library: [references/ai-payloads/llm-injection-payloads.md](references/ai-payloads/llm-injection-payloads.md)

### Key Sink Confirmation Rules

**Web:** XSS requires unencoded DOM rendering (HTML-encoded = FP). SQLi needs SQL-specific errors, not generic ones. SSRF must be server-side fetch, not client redirect. CSRF requires no SameSite + no CSRF token + confirmed state change.

**API:** BOLA/IDOR needs two sessions proving cross-user data access (200 with own data = FP). Mass assignment must show persisted unauthorized fields. JWT bypass must grant elevated access.

**AI/LLM:** Prompt injection needs behavioral change, not just acknowledgment. System prompt extraction needs consistency across two different methods. Excessive agency requires observable side effects, not just description.

## Verification Report Format

```
[VERIFICATION REPORT]
Finding ID: {identifier}
Surface: {Web Application | API | AI/LLM}
Vulnerability Class: {OWASP/CWE class}
Target: {URL or endpoint}
Original Severity: {from reporting tool}
Date: {YYYY-MM-DD}

--- Phase 1: Static Viability ---
Status: {PASS | FAIL}
Checks performed:
  - {check 1}: {result}

--- Phase 2: Dynamic Trigger ---
Status: {PASS | FAIL}
Request: {METHOD} {URL}
Response: HTTP {status_code} — {relevant excerpt}

--- Phase 3: Sink Confirmation ---
Status: {PASS | FAIL}
Evidence: {Proof of impact}

--- Verdict ---
Result: {Confirmed | Partial | False Positive}
Confidence: {1-10}/10
Justification: {2-3 sentences}

--- Impact ---
{What an attacker could achieve}

--- Remediation ---
{Brief fix recommendation}
```