Shannon: An Autonomous White-Box Pentester That Exploits Your Code Before You Ship

The Gap Shannon Fills

Most teams run a penetration test once a year, if that. In between, code ships continuously. Shannon exists to close that gap by turning penetration testing into an on-demand, automated step that can run against every build or release. It is built for developers and security engineers who want to catch vulnerabilities before they reach production. The key word is 'prove'. Shannon does not produce a list of speculative warnings. It produces reports that include a working proof-of-concept for each finding. That is a different standard from most scanners, which flag potential issues and leave the confirmation to a human.

How It Works: Source Analysis Plus Live Exploitation

Shannon combines white-box analysis with dynamic testing. It reads your web application's source code to identify attack vectors, then uses browser automation and command-line tools to execute real exploits against the running application and its APIs. The documentation calls this 'proof-by-exploitation'. Only vulnerabilities with a working proof-of-concept are included in the final report. The architecture is visible in the quick start. Shannon pulls a worker image from Docker Hub, starts local infrastructure, mounts the target repository read-only inside an ephemeral worker container, and writes results to a local workspace. That read-only mount is a deliberate safety boundary. The agent can read your code and attack the running app, but it cannot modify the source it is analyzing.

Getting It Running: Commands and Configuration

The quick start is straightforward. You need Docker for the worker container, Node.js 18 or newer, and credentials for an AI provider. Shannon supports Anthropic, OpenAI, xAI, AWS Bedrock, and any endpoint that speaks the Anthropic Messages API or the OpenAI Chat Completions or Responses API through a custom base URL. You bring your own key, and Keygraph never proxies your model traffic. The setup command is an interactive wizard: 'npx @keygraph/shannon setup'. Then you start a scan with 'npx @keygraph/shannon start -u https://your-app.com -r /path/to/your-repo'. The '-u' flag points at the live target, and the '-r' flag points at the source repository. The README notes that configuration files can describe login flows, test credentials, TOTP, email-based login flows, focus areas, and rules. That makes authenticated testing possible, which is often where real vulnerabilities hide.

The Safety Warning Is Not Decorative

The README contains a warning in capital letters: Shannon actively executes exploits. Run it only against applications and environments you own or have explicit written authorization to test. Do not run Shannon against production systems. This is not boilerplate. The agent is designed to launch real attacks, including command injection, SQL injection, and authentication bypass, as shown in the sample reports. If pointed at the wrong target, it will cause damage. The read-only source mount limits what it can do to your code, but it does nothing to limit what it does to the running application. The other safety layer is external. Anthropic and OpenAI apply real-time safeguards to cyber-security workloads, which can interrupt a scan mid-run. The README tells you to complete their guidance for legitimate security testers before your first run. That is a practical hurdle you must plan for, not a footnote.

Limitations and Wrong Use Cases

Shannon is not a black-box scanner. It needs source code to work. If you only have a URL and no repository, this tool is the wrong choice. The white-box approach also means the quality of the analysis depends on the quality of your source checkout. A partial or obfuscated repository will produce weaker attack planning. Another limitation is provider dependency. Shannon runs on AI models from Anthropic, OpenAI, xAI, or Bedrock. If your provider blocks cyber workloads, or if their safeguards interrupt a scan, you get nothing. The README explicitly notes that Claude Code subscriptions are not supported in the latest version, and that version 1.9.0 is the final release built on the Claude Agent SDK. That is a concrete compatibility boundary. Finally, the sample reports show 15 to 20+ findings on intentionally vulnerable apps. Do not expect that density on a hardened codebase. Real applications will produce fewer, but more valuable, proofs.

Editions and the Commercial Platform

Shannon is the agent. This repository is Shannon Open Source, the standalone pentester you run yourself. The same Shannon also powers the Keygraph platform, Keygraph's commercial pentesting product. The README points to an Editions section for comparison, but that section is not included in the cleaned text. What is clear is that the open-source version is a full agent, not a demo. It runs locally from your command line. The commercial platform likely adds managed infrastructure, reporting, or integration, but I cannot confirm the specifics from the README. What matters for adoption is that the open-source version is self-contained. You bring the Docker, the Node.js, the AI key, and the target. Keygraph provides the agent and the worker image.

Maintenance, License, and Upgrade Cost

The repository is licensed under AGPL-3.0. That is a strong copyleft license. If you modify Shannon and distribute it, you must release your changes under the same license. For internal use, the license has no practical cost, but if you build a product around Shannon, you need to understand the obligations. The project is actively maintained. The last push was August 28, 2026, with version 2.7.0 released the same day. Two earlier releases, v2.6.0 and v2.5.4, came in the same week. That pace means you will see frequent updates. The upgrade cost is low because the tool is a CLI. You re-run npx and get the latest version. But the worker image must also be updated, and your AI provider configuration may change. The README notes that version 1.9.0 is tied to the Claude Agent SDK, which suggests that major version changes can break provider compatibility. Check the release notes before upgrading.

Alternatives and the Real Difference

The obvious alternative is a traditional dynamic application security testing tool, such as OWASP ZAP or Burp Suite. Those tools scan a running web app by sending requests and analyzing responses. They do not read source code. Shannon's approach is different: it uses source analysis to guide dynamic testing and focus on realistic attack paths. That is the white-box advantage. It can find logic flaws that a black-box scanner would miss, because it knows the code paths. But ZAP and Burp are mature, have no AI provider dependency, and do not require you to clear cyber safeguards with a third party. They also do not produce proof-of-concept exploits automatically. Shannon trades that maturity and independence for the ability to prove a vulnerability end to end. If your team already uses a DAST tool and finds it sufficient, Shannon is an addition, not a replacement. If you need a report that says 'this exploit works', Shannon is the closer.

Editorial conclusion

Adopt Shannon if you own the target, can provide a clean source checkout, and have cleared cyber safeguards with your AI provider. Do not use it against production or anything you lack written authorization to test. Before your first scan, verify your provider's policy on cyber workloads, confirm Docker is available, and run the setup wizard to configure credentials. Shannon is a real exploitation tool, not a scanner. Its value depends on the quality of your source and the honesty of its proof-of-concept reports. If you need a traditional DAST tool with no source access, look elsewhere. If you want to prove vulnerabilities before release, Shannon is a concrete, direct answer.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes