# How Shannon's "No Exploit, No Report" Policy Eliminates False Positives in Security Testing

> Discover how Shannon's No Exploit No Report policy drastically reduces false positives in security testing by demanding reproducible proof of vulnerability for every finding. Enhance your tests now.

- Repository: [KeygraphHQ/shannon](https://github.com/keygraphhq/shannon)
- Tags: internals
- Published: 2026-02-16

---

**Shannon's "No Exploit, No Report" policy eliminates false positives by requiring exploit agents to provide concrete, reproducible proof of vulnerability before any finding enters the reporting pipeline.**

The KeygraphHQ/shannon repository implements a rigorous vulnerability assessment framework that rejects traditional pattern-matching in favor of verified exploitation. By enforcing a strict "No Exploit, No Report" rule during Phase 3 of its security pipeline, Shannon ensures that only confirmed, exploitable vulnerabilities reach the final report, effectively filtering out speculative alerts.

## The Problem with Traditional Vulnerability Scanning

Traditional security scanners often rely on signature-based detection or static analysis heuristics that flag potential vulnerabilities without verification. These tools generate reports filled with theoretical findings that may not be exploitable in the target environment, forcing security teams to waste resources triaging false positives. Shannon addresses this fundamental flaw by shifting from detection to confirmation.

## How the No Exploit No Report Policy Works in Shannon

Shannon's exploitation pipeline is built around a strict "No Exploit, No Report" rule documented in the project [`README.md`](https://github.com/KeygraphHQ/shannon/blob/main/README.md). Instead of merely flagging a potential vulnerability that matches a known pattern, Shannon requires concrete, reproducible proof that the vulnerability can actually be triggered.

### Phase 3 Exploitation and Live Verification

During Phase 3, specialized exploit agents run hypothesized attacks against live targets. If an exploit succeeds, the agent calls the `save_deliverable` MCP tool, which creates an entry in the appropriate exploitation queue (e.g., [`xss_exploitation_queue.json`](https://github.com/KeygraphHQ/shannon/blob/main/xss_exploitation_queue.json)). If the exploit fails, no queue entry is written and the finding is discarded as a false positive.

### Queue Gating in queue-validation.ts

The [`src/queue-validation.ts`](https://github.com/KeygraphHQ/shannon/blob/main/src/queue-validation.ts) module enforces the reporting gate. It defines the `EXPLOITATION_QUEUES` array containing paths to queue files such as [`injection_exploitation_queue.json`](https://github.com/KeygraphHQ/shannon/blob/main/injection_exploitation_queue.json) and [`xss_exploitation_queue.json`](https://github.com/KeygraphHQ/shannon/blob/main/xss_exploitation_queue.json). During workflow execution, the validation step reads each queue and checks for entries. Only queues containing at least one successful exploit are allowed to flow to the reporting phase; empty queues are treated as "no exploitable finding" and blocked.

### Evidence-First Reporting

When a vulnerability reaches the reporting phase, it carries the exploit evidence including PoC code, screenshots, and HTTP logs. The final report contains proof-by-exploitation rather than speculative descriptions. This evidence-first approach ensures that every reported item has been demonstrated in the target environment, making it far less likely that an auditor will flag a false positive.

## Technical Implementation: From Exploit to Report

The enforcement of the "No Exploit, No Report" policy relies on specific TypeScript implementations across the Shannon codebase.

In [`src/queue-validation.ts`](https://github.com/KeygraphHQ/shannon/blob/main/src/queue-validation.ts), the system explicitly checks for non-empty queues before allowing reporting:

```typescript
// src/queue-validation.ts – only non‑empty queues advance
export const EXPLOITATION_QUEUES = [
  { name: 'injection', queue: 'injection_exploitation_queue.json' },
  { name: 'xss',       queue: 'xss_exploitation_queue.json' },
  { name: 'auth',      queue: 'auth_exploitation_queue.json' },
  { name: 'ssrf',      queue: 'ssrf_exploitation_queue.json' },
  { name: 'authz',     queue: 'authz_exploitation_queue.json' },
];

// During workflow execution:
for (const q of EXPLOITATION_QUEUES) {
  const entries = await readJson(q.queue);
  if (entries.length === 0) {
    logger.info(`${q.name} exploitation queue empty → nothing to report`);
    continue;            // skips report generation for this vector
  }
  // otherwise, pass to reporting phase
}

```

Exploit agents use the `save-deliverable` tool to write evidence only upon successful exploitation, as implemented in [`src/mcp-server/src/tools/save-deliverable.ts`](https://github.com/KeygraphHQ/shannon/blob/main/src/mcp-server/src/tools/save-deliverable.ts):

```typescript
// Example of an exploit agent writing evidence only on success
if (exploitSucceeded) {
  await mcpHelper.saveDeliverable({
    deliverable_type: 'XSS_EVIDENCE',
    content: `# XSS Exploitation Evidence\n\n**Payload:** ${payload}\n**Result:** ${result}`,

  });
  // The helper automatically appends an entry to `xss_exploitation_queue.json`
}

```

The workflow orchestration in [`src/temporal/workflows.ts`](https://github.com/KeygraphHQ/shannon/blob/main/src/temporal/workflows.ts) ensures the strict sequence: exploitation activities run first, results are written to `*_exploitation_queue.json`, and reporting activities read those files only when they contain entries.

## Summary

Shannon's "No Exploit, No Report" policy eliminates false positives through a rigorous verification pipeline:

- **Live verification**: Exploit agents must successfully trigger vulnerabilities against live targets before any finding is recorded.
- **Queue gating**: The [`queue-validation.ts`](https://github.com/KeygraphHQ/shannon/blob/main/queue-validation.ts) module blocks reporting for empty exploitation queues, ensuring only verified findings reach the report.
- **Evidence-first output**: Every reported vulnerability includes concrete proof-of-concept evidence, replacing speculative alerts with demonstrated exploits.

By wiring exploitation evidence directly into the reporting gate, Shannon guarantees that final pentest reports contain only confirmed, exploitable vulnerabilities.

## Frequently Asked Questions

### What happens if an exploit agent fails to trigger a vulnerability?

If an exploit agent fails to trigger the vulnerability, no entry is written to the exploitation queue. The `save_deliverable` tool is only invoked upon successful exploitation, meaning the finding is automatically discarded as a false positive and never reaches the reporting phase.

### How does Shannon prevent empty exploitation queues from generating reports?

The [`src/queue-validation.ts`](https://github.com/KeygraphHQ/shannon/blob/main/src/queue-validation.ts) module explicitly checks each exploitation queue file (such as [`xss_exploitation_queue.json`](https://github.com/KeygraphHQ/shannon/blob/main/xss_exploitation_queue.json)) for entries before allowing the workflow to proceed to reporting. If a queue is empty, the validation step logs that there is nothing to report and skips report generation for that specific attack vector.

### What types of evidence does Shannon require for a finding to be reportable?

Shannon requires concrete, reproducible proof that a vulnerability can be triggered in the live target environment. This evidence typically includes proof-of-concept code, HTTP request/response logs, screenshots of successful exploitation, and detailed payload information. This evidence-first approach ensures every reported item has been demonstrated rather than merely hypothesized.

### Where is the "No Exploit, No Report" policy documented in the Shannon codebase?

The policy is explicitly documented in the project [`README.md`](https://github.com/KeygraphHQ/shannon/blob/main/README.md) under Phase 3 – Exploitation, which states that hypotheses unable to be successfully exploited are discarded as false positives. The technical enforcement occurs in [`src/queue-validation.ts`](https://github.com/KeygraphHQ/shannon/blob/main/src/queue-validation.ts), [`src/temporal/workflows.ts`](https://github.com/KeygraphHQ/shannon/blob/main/src/temporal/workflows.ts), and [`src/mcp-server/src/tools/save-deliverable.ts`](https://github.com/KeygraphHQ/shannon/blob/main/src/mcp-server/src/tools/save-deliverable.ts).