An agent that must be allowed to break things
Shannon combines two views that security tools often keep separate. It reads the target application's source to map routes, data flow, authentication, and likely attack surfaces, then explores a running copy through browser automation and command-line tools. Specialized agents investigate injection, cross-site scripting, server-side request forgery, authentication, and authorization. Exploitation agents attempt a working proof, and a reporting stage turns the evidence into Markdown.
That source-guided loop is the reason to try Shannon. A conventional static warning can identify dangerous code without showing whether input can reach it. A black-box scanner can observe the application without understanding an unusual internal path. Shannon uses code to aim the live test, then tries to demonstrate impact. For a developer, a reproducible request and response is usually more actionable than another possible-severity alert.
This is not a passive audit. The agent can register users, submit forms, alter or delete data, compromise test accounts, trigger outbound requests, and leave exploit artifacts. Keygraph explicitly says not to run it on production. The right target is a disposable local or staging deployment with fake data, isolated credentials, outbound controls, and written authorization. A disposable virtual machine provides the safest boundary.
The quick start is only the mechanical part
Installation starts cleanly. Node.js 18 or newer runs the published npx package, Docker hosts the worker and local infrastructure, an interactive setup stores provider choices, and one command takes the target URL plus repository path. The source tree is mounted read-only in an ephemeral worker, and results stay in a local workspace. macOS and Linux use Docker directly; Windows is supported through WSL2 rather than native shells.
A real test needs more design. The container must reach the application, so a host-local service uses host.docker.internal rather than localhost. Authenticated testing requires a configuration file describing the login URL, test credentials, and browser flow. Rules can exclude paths, cap login attempts or request rates, restrict vulnerability classes, and filter the final report. Writing these limits is part of safe setup, not optional tuning after the first scan.
Model access adds another dependency. The open-source edition needs credentials for Anthropic, OpenAI, xAI, AWS Bedrock, or another compatible provider, with Claude recommended and officially supported. Provider safeguards for cyber workloads can interrupt a legitimate test unless the account has been cleared. Version 2.4.0 adds Codex subscription authentication, while the current README directs Claude Code subscription users to the older 1.9.0 release. Local orchestration therefore does not mean the whole analysis is local. Review where source context and findings travel under the selected provider and gateway.
The project estimates a full run at roughly 1 to 1.5 hours. Cost varies with the model, target, and concurrency. Resume support prevents completed agents from repeating after an interruption, but teams should still cap spending and test a small scope before turning every vulnerability class loose.
Proof reduces noise, not the need for review
Shannon's headline rule is that only vulnerabilities with working proofs reach the report. This is a strong answer to the false-positive problem in AI security tools, but it is not an absolute guarantee. The safety guide says reports can contain weakly supported or incorrect details and require human review.
A current issue identifies a concrete mismatch. The supplied Juice Shop report includes a clearly labeled section for confirmed findings without successful exploits, including configuration observations, and mentions other unexploited possibilities in its summary. The reporter's point is narrow: the evidence is labeled, but the final artifact does not fully match the README's categorical promise. Until that boundary is fixed or reworded, reviewers should check that each claimed exploited finding includes the actual proof and keep informational observations separate.
Human review also has to judge safety and business context. An agent may prove that one test user can access another test user's record, yet only the application owner can determine affected roles, real data exposure, and the correct remediation. Conversely, Shannon can miss a logic flaw outside its modeled classes. A clean report is evidence from one method, not a security certificate.
The open edition has a deliberate boundary
Shannon Open Source covers five high-value web vulnerability families and produces a local report. It does not aim to replace software-composition analysis, secrets detection, infrastructure checks, broad configuration review, dashboards, ownership workflows, or automatic remediation. The README places those capabilities in the commercial Keygraph platform, along with continuous operation, enhanced black-box and grey-box testing, fix pull requests, and enterprise deployment.
This division is refreshingly explicit. Use the open edition when you want the proof engine and can manage the surrounding workflow yourself. Do not choose it expecting a free version of a complete application-security platform. AGPLv3 also matters to organizations embedding or modifying the service, and Keygraph offers separate commercial licensing. The repository currently welcomes issues but says it is not accepting external code contributions, which limits how directly the large user community can land fixes.
Active enough to test, young enough to supervise
The last push was August 12, 2026, version 2.4.0 arrived on August 10, and recent issue and pull-request activity covers providers, resume safety, reporting, and deployment. The open count of 31 combines issues and pull requests, so it is a small active queue rather than 31 verified defects. Tens of thousands of stars show exceptional interest, though popularity does not establish pentest accuracy.
Shannon earns a trial because it attacks with source context and demands evidence. Run it against an intentionally vulnerable application first, inspect its traffic and reports, then compare it with ZAP, Nuclei, static analysis, and a human review. It can find valuable flaws, but only a disciplined operator can keep an autonomous pentester useful and contained.