Shannon Breakdown: The AI Pentester That Won't Report a Bug It Can't Exploit

1. At a Glance: Worth Your Time?

Rating: ★★★★☆ (4 / 5)

Why this score: it is one of the few open-source AI security agents that puts exploitation-based validation at the centre of its pipeline — read the source, map attack paths, actually attack the running app, keep only what lands. That one filter kills the single most annoying problem with AI security tooling: a report full of things that look like vulnerabilities but aren’t.

The missing star comes from two places: the AGPL-3.0 licence (not Apache-2.0 — more on this, it matters a lot for companies), and the fact that it mutates the target. You can only point it at staging, and every run burns model tokens.

Key numbers (as of 2026-09-19)

Who it’s for

One-line verdict: it serves people who have a staging environment and want reproducible conclusions — not people who want a one-click compliance report.

Building on top of it

Allowed? You can modify it, but how you use it decides. AGPL-3.0 is not Apache-2.0. Internal use, modifications, self-hosting: all fine. The moment you wrap it into a service you offer to others (SaaS, a hosted scanning platform), network interaction triggers AGPL’s source-provision obligation — your changes have to be published. That single clause decides whether it can sit inside a commercial product’s distribution chain.

How hard?

2. What It Is — and What It Isn’t

Official positioning: an autonomous AI pentester for web applications and APIs.

How that differs from the usual suspects:

• Scanners (nuclei, ZAP): signature match → “this may exist” → a human reproduces it
• Evaluation-style AI tools (Garak and friends): probe the model, output a score
• Shannon: read your source → derive attack paths → attack the live application → report only what landed

The slogan in the README is the product philosophy in four words: No exploit, no report. No reproducible PoC, no finding.

That trade has a clear cost and a clear payoff. It misses things — anything the model didn’t think of, or thought of but failed to weaponise, never reaches the report. What you get in exchange is a very low false-positive rate. If the question is “can this report go straight to engineering?”, that trade is usually worth it.

The name comes from Claude Shannon, father of information theory. The authors’ reasoning fits: pentesting is fundamentally an information problem, and every probe reduces uncertainty about the system’s state.

3. Architecture: Two Candidate Streams, One Verdict

1
2
3
4
5
6
7
8
9
10
11

Source code ──┬──► ① Recon + vulnerability analysis (against the live app)
              │                    │
              └──► ② Agentic security code analysis
                                   │
           ③ Reconciliation (merge + dedupe) ──► exploitation queue
                                   │
           ④ Exploitation agents (browser automation + CLI tools)
                                   │
           ⑤ Validation: anything not demonstrated is discarded
                                   │
           ⑥ Reporting: PDF · Markdown · JSON · SARIF 2.1.0

Stage by stage:

1. Recon and vulnerability analysis explores the running application, ties runtime behaviour back to source, and dispatches specialised agents across injection, XSS, SSRF, authentication, and authorisation.
2. Agentic security code analysis first maps the application — architecture, trust boundaries, exposed interfaces, dependencies, data flows, high-value assets — then opens targeted investigations.
3. Reconciliation merges both candidate streams, deduplicates, and builds an exploitation queue.
4. Exploitation agents attempt real proof-of-concept attacks against the running target.
5. Validation discards everything Shannon cannot demonstrate.
6. Reporting produces PDF and Markdown with evidence attached, plus JSON and SARIF for downstream systems.

Only findings with status exploited count toward CI severity gates — a code-analysis hypothesis never fails a pipeline. That design choice matters; otherwise model speculation would block releases every day.

Each scan runs in an ephemeral Docker container with an isolated workspace, and the target repository is mounted read-only.

4. What Shannon 3.0 Changed

The README carries a 3.0 announcement at the top. The substantive upgrades:

• deeper security code analysis
• more thoroughly vetted findings
• a rebuilt CLI
• native CI/CD (GitHub Action and GitLab CI component)
• professional PDF reports
• SARIF (enabled by default for exploit-mode scans)

SARIF deserves its own mention: it lets Shannon’s findings flow straight into GitHub code scanning, side by side with your other scanners, instead of living in yet another dashboard.

5. Getting Started

Prerequisites: Docker (for the worker container), Node.js 18+, and a model API key (Anthropic, OpenAI, xAI, AWS Bedrock, or a local model).

1
2
3
4
5
6
7

# Configure credentials with the interactive wizard
npx @keygraph/shannon@latest setup

# Run a pentest against a source-available target
npx @keygraph/shannon@latest start \
  -u https://your-app.com \
  -r /path/to/your/repo

It pulls the worker image, starts the local infrastructure, mounts the target repo read-only inside an ephemeral container, and writes results to a local workspace. Workspaces are resumable — an interrupted scan picks up where it stopped instead of redoing completed work.

In CI:

1
2
3
4
5
6
7

- name: Run Shannon
  uses: KeygraphHQ/shannon-action@v1
  with:
    url: https://staging.example.com
    api-key: ${{ secrets.SHANNON_AI_API_KEY }}
    fail-on-severity: high
    upload-sarif: true

Requirements: a private repository, a runner with Docker and Docker Compose v2, and network access from the runner to the target environment.

One convenience worth knowing: it supports OpenAI Codex (ChatGPT Plus/Pro) and xAI subscriptions, so you can avoid per-token API billing. Claude Code subscriptions only work up to version 1.9.0, the last release built on the Claude Agent SDK.

6. How to Judge Whether It Works

The authors published a benchmark in the repo: they ran Shannon against Photoview 2.4.0 — the same application and version Doyensec used when comparing Aikido and XBOW — and published the PDF and SARIF output for three models (DeepSeek v4 Flash, Grok 4.6, Claude Opus 5), along with methodology and limitations.

My advice: ignore the star count and read that SARIF.

• Which categories does it actually report? Do they cluster in the areas it covers well (injection, broken authorisation)?
• Is the evidence chain complete — request, response, reproduction steps?
• Run it against your own project and compare with a human pentest. That is the only way to learn its recall on your stack.

Stars measure community heat, not fitness for your system.

7. Boundaries and Risks (Don’t Skip These)

1. It really does mutate the target. Exploitation agents create users, submit forms, change application state, and trigger outbound requests. Run it only in sandbox, staging, or local dev environments with disposable data. Never against production.

2. Authorisation is a hard precondition. Only test systems you own or have explicit written authorisation to test. This isn’t boilerplate — it’s a tool that initiates attacks, and the legal line is far stricter than for a passive scanner.

3. AGPL-3.0 has real edges. Internal use is fine; offering it as a service obliges you to publish your changes. Loop in legal before an enterprise rollout.

4. Reports still need human review. The README states it plainly: LLM-generated reports can contain weakly supported or incorrect details. A passing PoC is not a conclusion.

5. Model capability sets the ceiling. When a model fails to follow instructions, scan quality drops noticeably, and providers differ substantially.

6. Coverage is bounded. It focuses on exploitable OWASP-class issues: injection, XSS, SSRF, broken authentication, broken authorisation. The open-source edition is tuned for fast, code-informed pentesting in everyday development and CI; exhaustive agentic SAST, broader scanner coverage, centralised governance, and full-lifecycle vulnerability management live in the commercial Keygraph Platform.

8. One-Line Verdict

Shannon’s edge isn’t “AI can find bugs” — it’s that it is willing to pay the cost of a real exploit for every finding, and to delete anything it can’t land. That’s what turns it from another AI scanner into a gate you can put in a pipeline.

Good fit: teams with a staging environment and an authorisation process who want security testing to run at release cadence.
Poor fit: anyone trying to replace the annual human pentest (the project’s own framing is shifting pentesting left, not replacing experts), or anyone planning to integrate it into a closed-source commercial product — AGPL is in the way.

This is the deep-dive companion to Scanners-Box Daily AI Tool Picks.