` to copy deliverables to a custom output directory after the run completes.
-
-Output structure:
-
-```text
-workspaces/{hostname}_{sessionId}/
-├── session.json # Metrics and session data
-├── workflow.log # Human-readable workflow log
-├── agents/ # Per-agent execution logs
-├── prompts/ # Prompt snapshots for reproducibility
-└── deliverables/
- └── comprehensive_security_assessment_report.md # Final comprehensive security report
-```
-
----
-
-## Sample Reports
-
-Sample penetration test reports from industry-standard vulnerable applications:
-
-#### **OWASP Juice Shop** • [GitHub](https://github.com/juice-shop/juice-shop)
-
-*A notoriously insecure web application maintained by OWASP, designed to test a tool's ability to uncover a wide range of modern vulnerabilities.*
-
-**Results**: Identified over 20 vulnerabilities across targeted OWASP categories in a single automated run.
-
-**Notable findings**:
-
-- Authentication bypass and full user database exfiltration via SQL injection
-- Privilege escalation to administrator through registration workflow bypass
-- IDOR vulnerabilities enabling access to other users' data and shopping carts
-- SSRF enabling internal network reconnaissance
-
-[View Complete Report →](sample-reports/shannon-report-juice-shop.md)
-
----
-
-#### **c{api}tal API** • [GitHub](https://github.com/Checkmarx/capital)
-
-*An intentionally vulnerable API from Checkmarx, designed to test a tool's ability to uncover the OWASP API Security Top 10.*
-
-**Results**: Identified approximately 15 critical and high-severity vulnerabilities.
-
-**Notable findings**:
-
-- Root-level command injection via denylist bypass in a hidden debug endpoint
-- Authentication bypass through a legacy, unpatched v1 API endpoint
-- Privilege escalation via Mass Assignment in the user profile update function
-- Zero false positives for XSS (correctly confirmed robust XSS defenses)
-
-[View Complete Report →](sample-reports/shannon-report-capital-api.md)
-
----
-
-#### **OWASP crAPI** • [GitHub](https://github.com/OWASP/crAPI)
-
-*A modern, intentionally vulnerable API from OWASP, designed to benchmark a tool's effectiveness against the OWASP API Security Top 10.*
-
-**Results**: Identified over 15 critical and high-severity vulnerabilities.
-
-**Notable findings**:
-
-- Authentication bypass via multiple JWT attacks (Algorithm Confusion, alg:none, weak key injection)
-- Full PostgreSQL database compromise via injection, exfiltrating user credentials
-- SSRF attack forwarding internal authentication tokens to an external service
-- Zero false positives for XSS (correctly identified robust XSS defenses)
-
-[View Complete Report →](sample-reports/shannon-report-crapi.md)
-
----
-
-## Benchmark
-
-Shannon Lite scored **96.15% (100/104 exploits)** on a hint-free, source-aware variant of the XBOW security benchmark.
-
-**[Full results with detailed agent logs and per-challenge pentest reports →](https://github.com/KeygraphHQ/xbow-validation-benchmarks/blob/main/xben-benchmark-results/)**
-
----
+Learn more on the [Keygraph website](https://keygraph.io), read the [Shannon Pro technical overview](docs/shannon-pro.md), start a free trial or book a [Shannon Pro demo](https://cal.com/team/keygraph/shannon-pro), or contact [shannon@keygraph.io](mailto:shannon@keygraph.io).
## Architecture
-Shannon uses a multi-agent architecture that combines white-box source code analysis with dynamic exploitation across five phases:
+Shannon Lite uses a multi-agent workflow that combines source-code analysis with live exploitation:
-```
+```text
┌──────────────────────┐
│ Pre-Reconnaissance │
│ (source code scan) │
@@ -812,145 +176,75 @@ Shannon uses a multi-agent architecture that combines white-box source code anal
└──────────────────────┘
```
-### Architectural Overview
+At a high level:
-Shannon uses Anthropic's Claude Agent SDK as its reasoning engine within a multi-agent architecture. The system combines white-box source code analysis with black-box dynamic exploitation, managed by an orchestrator across five phases. The architecture is designed for minimal false positives through a "no exploit, no report" policy.
+- **Pre-reconnaissance** identifies frameworks, entry points, data flows, and likely attack surfaces from the repository.
+- **Reconnaissance** explores the live application and correlates runtime behavior with code-level context.
+- **Vulnerability analysis** runs specialized agents for Injection, XSS, SSRF, Authentication, and Authorization.
+- **Exploitation** attempts real proof-of-concept attacks and discards hypotheses that cannot be proven.
+- **Reporting** compiles validated findings, evidence, and remediation guidance into a final Markdown report.
-Each scan runs in its own ephemeral Docker container (`docker run --rm`) with a per-invocation Temporal task queue, enabling concurrent scans with different target repositories.
+Each scan runs in an ephemeral Docker container with an isolated workspace and per-invocation orchestration.
----
+## Documentation
-#### **Phase 1: Pre-Reconnaissance**
+Use these guides for operational detail:
-Performs source code analysis to identify the application framework, entry points, and potential attack surface from the codebase. Builds the foundational architectural intelligence that all subsequent agents depend on.
+| Guide | Use it for |
+| --- | --- |
+| [Source build and CLI commands](docs/development.md) | Cloning, building, common commands, output paths, and local development. |
+| [Configuration](docs/configuration.md) | Authenticated testing, login flows, rules of engagement, report filters, and rate-limit settings. |
+| [AI providers](docs/ai-providers.md) | Anthropic, AWS Bedrock, Google Vertex AI, and custom Anthropic-compatible endpoints. |
+| [Platforms and networking](docs/platforms.md) | Windows/WSL2, Linux, macOS, Docker networking, local apps, and custom hostnames. |
+| [Workspaces and resuming](docs/workspaces.md) | Naming workspaces, resuming interrupted scans, and workspace storage. |
+| [Safety and limitations](docs/safety.md) | Authorized-use requirements, non-production guidance, mutative effects, cost, and model caveats. |
+| [Coverage and roadmap](docs/coverage-roadmap.md) | Current vulnerability coverage and planned work. |
+| [Shannon Pro](docs/shannon-pro.md) | Commercial platform, black-box and white-box pentesting, full lifecycle workflows, and enterprise deployment. |
-#### **Phase 2: Reconnaissance**
+## Safety, Scope, and Limitations
-Builds a comprehensive attack surface map from the pre-recon findings. Shannon performs live application exploration via browser automation to correlate code-level insights with real-world behavior, producing a detailed map of all entry points, API endpoints, and authentication mechanisms.
+Shannon Lite is not a passive scanner. Its exploitation agents can create users, submit forms, mutate application state, trigger outbound requests, and otherwise affect the target system. Use sandboxed, staging, or local development environments with disposable data.
-#### **Phase 3: Vulnerability Analysis**
+You are responsible for using Shannon Lite legally and ethically. Do not point Shannon Lite at systems, repositories, or applications you do not own or do not have explicit authorization to test.
-To maximize efficiency, this phase operates in parallel with 5 concurrent agents. Using the reconnaissance data, specialized agents for each OWASP category (injection, XSS, auth, authz, SSRF) hunt for potential flaws in parallel. For vulnerabilities like Injection and SSRF, agents perform a structured data flow analysis, tracing user input to dangerous sinks. This phase produces a key deliverable: a list of **hypothesized exploitable paths** that are passed on for validation.
+Important limitations:
-#### **Phase 4: Exploitation**
+- Shannon Lite focuses on actively exploitable issues such as Injection, XSS, SSRF, Broken Authentication, and Broken Authorization. Broader static-analysis findings, including vulnerable dependencies and insecure configurations, are a core focus of Shannon Pro.
+- Findings still require human review. LLM-generated reports can contain weakly supported or incorrect details.
+- Shannon Lite is officially supported with Claude models. Smaller, alternative, or proxied non-Claude models may be incomplete or unstable.
+- A full run can take roughly 1 to 1.5 hours and may incur LLM API costs depending on model pricing and application complexity.
+- Do not scan untrusted or adversarial codebases; AI-powered tools that read source code can be exposed to prompt injection.
-Continuing the parallel workflow to maintain speed, this phase is dedicated entirely to turning hypotheses into proof. Dedicated exploit agents receive the hypothesized paths and attempt to execute real-world attacks using browser automation, command-line tools, and custom scripts. This phase enforces a strict **"No Exploit, No Report"** policy: if a hypothesis cannot be successfully exploited to demonstrate impact, it is discarded as a false positive.
+Read the full [Safety and limitations](docs/safety.md) guide before running Shannon Lite in a new environment.
-#### **Phase 5: Reporting**
+## License and Enterprise Licensing
-The final phase compiles all validated findings into a professional, actionable report. An agent consolidates the reconnaissance data and the successful exploit evidence, cleaning up any noise or hallucinated artifacts. Only verified vulnerabilities are included, complete with **reproducible, copy-and-paste Proof-of-Concepts**, delivering a final pentest-grade report focused exclusively on proven risks.
+Shannon Lite is licensed under the [GNU Affero General Public License v3.0](LICENSE).
+Commercial and enterprise licensing is available for organizations that need different license terms, commercial support, private redistribution, managed-service use, or broader deployment options.
-## Coverage and Roadmap
+For commercial licensing, contact [shannon@keygraph.io](mailto:shannon@keygraph.io).
-For detailed information about Shannon's security testing coverage and development roadmap, see our [Coverage and Roadmap](./COVERAGE.md) documentation.
+## Community and Support
-## Disclaimers
+**Community office hours** are available for hands-on help with bugs, deployments, and configuration questions.
-### Important Usage Guidelines & Disclaimers
+- US/EU: Thursday, 10:00 AM PT
+- Asia: Thursday, 2:00 PM IST
+- [Book a slot](https://cal.com/george-flores-keygraph/shannon-community-office-hours)
-Please review the following guidelines carefully before using Shannon (Lite). As a user, you are responsible for your actions and assume all liability.
+[Join Discord](https://discord.gg/cmctpMBXwE) to ask questions, share feedback, and connect with other Shannon Lite users.
-#### **1. Potential for Mutative Effects & Environment Selection**
+At this time, Keygraph is not accepting external code contributions. Issues are welcome for bug reports and feature requests:
-This is not a passive scanner. The exploitation agents are designed to **actively execute attacks** to confirm vulnerabilities. This process can have mutative effects on the target application and its data.
+- [Report bugs](https://github.com/KeygraphHQ/shannon/issues)
+- [Suggest features](https://github.com/KeygraphHQ/shannon/discussions)
-> [!WARNING]
-> **DO NOT run Shannon on production environments.**
->
-> - It is intended exclusively for use on sandboxed, staging, or local development environments where data integrity is not a concern.
-> - Potential mutative effects include, but are not limited to: creating new users, modifying or deleting data, compromising test accounts, and triggering unintended side effects from injection attacks.
-> - **For maximum security and isolation, run Shannon inside a virtual machine (VM).** This confines any side effects from exploitation — including unexpected outbound traffic, file writes from agent tooling, or interactions with local services — to a disposable environment.
+Stay connected:
-#### **2. Legal & Ethical Use**
-
-Shannon is designed for legitimate security auditing purposes only.
-
-> [!CAUTION]
-> **You must have explicit, written authorization** from the owner of the target system before running Shannon.
->
-> Unauthorized scanning and exploitation of systems you do not own is illegal and can be prosecuted under laws such as the Computer Fraud and Abuse Act (CFAA). Keygraph is not responsible for any misuse of Shannon.
-
-#### **3. LLM & Automation Caveats**
-
-- **Verification is Required**: While significant engineering has gone into our "proof-by-exploitation" methodology to eliminate false positives, the underlying LLMs can still generate hallucinated or weakly-supported content in the final report. **Human oversight is essential** to validate the legitimacy and severity of all reported findings.
-- **Model Support**: Shannon is officially supported only with **Claude models**. Our evaluations, internal testing, and agent harness are all optimized for Claude. Smaller or alternative models — including non-Claude models routed through a proxy — may not reliably follow Shannon's instructions or tool-use constraints, and are not officially supported.
-- **Comprehensiveness**: The analysis in Shannon Lite may not be exhaustive due to the inherent limitations of LLM context windows. For a more comprehensive, graph-based analysis of your entire codebase, **Shannon Pro** leverages its advanced data flow analysis engine to ensure deeper and more thorough coverage.
-
-#### **4. Scope of Analysis**
-
-- **Targeted Vulnerabilities**: The current version of Shannon Lite specifically targets the following classes of *exploitable* vulnerabilities:
- - Broken Authentication & Authorization
- - Injection
- - Cross-Site Scripting (XSS)
- - Server-Side Request Forgery (SSRF)
-- **What Shannon Lite Does Not Cover**: This list is not exhaustive of all potential security risks. Shannon Lite's "proof-by-exploitation" model means it will not report on issues it cannot actively exploit, such as vulnerable third-party libraries or insecure configurations. These types of deep static-analysis findings are a core focus of the advanced analysis engine in **Shannon Pro**.
-
-#### **5. Cost & Performance**
-
-- **Time**: As of the current version, a full test run typically takes **1 to 1.5 hours** to complete.
-- **Cost**: Running the full test using Anthropic's Claude 4.5 Sonnet model may incur costs of approximately **$50 USD**. Costs vary based on model pricing and application complexity.
-
-#### **6. Windows Antivirus False Positives**
-
-Windows Defender may flag files in `xben-benchmark-results/` or `deliverables/` as malware. These are false positives caused by exploit code in the reports. Add an exclusion for the Shannon directory in Windows Defender, or use Docker/WSL2.
-
-#### **7. Security Considerations**
-
-Shannon Lite is designed for scanning repositories and applications you own or have explicit permission to test. Do not point it at untrusted or adversarial codebases. Like any AI-powered tool that reads source code, Shannon Lite is susceptible to prompt injection from content in the scanned repository.
-
-
-## License
-
-Shannon Lite is released under the [GNU Affero General Public License v3.0 (AGPL-3.0)](LICENSE).
-
-Shannon is open source (AGPL v3). This license allows you to:
-- Use it freely for all internal security testing.
-- Modify the code privately for internal use without sharing your changes.
-
-The AGPL's sharing requirements primarily apply to organizations offering Shannon as a public or managed service (such as a SaaS platform). In those specific cases, any modifications made to the core software must be open-sourced.
-
-
-## Community & Support
-
-### Community Resources
-
-**1:1 Office Hours** — Thursdays, two time zones
-Book a free 15-min session for hands-on help with bugs, deployments, or config questions.
-→ US/EU: 10:00 AM PT | Asia: 2:00 PM IST
-→ [Book a slot](https://cal.com/george-flores-keygraph/shannon-community-office-hours)
-
-[Join our Discord](https://discord.gg/cmctpMBXwE) to ask questions, share feedback, and connect with other Shannon users.
-
-**Contributing:** At this time, we're not accepting external code contributions (PRs).
-Issues are welcome for bug reports and feature requests.
-
-- **Report bugs** via [GitHub Issues](https://github.com/KeygraphHQ/shannon/issues)
-- **Suggest features** in [Discussions](https://github.com/KeygraphHQ/shannon/discussions)
-
-### Stay Connected
-
-- **Twitter**: [@KeygraphHQ](https://twitter.com/KeygraphHQ)
-- **LinkedIn**: [Keygraph](https://linkedin.com/company/keygraph)
-- **Website**: [keygraph.io](https://keygraph.io)
-
-
-
-## Get in Touch
-
-### Shannon Pro
-
-Shannon Pro is Keygraph's all-in-one AppSec platform. For organizations that need unified SAST, SCA, and autonomous pentesting with static-dynamic correlation, CI/CD integration, or self-hosted deployment, see the [Shannon Pro technical overview](./SHANNON-PRO.md).
-
-
-
- 
-
-
-
-**Email**: [shannon@keygraph.io](mailto:shannon@keygraph.io)
-
----
+- [Keygraph website](https://keygraph.io)
+- [Twitter/X: @KeygraphHQ](https://twitter.com/KeygraphHQ)
+- [LinkedIn: Keygraph](https://linkedin.com/company/keygraph)
Built by Keygraph
diff --git a/SHANNON-PRO.md b/SHANNON-PRO.md
deleted file mode 100644
index 2493083..0000000
--- a/SHANNON-PRO.md
+++ /dev/null
@@ -1,255 +0,0 @@
-# Shannon Pro
-
-Shannon Pro is Keygraph's comprehensive AppSec platform, combining SAST, SCA, secrets scanning, business logic security testing, and autonomous pentesting in a single correlated workflow:
-
-- **Agentic static analysis:** CPG-based data flow, SCA with reachability, secrets detection, business logic security testing
-- **Static-dynamic correlation:** static findings are fed into the dynamic pipeline and exploited against the running application, so every reported vulnerability has a working proof-of-concept
-- **Enterprise deployment:** self-hosted runner (code and LLM calls never leave customer infrastructure), CI/CD integration, GitHub PR scanning, service boundary detection
-
-The platform cross-references static and dynamic results to eliminate false positives, prioritize by proven exploitability, and produce pentest-grade reports with reproducible proof-of-concept exploits for every finding.
-
----
-
-## The Problem: Fragmented AppSec and Alert Fatigue
-
-Modern engineering teams face two compounding security challenges. First, traditional static analysis tools (SCA, SAST, and secrets scanners) operate without context, producing high volumes of false positives that erode developer trust. Second, penetration testing remains an expensive, periodic exercise that cannot keep pace with continuous deployment. The result is a fragmented security posture where static tools cry wolf, dynamic assessments arrive too late, and engineering teams treat security as compliance theater rather than a source of genuine protection.
-
-Shannon Pro addresses both problems in a single platform by replacing pattern-based static analysis with LLM-powered reasoning and augmenting it with a fully autonomous AI pentester that validates findings at runtime. The platform supports a self-hosted runner model where source code and LLM interactions never leave the customer's infrastructure.
-
----
-
-## Platform Architecture Overview
-
-Shannon Pro operates as a two-stage pipeline: agentic static analysis of the codebase, followed by autonomous dynamic penetration testing against the running application. Findings from both stages are correlated to produce a unified, high-confidence result set.
-
----
-
-# Stage 1: Agentic Static Analysis (AppSec)
-
-The static analysis stage performs comprehensive code-level security assessment using LLM-powered agents. It comprises five core capabilities: SAST (data flow analysis, point issue detection, and business logic security testing), SCA with reachability analysis, and secrets detection.
-
-## SAST: Data Flow Analysis
-
-Shannon Pro transforms the target codebase into a Code Property Graph (CPG) that combines the abstract syntax tree, control flow graph, and program dependence graph into a unified structure. Nodes represent program constructs (such as expressions, statements, and declarations), and edges capture syntactic, control-flow, and data-dependence relationships. The analysis proceeds in three phases.
-
-### Phase 1: Source and Sink Extraction
-
-For each vulnerability type, the system identifies sources (where untrusted data enters, such as user input, API requests, and file reads) and sinks (where that data could cause harm, such as SQL queries, command execution, and file writes). Deterministic pattern matching establishes a baseline, then an AI agent analyzes the codebase to discover sources and sinks that generic patterns miss, including custom input handlers and framework-specific patterns unique to the target codebase. A filtering agent removes irrelevant results such as test fixtures and mock data.
-
-### Phase 2: Path Tracing with Contextual Reasoning
-
-This is where Shannon Pro's approach differs fundamentally from traditional SAST. The system traces backward from each sink toward potential sources. At every node along the path, an LLM analyzes whether sanitization is applied at that exact point and whether that sanitization is sufficient for this specific vulnerability in this specific context.
-
-The key insight is that security fixes are context-dependent. A function that makes data safe for one SQL query might not protect a different query. A custom sanitizer that a team wrote will not be recognized by pattern-based tools. Traditional tools rely on a hard-coded list of safe functions; Shannon Pro reasons about what the code is actually doing, validating whether the specific sanitization at each node actually addresses the specific risk at the specific sink.
-
-### Phase 3: Path Validation
-
-Each identified vulnerability path is validated by an autonomous Claude agent that confirms control flow correctness (is the path actually executable?) and logic correctness (is the vulnerability real or a false positive?). Agents produce confidence scores, and only validated paths proceed to reporting.
-
-## SAST: Point Issue Detection
-
-Point issues are vulnerabilities where security depends on what is happening at a single location rather than across a data flow path. The system pre-filters and organizes files, then feeds each one to an LLM to identify issues such as:
-
-- Use of weak encryption algorithms
-- Hardcoded credentials or API keys
-- Insecure configuration settings (e.g., debug mode enabled in production)
-- Missing security headers
-- Weak random number generation
-- Disabled certificate validation
-- Overly permissive CORS settings
-
-## SAST: Business Logic Security Testing
-
-Traditional security testing tools cannot reason about application-specific correctness properties. Pattern-based scanners look for known vulnerability signatures; conventional fuzzers (AFL, libFuzzer) find crashes and memory errors through input mutation but operate without awareness of business semantics. Neither can determine whether a syntactically valid response actually violates the application's security model. Shannon Pro bridges this gap with automated invariant-based security testing: LLM agents that understand the business semantics of the codebase, automatically discover application-specific invariants, and generate targeted test scenarios that verify whether those invariants hold under adversarial conditions. This approach draws from property-based testing methodology, applied specifically to security-relevant business logic.
-
-### Why Business Logic Bugs Are Missed
-
-Pattern-based scanners and traditional SAST are structurally incapable of finding business logic vulnerabilities. These bugs do not involve malformed input reaching a dangerous sink. Instead, they involve legitimate operations that violate unstated rules about how the application should behave. A multi-tenant SaaS platform assumes Organization A's data is never accessible to Organization B. An e-commerce application assumes a checkout total cannot go negative. A healthcare platform assumes a patient record is only visible to the assigned provider. These invariants are implicit in the business domain, never encoded in a generic vulnerability database, and invisible to any tool that does not understand what the application is supposed to do.
-
-### How It Works
-
-Shannon Pro's business logic security testing operates in four phases:
-
-**Phase 1: Invariant Discovery.** An LLM agent performs a deep semantic analysis of the codebase, examining data models, API endpoints, authorization logic, and domain-specific patterns. Rather than looking for known vulnerability signatures, the agent reasons about the application's intended behavior and derives business logic invariants: rules that must hold for the application to be secure. For a multi-tenant platform, the agent identifies invariants such as "document access must verify that the document belongs to the requesting user's organization." For a financial application, it might identify "a transfer cannot be initiated where the source and destination accounts have the same owner but different privilege levels." These are security properties that no generic scanner can know about because they are unique to each application.
-
-**Phase 2: Fuzzer Generation.** For each discovered invariant, a second agent generates a targeted fuzzer: a test scenario designed to violate the invariant. These are not random inputs. The agent reads the code, understands the expected authorization checks (or lack thereof), and constructs specific adversarial scenarios. For an authorization invariant, the fuzzer might construct a request where a user from one organization references a resource belonging to another organization. For a state machine invariant, it might craft a sequence of API calls that skips a required approval step.
-
-**Phase 3: Violation Detection.** The generated fuzzers are executed against a stubbed test environment that replicates the application's business logic with mocked dependencies. When a fuzzer succeeds, meaning the invariant does not hold, the system has identified a confirmed business logic vulnerability. The agent traces the violation back to the specific code location where the missing check or flawed logic exists.
-
-**Phase 4: Exploit Synthesis.** For every confirmed violation, the system produces a full proof-of-concept exploit with step-by-step reproduction instructions, the specific API calls or user actions required, the observed versus expected behavior, and the security impact.
-
-### Real-World Example: Cross-Tenant Data Access (CWE-639)
-
-In a production multi-tenant platform, Shannon Pro's business logic security testing discovered a critical Insecure Direct Object Reference (IDOR) vulnerability that no traditional scanner would detect.
-
-**Invariant discovered:** Document access must verify that the document belongs to the requesting user's organization.
-
-**Fuzzer generated:** The agent extracted the `GetDocument` handler logic into a stubbed test environment, mocking the database layer to return documents with known organization IDs. The fuzzer generated combinations of requesting user organizations and document owner organizations, testing whether the handler enforces organizational boundaries.
-
-**Violation confirmed:** An attacker from Organization B can access documents belonging to Organization A by calling the `GetDocument` endpoint with the victim's document ID, without any authorization check preventing cross-organization access.
-
-**Exploit synthesized:**
-
-1. Attacker authenticates as a user in Organization B and obtains valid credentials.
-2. Attacker enumerates or guesses a document ID belonging to Organization A (e.g., through sequential ID guessing, leaked references, or predictable UUID patterns).
-3. Attacker calls `GET /api/document?document_id=victim-doc-123` with their Organization B credentials.
-4. The system retrieves the document without verifying organizational ownership.
-5. The system returns HTTP 200 with the complete document contents, including sensitive data belonging to Organization A.
-
-**Impact:** Complete breach of multi-tenant data isolation. Attackers can read all documents across all organizations, potentially exposing confidential business data, PII, trade secrets, and compliance-sensitive information.
-
-**Expected behavior:** HTTP 403 Forbidden with an error message indicating access is denied, or HTTP 404 Not Found to avoid leaking document existence.
-
-This class of vulnerability, missing authorization at an organizational boundary, is invisible to pattern-based tools because the code is syntactically correct, uses no dangerous functions, and follows normal request-handling patterns. Only a system that understands the business invariant ("documents belong to organizations, and access must respect that boundary") can identify the violation.
-
-### What This Means
-
-Business logic security testing extends Shannon Pro's coverage beyond the limits of traditional static and dynamic analysis. Data flow analysis catches injection, XSS, and other input-driven vulnerabilities. Point issue detection catches configuration and cryptographic weaknesses. Business logic security testing catches the authorization failures, state machine violations, and domain-specific logic errors that represent some of the most severe and most commonly missed vulnerabilities in production applications. Together, these three capabilities provide comprehensive SAST coverage across the full vulnerability spectrum.
-
-## SCA with Reachability Analysis
-
-Traditional SCA flags any library with a known CVE regardless of whether the vulnerable function is called or even reachable. Shannon Pro goes further with a four-step reachability process:
-
-1. An AI agent researches each CVE to identify the exact vulnerable function, framework, or conditions.
-2. For framework-level issues, the system checks whether the application actually uses the affected framework in practice.
-3. For function-level issues, the CPG is queried to extract nodes where the vulnerable function is used. If no nodes are found, the vulnerability is marked as not reachable.
-4. If nodes are found, execution flow is traced from entry points (main functions, API endpoints) to determine whether a path exists. Proven executable vulnerabilities are flagged; code that uses the function but is not currently callable is marked as likely reachable.
-
-## Secrets Detection
-
-Shannon Pro combines three approaches to secrets scanning. Standard regex-based pattern matching catches known formats (AWS keys, API tokens, etc.). Simultaneously, during the point issue detection phase, LLM-based detection catches secrets that standard patterns miss, such as dynamically constructed credentials, custom credential formats, and obfuscated tokens. The LLM layer also filters out test data, placeholders, and documentation examples that regex scanners frequently flag as false positives.
-
-For discovered secrets, Shannon Pro performs liveness validation: an agent determines the API context for each credential and attempts to authenticate against the corresponding service. This distinguishes active, exploitable secrets from revoked or rotated credentials, ensuring teams focus remediation effort on secrets that represent real exposure. Liveness checks use read-only API calls (e.g., identity verification endpoints) to avoid triggering side effects or account lockouts, and in the self-hosted runner deployment, all validation occurs within the customer's network.
-
-## Boundary Analysis
-
-For large-scale or monorepo architectures, Shannon Pro's boundary analysis capability allows organizations to scope scans to specific services or portions of the codebase. An agent analyzes the repository and identifies logical boundaries (by service, frontend vs. backend, microservice, etc.). Users review, confirm, and optionally edit the detected boundaries, then select which to include in a scan. Findings are tagged by boundary, enabling clear routing to the responsible team.
-
-## False Positive Tagging
-
-Any finding can be marked as a false positive. On subsequent scans, the same finding will be flagged as likely false positive, so teams do not repeatedly triage issues they have already dismissed.
-
----
-
-# Stage 2: Autonomous Dynamic Penetration Testing
-
-Shannon Pro's dynamic testing pipeline mirrors the workflow of a professional human penetration tester, implemented as a multi-agent system powered by the Anthropic Claude Agent SDK. The system operates through five phases using 13 specialized agents.
-
-## Execution Model
-
-Phases 1 and 2 (reconnaissance) run sequentially. Phases 3 and 4 (vulnerability analysis and exploitation) run as pipelined parallel: each vulnerability/exploit pair is independent. When a vulnerability agent finishes for a given attack domain, the corresponding exploit agent starts immediately, even if other vulnerability agents are still running. Phase 5 (reporting) runs after all exploitation is complete.
-
-## Phase 1: Pre-Reconnaissance
-
-Pure static analysis of the source code without browser interaction. The pre-recon agent maps the application architecture, identifies security-relevant components (authentication systems, database access patterns, input handling), and catalogs the complete attack surface from a code perspective. Outputs include a comprehensive catalog of all network-accessible entry points, technology stack details, authentication and authorization mechanisms, and all identified sinks (XSS, SSRF, injection) with their locations.
-
-This phase informs everything downstream. If the codebase uses an ORM with parameterized queries everywhere, the injection agents know to focus elsewhere.
-
-## Phase 2: Reconnaissance
-
-Bridges static and dynamic analysis using browser automation. The recon agent correlates code findings with the live application, validating that endpoints actually exist, mapping authentication flows, inventorying input vectors (URL parameters, POST fields, headers, cookies), and documenting the real authorization architecture.
-
-## Phase 3: Vulnerability Analysis
-
-Five parallel agents, each focused on a distinct attack domain, combine code analysis with runtime probing to generate exploitation hypotheses. Each agent produces a detailed analysis deliverable and an exploitation queue -- a structured JSON file listing specific vulnerabilities to attempt, including the type, location, method, parameter, code evidence, and a suggested initial payload.
-
-The five vulnerability analysis agents and their methodologies:
-
-| Agent | Approach | What It Analyzes |
-| --- | --- | --- |
-| **Injection** | Source -> Sink taint | User input reaching SQL, command, file, template, or deserialization sinks without adequate sanitization |
-| **XSS** | Sink -> Source taint | HTML rendering contexts (innerHTML, document.write, event handlers, eval) reachable from user input without proper encoding |
-| **SSRF** | Sink -> Source taint | HTTP client libraries, raw sockets, URL openers, and headless browsers callable with user-controlled URLs |
-| **Auth** | Guard validation | Missing security controls: rate limiting, session management, token entropy, password hashing, HSTS, SSO/OAuth configuration |
-| **Authz** | Guard validation | Missing authorization checks before side effects: horizontal (ownership), vertical (role/capability), and context/workflow violations |
-
-If a vulnerability agent's exploitation queue is empty for a given attack domain, the corresponding exploit agent is skipped entirely, saving significant time and cost.
-
-## Phase 4: Exploitation
-
-Five parallel exploit agents consume the exploitation queues and attempt to verify each hypothesis using full Playwright browser automation. Agents can navigate to endpoints, fill forms with crafted payloads, submit requests, observe responses, take screenshots, and chain multiple requests together to validate complex attack sequences.
-
-**Core principle: POC or it didn't happen.** Shannon Pro never reports a vulnerability without a working proof-of-concept exploit. Exploitation agents classify each finding as EXPLOITED, POTENTIAL, or FALSE POSITIVE. Only EXPLOITED findings (with concrete evidence) make it to the final report. POTENTIAL findings are programmatically stripped before reporting, giving agents a designated space to log uncertain observations without polluting the deliverable.
-
-## Phase 5: Reporting
-
-A reporting agent synthesizes all evidence files into a pentest-grade executive report. The agent only sees confirmed findings (evidence files from Phase 4), never raw hypotheses. It de-duplicates findings, assesses severity, and provides remediation guidance. Every reported vulnerability includes reproducible steps and copy-and-paste commands for verification.
-
----
-
-# Static-Dynamic Correlation
-
-Shannon Pro's distinguishing capability is the correlation between its static and dynamic analysis stages.
-
-## How AppSec Feeds Into Dynamic Testing
-
-After static analysis completes, findings go through an enrichment phase that adds priority, confidence, and application context. CWEs are mapped to Shannon's five attack domains using a best-fit heuristic. Where a CWE maps to multiple domains (e.g., CWE-918 spans both SSRF and injection contexts), the finding is routed to the most exploitation-relevant agent. CWEs that do not map cleanly to any attack domain, such as certain business logic classes, are routed directly to the exploitation queue with their static analysis context preserved rather than forced into an ill-fitting category. Secrets, data flow findings, point issues, and business logic security testing violations are sent to Shannon's exploitation queue, where domain-specific agents attempt to exploit each finding with real proof-of-concept attacks against the running application.
-
-This correlation means that a data flow vulnerability identified in static analysis (e.g., unsanitized user input reaching a SQL query) is not just reported as a theoretical risk -- it is actively exploited against the live application. Similarly, a business logic invariant violation (e.g., missing cross-tenant authorization) identified by the security testing engine is fed directly into the Authz exploitation agent, which attempts to reproduce the exact cross-organization access scenario against the running application. Confirmed exploits are traced back to their source code location, giving developers both the proof that the vulnerability is real and the exact line of code to fix.
-
----
-
-# Key Technical Capabilities
-
-- **Fully Autonomous Operation:** Shannon Pro handles complex workflows including 2FA/TOTP logins and SSO (e.g., Sign in with Google) without human intervention. TOTP is handled via a dedicated MCP server tool.
-- **White-Box Awareness:** Unlike black-box scanners, Shannon Pro reads the source code to intelligently guide its attack strategy, combining code-level insight with runtime validation.
-- **Parallel Processing:** Vulnerability analysis and exploitation phases run concurrently across attack domains, with pipelined parallelism minimizing total execution time.
-- **Configurable Login Flows:** Authentication configuration specifies login procedures and credentials, which are interpolated into agent prompts for authenticated testing.
-
----
-
-# Container Isolation and Data Security
-
-Shannon Pro is engineered with a secure-by-design philosophy to ensure code privacy and isolation across every stage of the pipeline.
-
-## Per-Organization Infrastructure
-
-Each organization receives its own isolated compute environment. In the managed deployment, Keygraph provisions dedicated ECS infrastructure (containers, IAM roles, task queues) per organization. In the self-hosted runner deployment, the organization provisions and controls the data plane, which handles all code access and LLM calls using the organization's own API keys. The Keygraph control plane receives only aggregate findings. In either model, organizations never share compute environments with other organizations.
-
-## Ephemeral Code Handling
-
-When a scan runs, the target repository is cloned to a temporary workspace inside the isolated container. The scan executes against this local copy. Immediately after the scan completes, the entire workspace is deleted, including all cloned code. Source code is never persisted after a scan finishes. Even if a scan fails or is cancelled, a disconnected cleanup process executes regardless of how the scan terminates.
-
-In the self-hosted runner deployment, all code handling occurs within the customer's own infrastructure. Keygraph's control plane never receives, processes, or stores source code.
-
-## Encrypted Storage
-
-Code snippets associated with findings are encrypted before being written to the database. Deliverables uploaded to S3 are encrypted at rest. Each organization's data is stored in org-specific buckets with org-scoped access policies.
-
-## Network Isolation
-
-Isolated workers run in private subnets with org-specific security groups, ensuring network-level separation between customer workloads.
-
-## Self-Hosted Runner
-
-Shannon Pro supports a self-hosted runner deployment model, following the same architecture as GitHub Actions self-hosted runners. The data plane (the runner that clones code, executes scans, and makes all LLM API calls) runs entirely within the customer's infrastructure using the customer's own LLM API keys. Source code never leaves the customer's network, and no code or LLM interactions pass through Keygraph's systems. The control plane (job orchestration, scan scheduling, and the reporting UI) is hosted by Keygraph and receives only aggregate findings to power dashboards, search, and reporting. This separation ensures that Keygraph never has access to customer source code or raw LLM call content.
-
----
-
-# Deployment and Editions
-
-Shannon is offered in two editions to serve different operational needs:
-
-| Feature | Shannon Lite | Shannon Pro |
-| --- | --- | --- |
-| **Licensing** | AGPL-3.0 (open source) | Commercial |
-| **Static Analysis** | Code review prompting | Full agentic static analysis (SAST, SCA, secrets, business logic security testing) |
-| **Dynamic Testing** | Autonomous AI pentest framework | Autonomous AI pentesting with static-dynamic correlation |
-| **Analysis Engine** | Code review prompting | CPG-based data flow with LLM reasoning at every node |
-| **Business Logic** | N/A | Automated invariant discovery, test scenario generation, and exploit synthesis |
-| **Integration** | Manual / CLI | Native CI/CD, GitHub PR scanning, enterprise support, self-hosted runner |
-| **Deployment** | CLI / manual | Managed cloud or self-hosted runner (customer data plane, Keygraph control plane) |
-| **Boundary Analysis** | N/A | Automatic service boundary detection with team routing |
-| **Best For** | Local testing of own applications | Enterprise application security posture management |
-
----
-
-# Compliance Integration
-
-Within the broader Keygraph ecosystem, Shannon Pro serves as the primary engine for automated compliance evidence generation. By automating penetration testing and static analysis requirements, Shannon Pro generates real-time evidence for frameworks such as SOC 2 and HIPAA, transforming security testing from a periodic audit obligation into a continuous component of the compliance program.
-
----
-
-# Methodology Standards
-
-Shannon Pro follows AI-assisted white-box testing methodology broadly aligned with OWASP Web Security Testing Guide (WSTG) and OWASP Top 10 standards. All dynamic testing produces confirmed, exploitable findings with reproducible proof-of-concept exploits. Static analysis covers established CWE categories with LLM-powered validation to minimize false positive rates.
diff --git a/docs/ai-providers.md b/docs/ai-providers.md
new file mode 100644
index 0000000..59ce48b
--- /dev/null
+++ b/docs/ai-providers.md
@@ -0,0 +1,119 @@
+# AI Providers
+
+Shannon Lite works best with Claude models. Anthropic API keys are recommended for most users, and Shannon Lite also supports AWS Bedrock, Google Vertex AI, and custom Anthropic-compatible endpoints.
+
+## Anthropic
+
+Run the setup wizard:
+
+```bash
+npx @keygraph/shannon setup
+```
+
+Or export an API key directly:
+
+```bash
+export ANTHROPIC_API_KEY=your-api-key
+```
+
+Source-build mode can use a `.env` file:
+
+```bash
+ANTHROPIC_API_KEY=your-api-key
+CLAUDE_CODE_MAX_OUTPUT_TOKENS=64000
+```
+
+## AWS Bedrock
+
+Run `npx @keygraph/shannon setup` and select **AWS Bedrock**. The wizard prompts for region, bearer token, and model IDs.
+
+Or export environment variables directly:
+
+```bash
+export CLAUDE_CODE_USE_BEDROCK=1
+export AWS_REGION=us-east-1
+export AWS_BEARER_TOKEN_BEDROCK=your-bearer-token
+export ANTHROPIC_SMALL_MODEL=us.anthropic.claude-haiku-4-5-20251001-v1:0
+export ANTHROPIC_MEDIUM_MODEL=us.anthropic.claude-sonnet-4-6
+export ANTHROPIC_LARGE_MODEL=us.anthropic.claude-opus-4-7
+```
+
+Source-build `.env` equivalent:
+
+```bash
+CLAUDE_CODE_USE_BEDROCK=1
+AWS_REGION=us-east-1
+AWS_BEARER_TOKEN_BEDROCK=your-bearer-token
+ANTHROPIC_SMALL_MODEL=us.anthropic.claude-haiku-4-5-20251001-v1:0
+ANTHROPIC_MEDIUM_MODEL=us.anthropic.claude-sonnet-4-6
+ANTHROPIC_LARGE_MODEL=us.anthropic.claude-opus-4-7
+```
+
+Shannon Lite uses three model tiers:
+
+- **small** for summarization
+- **medium** for security analysis
+- **large** for deep reasoning
+
+Set `ANTHROPIC_SMALL_MODEL`, `ANTHROPIC_MEDIUM_MODEL`, and `ANTHROPIC_LARGE_MODEL` to Bedrock model IDs available in your region.
+
+## Google Vertex AI
+
+Create a service account with the `roles/aiplatform.user` role in the GCP Console, then download a JSON key file.
+
+Run `npx @keygraph/shannon setup` and select **Google Vertex AI**. The wizard prompts for region, project ID, service account key file path, and model IDs. The key file is copied to `~/.shannon/google-sa-key.json`.
+
+Or export environment variables directly:
+
+```bash
+export CLAUDE_CODE_USE_VERTEX=1
+export CLOUD_ML_REGION=us-east5
+export ANTHROPIC_VERTEX_PROJECT_ID=your-gcp-project-id
+export GOOGLE_APPLICATION_CREDENTIALS=/path/to/your-sa-key.json
+export ANTHROPIC_SMALL_MODEL=claude-haiku-4-5@20251001
+export ANTHROPIC_MEDIUM_MODEL=claude-sonnet-4-6
+export ANTHROPIC_LARGE_MODEL=claude-opus-4-7
+```
+
+Source-build `.env` equivalent:
+
+```bash
+CLAUDE_CODE_USE_VERTEX=1
+CLOUD_ML_REGION=us-east5
+ANTHROPIC_VERTEX_PROJECT_ID=your-gcp-project-id
+GOOGLE_APPLICATION_CREDENTIALS=./credentials/google-sa-key.json
+ANTHROPIC_SMALL_MODEL=claude-haiku-4-5@20251001
+ANTHROPIC_MEDIUM_MODEL=claude-sonnet-4-6
+ANTHROPIC_LARGE_MODEL=claude-opus-4-7
+```
+
+Set `CLOUD_ML_REGION=global` for global endpoints, or use a specific region like `us-east5`. Some models may not be available on global endpoints.
+
+## Custom Base URL
+
+Shannon Lite supports pointing the SDK at an Anthropic-compatible endpoint with `ANTHROPIC_BASE_URL`. For proxy-based routing, use an LLM proxy such as LiteLLM configured to expose an Anthropic-compatible endpoint.
+
+> [!IMPORTANT]
+> Only Claude models are officially supported. Shannon Lite's evaluations, internal testing, and agent harness are optimized for Claude. Smaller or alternative models, including non-Claude models routed through a proxy, may not reliably follow Shannon Lite's instructions or tool-use constraints. Use them at your own risk.
+
+The experimental `claude-code-router` integration is being removed. If you rely on it, migrate to an Anthropic-compatible proxy such as LiteLLM before upgrading.
+
+Run `npx @keygraph/shannon setup` and select **Custom Base URL**, or export variables directly:
+
+```bash
+export ANTHROPIC_BASE_URL=https://your-proxy.example.com
+export ANTHROPIC_AUTH_TOKEN=your-auth-token
+export ANTHROPIC_SMALL_MODEL=claude-haiku-4-5-20251001
+export ANTHROPIC_MEDIUM_MODEL=claude-sonnet-4-6
+export ANTHROPIC_LARGE_MODEL=claude-opus-4-7
+```
+
+Source-build `.env` equivalent:
+
+```bash
+ANTHROPIC_BASE_URL=https://your-proxy.example.com
+ANTHROPIC_AUTH_TOKEN=your-auth-token
+ANTHROPIC_SMALL_MODEL=claude-haiku-4-5-20251001
+ANTHROPIC_MEDIUM_MODEL=claude-sonnet-4-6
+ANTHROPIC_LARGE_MODEL=claude-opus-4-7
+```
diff --git a/docs/configuration.md b/docs/configuration.md
new file mode 100644
index 0000000..db119ff
--- /dev/null
+++ b/docs/configuration.md
@@ -0,0 +1,151 @@
+# Configuration
+
+Shannon Lite can run without a configuration file, but configuration enables authenticated testing, scope guidance, rules of engagement, report filtering, and rate-limit tuning.
+
+## Credential Precedence
+
+Source-build mode resolves credentials from:
+
+1. Environment variables, such as `export ANTHROPIC_API_KEY=...`
+2. `./.env`
+
+`npx` mode resolves credentials from:
+
+1. Environment variables
+2. `~/.shannon/config.toml`, created by `npx @keygraph/shannon setup`
+
+Environment variables always win, so you can override saved config for a single session without editing files.
+
+## Create a Configuration File
+
+Copy and modify the example configuration:
+
+```bash
+cp configs/example-config.yaml ./my-app-config.yaml
+```
+
+Run with:
+
+```bash
+npx @keygraph/shannon start -u https://example.com -r /path/to/repo -c ./my-app-config.yaml
+```
+
+Source-build equivalent:
+
+```bash
+./shannon start -u https://example.com -r /path/to/repo -c ./my-app-config.yaml
+```
+
+## Basic Configuration Structure
+
+```yaml
+# Describe your target environment.
+description: "Next.js e-commerce app on PostgreSQL. Local dev environment; .env files contain local-only credentials."
+
+# Limit which vulnerability classes run end-to-end.
+# vuln_classes: [injection, xss, auth, authz, ssrf]
+
+# Skip the exploitation phase.
+# exploit: "false"
+
+# Free-form rules of engagement.
+# rules_of_engagement: |
+# - No password brute-force; cap login attempts at 5 per account.
+# - Throttle to under 5 requests per second per endpoint; back off 60s on any 429.
+# - Use placeholders like [order_id] in deliverables; no real data values.
+
+authentication:
+ login_type: form
+ login_url: "https://your-app.com/login"
+ credentials:
+ username: "test@example.com"
+ password: "yourpassword"
+ totp_secret: "LB2E2RX7XFHSTGCK"
+
+ # Optional mailbox credentials for magic-link or email-OTP flows.
+ # email_login:
+ # address: "inbox@example.com"
+ # password: "mailbox-password"
+ # totp_secret: "JBSWY3DPEHPK3PXP"
+
+ login_flow:
+ - "Type $username into the email field"
+ - "Type $password into the password field"
+ - "Click the 'Sign In' button"
+
+ success_condition:
+ type: url_contains
+ value: "/dashboard"
+
+rules:
+ avoid:
+ - description: "AI should avoid testing logout functionality"
+ type: url_path
+ value: "/logout"
+
+ # code_path values are repo-relative file paths or globs.
+ # - description: "Out-of-scope vendored libraries"
+ # type: code_path
+ # value: "src/vendor/**"
+
+ focus:
+ - description: "AI should emphasize testing API endpoints"
+ type: url_path
+ value: "/api"
+
+# Filters applied by the report agent when assembling the final report.
+# report:
+# min_severity: low
+# min_confidence: low
+# guidance: |
+# Drop findings about missing security headers and rate-limit gaps.
+```
+
+Supported rule types include `url_path`, `subdomain`, `domain`, `method`, `header`, `parameter`, and `code_path`.
+
+## Writing Login Flow
+
+Log in once in a fresh private browser window. Write the steps in the same order you perform them:
+
+- When typing into a field, reference the field by its exact label or placeholder.
+- When clicking a button, reference the exact button text.
+
+Supported placeholders:
+
+- `$username`
+- `$password`
+- `$totp`
+- `$email_address`
+- `$email_password`
+- `$email_totp`
+
+At runtime, Shannon Lite replaces these placeholders with the credentials passed in the config.
+
+```yaml
+login_flow:
+ - "Type $username in "
+ - "Click "
+ - "Type $password in "
+ - "Click "
+ - "If prompted for 2FA, type $totp in "
+ - "Click "
+```
+
+## Adaptive Thinking
+
+Claude decides when and how deeply to reason on Opus 4.6 and 4.7. This is enabled by default whenever a tier resolves to one of these models.
+
+- `npx` mode: `npx @keygraph/shannon setup` prompts you during the wizard.
+- Source-build mode: set `CLAUDE_ADAPTIVE_THINKING=false` in `.env` or export it in your shell.
+
+## Subscription Plan Rate Limits
+
+Anthropic subscription plans reset usage on a rolling 5-hour window. The default retry strategy may exhaust retries before the window resets. Add this to your config:
+
+```yaml
+pipeline:
+ retry_preset: subscription
+ max_concurrent_pipelines: 2
+```
+
+`max_concurrent_pipelines` controls how many vulnerability pipelines run simultaneously. Supported values are 1-5, with a default of 5. Lower values reduce burst API usage but increase wall-clock time.
diff --git a/docs/coverage-roadmap.md b/docs/coverage-roadmap.md
new file mode 100644
index 0000000..4ec7a12
--- /dev/null
+++ b/docs/coverage-roadmap.md
@@ -0,0 +1,23 @@
+# Coverage and Roadmap
+
+Shannon Lite focuses on exploitable findings that can be validated against a running application.
+
+## Current Shannon Lite Coverage
+
+- Broken Authentication
+- Broken Authorization
+- Injection
+- Cross-Site Scripting
+- Server-Side Request Forgery
+
+## Reporting Philosophy
+
+Shannon Lite follows a proof-by-exploitation model. Findings that cannot be demonstrated with a working proof of concept are not included in the final report.
+
+This reduces speculative noise, but it also means Shannon Lite does not aim to report every possible security issue in a repository. In particular, many dependency, policy, configuration, and broad static-analysis findings are outside the core Shannon Lite workflow.
+
+## Roadmap Direction
+
+Planned coverage areas should continue to live in the repository's canonical roadmap document if one exists. The README should link to that document rather than carrying detailed roadmap history inline.
+
+For organizations that need broader static and organizational coverage now, see [Shannon Pro](shannon-pro.md).
diff --git a/docs/development.md b/docs/development.md
new file mode 100644
index 0000000..2106dea
--- /dev/null
+++ b/docs/development.md
@@ -0,0 +1,145 @@
+# Source Build and CLI Commands
+
+This guide covers the source-build workflow, common CLI commands, repository paths, and output locations. For the fastest first run, use the `npx` workflow in the main README.
+
+## Prerequisites
+
+- Docker
+- Node.js 18+
+- pnpm
+- AI provider credentials
+
+## Clone and Build
+
+Use the source-build workflow if you want to run Shannon Lite from a local clone, modify the open-source CLI, or keep the worker image built locally.
+
+```bash
+# 1. Clone Shannon Lite.
+git clone https://github.com/KeygraphHQ/shannon.git
+cd shannon
+
+# 2. Configure credentials.
+cp .env.example .env
+
+# 3. Install dependencies and build.
+pnpm install
+pnpm build
+
+# 4. Run a pentest.
+./shannon start -u https://your-app.com -r /path/to/your-repo
+```
+
+At minimum, your `.env` file should include one supported AI provider credential, such as:
+
+```bash
+ANTHROPIC_API_KEY=your-api-key
+CLAUDE_CODE_MAX_OUTPUT_TOKENS=64000
+```
+
+Environment variables can also be exported directly:
+
+```bash
+export ANTHROPIC_API_KEY="your-api-key"
+export CLAUDE_CODE_MAX_OUTPUT_TOKENS=64000
+```
+
+## Prepare Your Repository
+
+Shannon Lite can scan any repository on your machine. Pass an absolute or relative path with `-r`.
+
+```bash
+npx @keygraph/shannon start -u https://example.com -r /path/to/repo
+./shannon start -u https://example.com -r ./relative/path
+```
+
+The target repository is mounted read-only inside the worker container.
+
+## Common Commands
+
+Monitor progress:
+
+```bash
+npx @keygraph/shannon logs
+npx @keygraph/shannon status
+```
+
+Source-build equivalents:
+
+```bash
+./shannon logs
+./shannon status
+```
+
+Open the Temporal Web UI for detailed monitoring:
+
+```bash
+open http://localhost:8233
+```
+
+Stop Shannon Lite:
+
+```bash
+npx @keygraph/shannon stop
+npx @keygraph/shannon stop --clean
+npx @keygraph/shannon uninstall
+```
+
+Source-build equivalents:
+
+```bash
+./shannon stop
+./shannon stop --clean
+```
+
+Usage examples:
+
+```bash
+# Basic pentest.
+npx @keygraph/shannon start -u https://example.com -r /path/to/repo
+
+# With a configuration file.
+npx @keygraph/shannon start -u https://example.com -r /path/to/repo -c /path/to/my-config.yaml
+
+# Custom output directory.
+npx @keygraph/shannon start -u https://example.com -r /path/to/repo -o ./my-reports
+
+# Named workspace.
+npx @keygraph/shannon start -u https://example.com -r /path/to/repo -w q1-audit
+
+# List all workspaces.
+npx @keygraph/shannon workspaces
+```
+
+Source-build examples:
+
+```bash
+./shannon start -u https://example.com -r /path/to/repo
+./shannon start -u https://example.com -r /path/to/repo -c /path/to/my-config.yaml
+./shannon start -u https://example.com -r /path/to/repo -o ./my-reports
+./shannon start -u https://example.com -r /path/to/repo -w q1-audit
+./shannon workspaces
+
+# Rebuild the worker image.
+./shannon build --no-cache
+```
+
+## Output and Results
+
+Results are saved to the workspaces directory:
+
+- `./workspaces/` in source-build mode
+- `~/.shannon/workspaces/` in `npx` mode
+
+Use `-o ` to copy deliverables to a custom output directory after a run completes.
+
+Output structure:
+
+```text
+workspaces/{hostname}_{sessionId}/
+|-- session.json
+|-- workflow.log
+|-- agents/
+|-- prompts/
+`-- deliverables/
+ `-- comprehensive_security_assessment_report.md
+```
diff --git a/docs/platforms.md b/docs/platforms.md
new file mode 100644
index 0000000..34de73f
--- /dev/null
+++ b/docs/platforms.md
@@ -0,0 +1,84 @@
+# Platforms and Networking
+
+This guide covers platform-specific notes and Docker networking behavior.
+
+## Windows
+
+Shannon Lite on Windows is supported through WSL2. Native Windows, including Git Bash, is not supported.
+
+### Ensure WSL2
+
+```powershell
+wsl --install
+wsl --set-default-version 2
+
+# Check installed distros.
+wsl --list --verbose
+
+# If you do not have a distro, install one.
+wsl --list --online
+wsl --install Ubuntu-24.04
+
+# If your distro shows VERSION 1, convert it to WSL2.
+wsl --set-version 2
+```
+
+Install Docker Desktop on Windows and enable the WSL2 backend under **Settings > General > Use the WSL 2 based engine**.
+
+Run Shannon Lite inside WSL:
+
+```bash
+npx @keygraph/shannon setup
+npx @keygraph/shannon start -u https://your-app.com -r /path/to/your-repo
+```
+
+Source-build equivalent:
+
+```bash
+git clone https://github.com/KeygraphHQ/shannon.git
+cd shannon
+cp .env.example .env
+./shannon start -u https://your-app.com -r /path/to/your-repo
+```
+
+To access the Temporal Web UI, run `ip addr` inside WSL to find your WSL IP address, then navigate to `http://:8233` in your Windows browser.
+
+Windows Defender may flag exploit code in reports as false positives. Add an exclusion for the Shannon Lite directory or use Docker/WSL2 isolation.
+
+## Linux
+
+Linux works with native Docker. Depending on your Docker setup, you may need `sudo`. If output files have permission issues, ensure your user has access to the Docker socket and workspace directory.
+
+## macOS
+
+macOS works with Docker Desktop installed.
+
+## Testing Local Applications
+
+Docker containers cannot reach `localhost` on your host machine. Use `host.docker.internal` instead:
+
+```bash
+npx @keygraph/shannon start -u http://host.docker.internal:3000 -r /path/to/repo
+```
+
+Source-build equivalent:
+
+```bash
+./shannon start -u http://host.docker.internal:3000 -r /path/to/repo
+```
+
+## Custom Hostnames
+
+If your local stack uses custom hostnames mapped in `/etc/hosts`, Shannon Lite forwards those entries into the worker container at scan start.
+
+To disable forwarding:
+
+```bash
+export SHANNON_FORWARD_HOSTS=false
+```
+
+In source-build mode, you can also add this to `.env`:
+
+```bash
+SHANNON_FORWARD_HOSTS=false
+```
diff --git a/docs/safety.md b/docs/safety.md
new file mode 100644
index 0000000..af37ef4
--- /dev/null
+++ b/docs/safety.md
@@ -0,0 +1,52 @@
+# Safety and Limitations
+
+Read this before running Shannon Lite in a new environment.
+
+## Authorized Use Only
+
+Shannon Lite is designed for legitimate security auditing. You must have explicit written authorization from the owner of the target system before running Shannon Lite.
+
+Unauthorized scanning or exploitation of systems you do not own is illegal. Keygraph is not responsible for misuse of Shannon Lite.
+
+## Do Not Run on Production
+
+Shannon Lite is not a passive scanner. Exploitation agents actively execute attacks to confirm vulnerabilities. This can mutate application state and data.
+
+Do not run Shannon Lite against production systems. Use sandboxed, staging, or local development environments where data integrity is not a concern.
+
+Potential mutative effects include:
+
+- Creating new users
+- Modifying or deleting data
+- Compromising test accounts
+- Triggering unintended side effects from injection attacks
+- Generating unexpected outbound traffic
+- Writing exploit artifacts to reports or deliverables
+
+For maximum isolation, run Shannon Lite inside a disposable virtual machine.
+
+## LLM and Automation Caveats
+
+- **Verification is required**: Shannon Lite uses a proof-by-exploitation methodology, but final reports can still contain weakly supported or incorrect details. Human review is essential.
+- **Model support**: Shannon Lite is officially supported only with Claude models. Alternative models may be incomplete, inaccurate, or unstable.
+- **Prompt injection risk**: Do not point Shannon Lite at untrusted or adversarial codebases. AI-powered tools that read source code can be influenced by malicious repository content.
+
+## Scope of Analysis
+
+Shannon Lite currently targets exploitable vulnerabilities in these classes:
+
+- Broken Authentication
+- Broken Authorization
+- Injection
+- Cross-Site Scripting
+- Server-Side Request Forgery
+
+Shannon Lite's proof-by-exploitation model means it does not report issues it cannot actively exploit, such as many vulnerable dependency, insecure configuration, or broad policy findings.
+
+For broader coverage, Shannon Pro adds black-box and white-box agentic pentesting, graph-based static analysis, SCA reachability, secrets detection, business logic testing, remediation workflows, SLA tracking, and reporting dashboards.
+
+## Cost and Performance
+
+A full test run typically takes roughly 1 to 1.5 hours. LLM API costs vary by model pricing, target complexity, selected provider, and concurrency.
+
+If you use subscription-based model access, consider the rate-limit guidance in [Configuration](configuration.md).
diff --git a/docs/shannon-pro.md b/docs/shannon-pro.md
new file mode 100644
index 0000000..02094ad
--- /dev/null
+++ b/docs/shannon-pro.md
@@ -0,0 +1,94 @@
+# Shannon Pro
+
+Shannon Pro is Keygraph's commercial continuous pentesting and AppSec platform for teams running security across many repositories, services, and environments. While Shannon Lite is a local white-box pentesting CLI, Shannon Pro is a full platform: it combines parsed-code SAST, source-to-sink analysis, black-box and white-box agentic pentesting, verified remediation, CI/CD gating, SLA tracking, and reporting for security and compliance teams.
+
+This repository contains Shannon Lite, the AGPL-3.0 open-source CLI for strictly white-box pentesting. Shannon Pro supports both white-box and black-box agentic pentesting and adds static analysis, finding management, remediation workflows, reporting, and enterprise deployment options.
+
+## Who Should Consider Shannon Pro
+
+Shannon Pro is intended for organizations that need:
+
+- Continuous AppSec coverage across many repositories and services
+- White-box pentesting when source code is available
+- Black-box pentesting against deployed applications and APIs without source-code access
+- Agentic SAST, SCA with reachability, secrets scanning, IaC scanning, container scanning, and business logic testing
+- Canonical finding management, deduplication, ownership, status tracking, and severity tracking
+- Sync into developer workflows, including ticketing and source-control systems
+- User-initiated remediation with verification before delivery
+- SLA tracking, reporting dashboards, and compliance evidence
+- Commercial support
+- Self-hosted, air-gapped, BYOK, and customer-controlled LLM gateway deployment options
+
+## Full Vulnerability Lifecycle
+
+Shannon Pro is designed to cover the full vulnerability lifecycle, not only discovery:
+
+1. **Find** exploitable issues with white-box pentesting, black-box pentesting, SAST, SCA, secrets, IaC, container, and business logic testing.
+2. **Normalize** results into canonical findings so duplicate scanner outputs become one tracked vulnerability per repository.
+3. **Prioritize** findings using exploit evidence, reachability, severity, ownership, and business context.
+4. **Sync** work into developer workflows through ticketing and source-control integrations.
+5. **Remediate** with user-initiated patch generation when teams want help moving from evidence to code changes.
+6. **Verify** fixes by re-running the relevant scanner or exploit workflow before a remediation is delivered.
+7. **Track** ownership, status, SLAs, MTTR, and drift over time.
+8. **Report** through dashboards for risk, trends, compliance evidence, and security program operations.
+
+## Pentesting Modes
+
+Shannon Lite is strictly white-box: it requires access to the target application's source code and repository layout.
+
+Shannon Pro supports two pentesting modes:
+
+- **White-box agentic pentesting**: Agents use source-code context to understand architecture, identify realistic attack paths, and validate exploitability against the running application.
+- **Black-box agentic pentesting**: Agents test deployed applications and APIs without source-code access, useful for third-party surfaces, production-like external validation, or environments where source access is unavailable.
+
+Both modes follow the same core principle: do not report what might be vulnerable when an exploit can prove what is vulnerable.
+
+## AppSec Coverage
+
+Shannon Pro combines agentic pentesting with broader AppSec coverage:
+
+- **Agentic SAST**: Code Property Graph analysis with LLM reasoning for data flow, context, and sanitization decisions.
+- **SCA with reachability**: Dependency vulnerability analysis that prioritizes issues reachable from application entry points.
+- **Secrets scanning**: Detection and validation of credentials, tokens, and API keys.
+- **Business logic testing**: Authorization bypass, IDOR, workflow abuse, state-machine flaws, race conditions, and other application-specific logic issues.
+- **IaC scanning**: Terraform, CloudFormation, Kubernetes, Helm, and related infrastructure configuration checks.
+- **Container scanning**: Vulnerable packages, exposed secrets, and misconfigurations across image layers.
+
+## Static-Dynamic Correlation
+
+Static-dynamic correlation is a core product difference. A static finding, such as unsanitized input reaching a SQL query, is not treated as a purely theoretical issue. It is sent to an exploit agent, tested against the live application, and traced back to the exact source-code location when confirmed.
+
+The result is a finding with proof of exploitability, source context when available, ownership, status, SLA, remediation history, and reporting metadata.
+
+## Enterprise Deployment
+
+Shannon Pro supports enterprise deployment patterns for teams with strict data, model, and network requirements:
+
+- **Self-hosted deployments** inside the customer's cloud or infrastructure
+- **Air-gapped deployments** for isolated environments
+- **Strict BYOK model access** using customer-managed model credentials
+- **Customer-controlled LLM gateway patterns** for routing, policy, logging, and isolation
+- **Enterprise identity and provisioning** such as SSO and SCIM
+- **Deep integrations** with source control, ticketing, chat, registries, and cloud environments
+
+Deployments can be designed so source code, scan results, prompts, completions, and model traffic remain inside the customer's security perimeter.
+
+## Capability Comparison
+
+| Need | Shannon Lite | Shannon Pro |
+| --- | --- | --- |
+| Licensing | AGPL-3.0 | Commercial |
+| White-box pentesting | Yes; source code required | Yes; source-aware testing with platform workflows |
+| Black-box pentesting | No | Yes; autonomous testing without source-code access |
+| Code analysis / SAST | Prompting and source pass-through to guide pentesting | Actual code parsing, Code Property Graph analysis, source-to-sink path analysis, and agentic SAST |
+| AppSec coverage | OWASP-focused agentic pentesting | Agentic pentesting, SAST, SCA, secrets, IaC, containers, and business logic testing |
+| CI/CD and gating | Manual/local CLI runs | Headless commercial CLI for CI/CD gating across enterprise CI/CD platforms |
+| Finding lifecycle | Local Markdown reports | Canonical findings, deduplication, ownership, status, SLA tracking, workflow sync, and reporting dashboards |
+| Remediation | Manual | User-initiated remediation with verification before delivery |
+| Fix verification | None; manual reruns only | Targeted verification without rerunning the entire scan, completing the remediation lifecycle |
+| Enterprise deployment | Local CLI and Docker worker | Self-hosted, air-gapped, BYOK, and customer-controlled LLM gateway options |
+| Support | Community | Commercial support |
+
+## Contact
+
+Learn more on the [Keygraph website](https://keygraph.io), start a free trial, book a [Shannon Pro demo](https://cal.com/team/keygraph/shannon-pro), or contact [shannon@keygraph.io](mailto:shannon@keygraph.io).
diff --git a/docs/workspaces.md b/docs/workspaces.md
new file mode 100644
index 0000000..0d9c19f
--- /dev/null
+++ b/docs/workspaces.md
@@ -0,0 +1,50 @@
+# Workspaces and Resuming
+
+Shannon Lite uses workspaces to store scan state, logs, prompts, and deliverables. Workspaces allow interrupted or failed runs to resume without re-running completed agents.
+
+## How Workspaces Work
+
+- Every run creates a workspace.
+- Auto-named workspaces use the target hostname and a session ID, such as `example-com_shannon-1771007534808`.
+- `npx` mode stores workspaces in `~/.shannon/workspaces/`.
+- Source-build mode stores workspaces in `./workspaces/`.
+- Use `-w ` to give a run a custom name.
+- To resume a run, pass the same workspace name with `-w`.
+- Each agent's progress is checkpointed so resumed runs can skip completed work.
+
+> [!NOTE]
+> The URL must match the original workspace URL when resuming. Shannon Lite rejects mismatched URLs to prevent cross-target contamination.
+
+## Examples
+
+Start with a named workspace:
+
+```bash
+npx @keygraph/shannon start -u https://example.com -r /path/to/repo -w my-audit
+```
+
+Resume the same workspace:
+
+```bash
+npx @keygraph/shannon start -u https://example.com -r /path/to/repo -w my-audit
+```
+
+Resume an auto-named workspace:
+
+```bash
+npx @keygraph/shannon start -u https://example.com -r /path/to/repo -w example-com_shannon-1771007534808
+```
+
+List all workspaces:
+
+```bash
+npx @keygraph/shannon workspaces
+```
+
+Source-build equivalents:
+
+```bash
+./shannon start -u https://example.com -r /path/to/repo -w my-audit
+./shannon start -u https://example.com -r /path/to/repo -w example-com_shannon-1771007534808
+./shannon workspaces
+```
diff --git a/llms-full.txt b/llms-full.txt
new file mode 100644
index 0000000..1c8ca2c
--- /dev/null
+++ b/llms-full.txt
@@ -0,0 +1,1018 @@
+# Shannon Full LLM Context
+
+> Combined README and documentation for AI agents and LLMs. Generated from repository Markdown files. For the concise index, see [llms.txt](llms.txt).
+
+
+---
+
+# File: README.md
+
+>[!NOTE]
+> **[Better Steerability, Authentication Improvements, and the Migration to the Pi Harness](https://github.com/KeygraphHQ/shannon/discussions/348)**
+
+
+
+
+
+# Shannon - AI Pentester by Keygraph
+
+
+
+Shannon is an autonomous, white-box AI pentester for web applications and APIs.
+It analyzes your source code, identifies attack paths, and executes real exploits to prove vulnerabilities before they reach production.
+
+---
+
+
+
+
+---
+
+ 
+
+
+Sample Shannon Lite penetration test reports from intentionally vulnerable applications:
+
+| Target | Summary | Report |
+| --- | --- | --- |
+| OWASP Juice Shop | 20+ vulnerabilities, including authentication bypass, SQL injection, IDOR, and SSRF. | [View report](sample-reports/shannon-report-juice-shop.md) |
+| c{api}tal API | Approximately 15 critical and high-severity API findings, including command injection, auth bypass, and mass assignment. | [View report](sample-reports/shannon-report-capital-api.md) |
+| OWASP crAPI | 15+ critical and high-severity findings across JWT, injection, SSRF, and API authorization paths. | [View report](sample-reports/shannon-report-crapi.md) |
+
+## Quick Start
+
+### Prerequisites
+
+- **Docker** - required for the worker container.
+- **Node.js 18+** - required for the recommended `npx` workflow.
+- **AI provider credentials** - Anthropic is recommended; AWS Bedrock, Google Vertex AI, and compatible proxy setups are documented separately.
+
+### Run Shannon Lite
+
+> [!WARNING]
+> Shannon Lite actively executes exploits. Run it only against applications and environments you own or have explicit written authorization to test. Do not run Shannon Lite against production systems.
+
+```bash
+# Configure credentials with the interactive wizard.
+npx @keygraph/shannon setup
+
+# Run a pentest against a source-available target.
+npx @keygraph/shannon start -u https://your-app.com -r /path/to/your-repo
+```
+
+Shannon Lite pulls the worker image from Docker Hub, starts the required local infrastructure, mounts the target repository read-only inside an ephemeral worker container, and writes results to a local workspace.
+
+For source builds, authenticated scans, provider-specific setup, and platform notes, see [Documentation](#documentation).
+
+## Key Capabilities
+
+- **Proof-by-exploitation reports**: Shannon Lite reports validated findings with reproducible proof-of-concept steps instead of speculative warnings.
+- **White-box attack planning**: Shannon Lite uses source-code analysis to guide dynamic testing and focus on realistic attack paths.
+- **Autonomous execution**: Shannon Lite launches reconnaissance, vulnerability analysis, exploitation, and report generation from a single command.
+- **Authenticated testing**: Shannon Lite configuration files can describe login flows, test credentials, TOTP, email-based login flows, focus areas, and rules of engagement.
+- **OWASP-focused coverage**: Shannon Lite targets exploitable Injection, XSS, SSRF, Broken Authentication, and Broken Authorization issues.
+- **Resumable workspaces**: Shannon Lite can resume interrupted runs without re-running completed agents.
+
+## Shannon Lite and Shannon Pro
+
+This repository contains **Shannon Lite**, the AGPL-3.0 open-source CLI for strictly white-box, proof-by-exploitation testing of web applications and APIs you own or are authorized to test. Shannon Lite requires access to the target application's source code and repository layout.
+
+**Shannon Pro** is Keygraph's commercial continuous pentesting and AppSec platform for teams running security across many repositories, services, and environments. While Shannon Lite is a local white-box pentesting CLI, Shannon Pro is a full platform: it combines parsed-code SAST, source-to-sink analysis, black-box and white-box agentic pentesting, verified remediation, CI/CD gating, SLA tracking, and reporting for security and compliance teams.
+
+Shannon Pro supports both **white-box and black-box agentic pentesting**: use source-aware testing when code is available, or run autonomous black-box testing against deployed applications and APIs when source access is unavailable or unnecessary.
+
+Shannon Pro covers the full vulnerability lifecycle: finding exploitable issues, deduplicating and prioritizing them, syncing work into developer workflows, generating verified remediations, re-testing fixes, tracking SLAs, and producing dashboards for security reporting and compliance.
+
+For enterprise deployments, Shannon Pro supports self-hosted and air-gapped environments, strict bring-your-own-key model access, and customer-controlled LLM gateway patterns. Deployments can be designed so source code, scan results, prompts, completions, and model traffic remain inside your security perimeter.
+
+Shannon Lite is a strong fit for local and project-level white-box testing. Shannon Pro is intended for organizations that need continuous AppSec coverage, black-box and white-box pentesting, centralized triage, verified remediation workflows, compliance-ready reporting, enterprise integrations, and commercial support.
+
+| Need | Shannon Lite | Shannon Pro |
+| --- | --- | --- |
+| License | AGPL-3.0 | Commercial |
+| White-box pentesting | Yes; source code required | Yes; source-aware testing with platform workflows |
+| Black-box pentesting | No | Yes; autonomous testing without source-code access |
+| Code analysis / SAST | Prompting and source pass-through to guide pentesting | Actual code parsing, Code Property Graph analysis, source-to-sink path analysis, and agentic SAST |
+| AppSec coverage | OWASP-focused agentic pentesting | Agentic pentesting, SAST, SCA, secrets, IaC, containers, and business logic testing |
+| CI/CD and gating | Manual/local CLI runs | Headless commercial CLI for CI/CD gating across enterprise CI/CD platforms |
+| Finding lifecycle | Local Markdown reports | Canonical findings, deduplication, ownership, status, SLA tracking, workflow sync, and reporting dashboards |
+| Remediation | Manual | User-initiated remediation with verification before delivery |
+| Fix verification | None; manual reruns only | Targeted verification without rerunning the entire scan, completing the remediation lifecycle |
+| Enterprise deployment | Local CLI and Docker worker | Self-hosted, air-gapped, BYOK, and customer-controlled LLM gateway options |
+| Support | Community | Commercial support |
+
+Learn more on the [Keygraph website](https://keygraph.io), read the [Shannon Pro technical overview](docs/shannon-pro.md), start a free trial or book a [Shannon Pro demo](https://cal.com/team/keygraph/shannon-pro), or contact [shannon@keygraph.io](mailto:shannon@keygraph.io).
+
+## Architecture
+
+Shannon Lite uses a multi-agent workflow that combines source-code analysis with live exploitation:
+
+```text
+ ┌──────────────────────┐
+ │ Pre-Reconnaissance │
+ │ (source code scan) │
+ └──────────┬───────────┘
+ │
+ ▼
+ ┌──────────────────────┐
+ │ Reconnaissance │
+ │ (attack surface │
+ │ mapping) │
+ └──────────┬───────────┘
+ │
+ ▼
+ ┌──────────┴───────────┐
+ │ │ │
+ ▼ ▼ ▼
+ ┌───────────┐ ┌───────────┐ ┌───────────┐
+ │ Vuln │ │ Vuln │ │ ... │
+ │(Injection)│ │ (XSS) │ │ │
+ └─────┬─────┘ └─────┬─────┘ └─────┬─────┘
+ │ │ │
+ ▼ ▼ ▼
+ ┌───────────┐ ┌───────────┐ ┌───────────┐
+ │ Exploit │ │ Exploit │ │ ... │
+ │(Injection)│ │ (XSS) │ │ │
+ └─────┬─────┘ └─────┬─────┘ └─────┬─────┘
+ │ │ │
+ └──────┬───────┴─────────────┘
+ │
+ ▼
+ ┌──────────────────────┐
+ │ Reporting │
+ └──────────────────────┘
+```
+
+At a high level:
+
+- **Pre-reconnaissance** identifies frameworks, entry points, data flows, and likely attack surfaces from the repository.
+- **Reconnaissance** explores the live application and correlates runtime behavior with code-level context.
+- **Vulnerability analysis** runs specialized agents for Injection, XSS, SSRF, Authentication, and Authorization.
+- **Exploitation** attempts real proof-of-concept attacks and discards hypotheses that cannot be proven.
+- **Reporting** compiles validated findings, evidence, and remediation guidance into a final Markdown report.
+
+Each scan runs in an ephemeral Docker container with an isolated workspace and per-invocation orchestration.
+
+## Documentation
+
+Use these guides for operational detail:
+
+| Guide | Use it for |
+| --- | --- |
+| [Source build and CLI commands](docs/development.md) | Cloning, building, common commands, output paths, and local development. |
+| [Configuration](docs/configuration.md) | Authenticated testing, login flows, rules of engagement, report filters, and rate-limit settings. |
+| [AI providers](docs/ai-providers.md) | Anthropic, AWS Bedrock, Google Vertex AI, and custom Anthropic-compatible endpoints. |
+| [Platforms and networking](docs/platforms.md) | Windows/WSL2, Linux, macOS, Docker networking, local apps, and custom hostnames. |
+| [Workspaces and resuming](docs/workspaces.md) | Naming workspaces, resuming interrupted scans, and workspace storage. |
+| [Safety and limitations](docs/safety.md) | Authorized-use requirements, non-production guidance, mutative effects, cost, and model caveats. |
+| [Coverage and roadmap](docs/coverage-roadmap.md) | Current vulnerability coverage and planned work. |
+| [Shannon Pro](docs/shannon-pro.md) | Commercial platform, black-box and white-box pentesting, full lifecycle workflows, and enterprise deployment. |
+
+## Safety, Scope, and Limitations
+
+Shannon Lite is not a passive scanner. Its exploitation agents can create users, submit forms, mutate application state, trigger outbound requests, and otherwise affect the target system. Use sandboxed, staging, or local development environments with disposable data.
+
+You are responsible for using Shannon Lite legally and ethically. Do not point Shannon Lite at systems, repositories, or applications you do not own or do not have explicit authorization to test.
+
+Important limitations:
+
+- Shannon Lite focuses on actively exploitable issues such as Injection, XSS, SSRF, Broken Authentication, and Broken Authorization. Broader static-analysis findings, including vulnerable dependencies and insecure configurations, are a core focus of Shannon Pro.
+- Findings still require human review. LLM-generated reports can contain weakly supported or incorrect details.
+- Shannon Lite is officially supported with Claude models. Smaller, alternative, or proxied non-Claude models may be incomplete or unstable.
+- A full run can take roughly 1 to 1.5 hours and may incur LLM API costs depending on model pricing and application complexity.
+- Do not scan untrusted or adversarial codebases; AI-powered tools that read source code can be exposed to prompt injection.
+
+Read the full [Safety and limitations](docs/safety.md) guide before running Shannon Lite in a new environment.
+
+## License and Enterprise Licensing
+
+Shannon Lite is licensed under the [GNU Affero General Public License v3.0](LICENSE).
+
+Commercial and enterprise licensing is available for organizations that need different license terms, commercial support, private redistribution, managed-service use, or broader deployment options.
+
+For commercial licensing, contact [shannon@keygraph.io](mailto:shannon@keygraph.io).
+
+## Community and Support
+
+**Community office hours** are available for hands-on help with bugs, deployments, and configuration questions.
+
+- US/EU: Thursday, 10:00 AM PT
+- Asia: Thursday, 2:00 PM IST
+- [Book a slot](https://cal.com/george-flores-keygraph/shannon-community-office-hours)
+
+[Join Discord](https://discord.gg/cmctpMBXwE) to ask questions, share feedback, and connect with other Shannon Lite users.
+
+At this time, Keygraph is not accepting external code contributions. Issues are welcome for bug reports and feature requests:
+
+- [Report bugs](https://github.com/KeygraphHQ/shannon/issues)
+- [Suggest features](https://github.com/KeygraphHQ/shannon/discussions)
+
+Stay connected:
+
+- [Keygraph website](https://keygraph.io)
+- [Twitter/X: @KeygraphHQ](https://twitter.com/KeygraphHQ)
+- [LinkedIn: Keygraph](https://linkedin.com/company/keygraph)
+
+
+ Built by Keygraph
+
+
+---
+
+# File: docs/development.md
+
+# Source Build and CLI Commands
+
+This guide covers the source-build workflow, common CLI commands, repository paths, and output locations. For the fastest first run, use the `npx` workflow in the main README.
+
+## Prerequisites
+
+- Docker
+- Node.js 18+
+- pnpm
+- AI provider credentials
+
+## Clone and Build
+
+Use the source-build workflow if you want to run Shannon Lite from a local clone, modify the open-source CLI, or keep the worker image built locally.
+
+```bash
+# 1. Clone Shannon Lite.
+git clone https://github.com/KeygraphHQ/shannon.git
+cd shannon
+
+# 2. Configure credentials.
+cp .env.example .env
+
+# 3. Install dependencies and build.
+pnpm install
+pnpm build
+
+# 4. Run a pentest.
+./shannon start -u https://your-app.com -r /path/to/your-repo
+```
+
+At minimum, your `.env` file should include one supported AI provider credential, such as:
+
+```bash
+ANTHROPIC_API_KEY=your-api-key
+CLAUDE_CODE_MAX_OUTPUT_TOKENS=64000
+```
+
+Environment variables can also be exported directly:
+
+```bash
+export ANTHROPIC_API_KEY="your-api-key"
+export CLAUDE_CODE_MAX_OUTPUT_TOKENS=64000
+```
+
+## Prepare Your Repository
+
+Shannon Lite can scan any repository on your machine. Pass an absolute or relative path with `-r`.
+
+```bash
+npx @keygraph/shannon start -u https://example.com -r /path/to/repo
+./shannon start -u https://example.com -r ./relative/path
+```
+
+The target repository is mounted read-only inside the worker container.
+
+## Common Commands
+
+Monitor progress:
+
+```bash
+npx @keygraph/shannon logs
+npx @keygraph/shannon status
+```
+
+Source-build equivalents:
+
+```bash
+./shannon logs
+./shannon status
+```
+
+Open the Temporal Web UI for detailed monitoring:
+
+```bash
+open http://localhost:8233
+```
+
+Stop Shannon Lite:
+
+```bash
+npx @keygraph/shannon stop
+npx @keygraph/shannon stop --clean
+npx @keygraph/shannon uninstall
+```
+
+Source-build equivalents:
+
+```bash
+./shannon stop
+./shannon stop --clean
+```
+
+Usage examples:
+
+```bash
+# Basic pentest.
+npx @keygraph/shannon start -u https://example.com -r /path/to/repo
+
+# With a configuration file.
+npx @keygraph/shannon start -u https://example.com -r /path/to/repo -c /path/to/my-config.yaml
+
+# Custom output directory.
+npx @keygraph/shannon start -u https://example.com -r /path/to/repo -o ./my-reports
+
+# Named workspace.
+npx @keygraph/shannon start -u https://example.com -r /path/to/repo -w q1-audit
+
+# List all workspaces.
+npx @keygraph/shannon workspaces
+```
+
+Source-build examples:
+
+```bash
+./shannon start -u https://example.com -r /path/to/repo
+./shannon start -u https://example.com -r /path/to/repo -c /path/to/my-config.yaml
+./shannon start -u https://example.com -r /path/to/repo -o ./my-reports
+./shannon start -u https://example.com -r /path/to/repo -w q1-audit
+./shannon workspaces
+
+# Rebuild the worker image.
+./shannon build --no-cache
+```
+
+## Output and Results
+
+Results are saved to the workspaces directory:
+
+- `./workspaces/` in source-build mode
+- `~/.shannon/workspaces/` in `npx` mode
+
+Use `-o ` to copy deliverables to a custom output directory after a run completes.
+
+Output structure:
+
+```text
+workspaces/{hostname}_{sessionId}/
+|-- session.json
+|-- workflow.log
+|-- agents/
+|-- prompts/
+`-- deliverables/
+ `-- comprehensive_security_assessment_report.md
+```
+
+---
+
+# File: docs/configuration.md
+
+# Configuration
+
+Shannon Lite can run without a configuration file, but configuration enables authenticated testing, scope guidance, rules of engagement, report filtering, and rate-limit tuning.
+
+## Credential Precedence
+
+Source-build mode resolves credentials from:
+
+1. Environment variables, such as `export ANTHROPIC_API_KEY=...`
+2. `./.env`
+
+`npx` mode resolves credentials from:
+
+1. Environment variables
+2. `~/.shannon/config.toml`, created by `npx @keygraph/shannon setup`
+
+Environment variables always win, so you can override saved config for a single session without editing files.
+
+## Create a Configuration File
+
+Copy and modify the example configuration:
+
+```bash
+cp configs/example-config.yaml ./my-app-config.yaml
+```
+
+Run with:
+
+```bash
+npx @keygraph/shannon start -u https://example.com -r /path/to/repo -c ./my-app-config.yaml
+```
+
+Source-build equivalent:
+
+```bash
+./shannon start -u https://example.com -r /path/to/repo -c ./my-app-config.yaml
+```
+
+## Basic Configuration Structure
+
+```yaml
+# Describe your target environment.
+description: "Next.js e-commerce app on PostgreSQL. Local dev environment; .env files contain local-only credentials."
+
+# Limit which vulnerability classes run end-to-end.
+# vuln_classes: [injection, xss, auth, authz, ssrf]
+
+# Skip the exploitation phase.
+# exploit: "false"
+
+# Free-form rules of engagement.
+# rules_of_engagement: |
+# - No password brute-force; cap login attempts at 5 per account.
+# - Throttle to under 5 requests per second per endpoint; back off 60s on any 429.
+# - Use placeholders like [order_id] in deliverables; no real data values.
+
+authentication:
+ login_type: form
+ login_url: "https://your-app.com/login"
+ credentials:
+ username: "test@example.com"
+ password: "yourpassword"
+ totp_secret: "LB2E2RX7XFHSTGCK"
+
+ # Optional mailbox credentials for magic-link or email-OTP flows.
+ # email_login:
+ # address: "inbox@example.com"
+ # password: "mailbox-password"
+ # totp_secret: "JBSWY3DPEHPK3PXP"
+
+ login_flow:
+ - "Type $username into the email field"
+ - "Type $password into the password field"
+ - "Click the 'Sign In' button"
+
+ success_condition:
+ type: url_contains
+ value: "/dashboard"
+
+rules:
+ avoid:
+ - description: "AI should avoid testing logout functionality"
+ type: url_path
+ value: "/logout"
+
+ # code_path values are repo-relative file paths or globs.
+ # - description: "Out-of-scope vendored libraries"
+ # type: code_path
+ # value: "src/vendor/**"
+
+ focus:
+ - description: "AI should emphasize testing API endpoints"
+ type: url_path
+ value: "/api"
+
+# Filters applied by the report agent when assembling the final report.
+# report:
+# min_severity: low
+# min_confidence: low
+# guidance: |
+# Drop findings about missing security headers and rate-limit gaps.
+```
+
+Supported rule types include `url_path`, `subdomain`, `domain`, `method`, `header`, `parameter`, and `code_path`.
+
+## Writing Login Flow
+
+Log in once in a fresh private browser window. Write the steps in the same order you perform them:
+
+- When typing into a field, reference the field by its exact label or placeholder.
+- When clicking a button, reference the exact button text.
+
+Supported placeholders:
+
+- `$username`
+- `$password`
+- `$totp`
+- `$email_address`
+- `$email_password`
+- `$email_totp`
+
+At runtime, Shannon Lite replaces these placeholders with the credentials passed in the config.
+
+```yaml
+login_flow:
+ - "Type $username in "
+ - "Click "
+ - "Type $password in "
+ - "Click "
+ - "If prompted for 2FA, type $totp in "
+ - "Click "
+```
+
+## Adaptive Thinking
+
+Claude decides when and how deeply to reason on Opus 4.6 and 4.7. This is enabled by default whenever a tier resolves to one of these models.
+
+- `npx` mode: `npx @keygraph/shannon setup` prompts you during the wizard.
+- Source-build mode: set `CLAUDE_ADAPTIVE_THINKING=false` in `.env` or export it in your shell.
+
+## Subscription Plan Rate Limits
+
+Anthropic subscription plans reset usage on a rolling 5-hour window. The default retry strategy may exhaust retries before the window resets. Add this to your config:
+
+```yaml
+pipeline:
+ retry_preset: subscription
+ max_concurrent_pipelines: 2
+```
+
+`max_concurrent_pipelines` controls how many vulnerability pipelines run simultaneously. Supported values are 1-5, with a default of 5. Lower values reduce burst API usage but increase wall-clock time.
+
+---
+
+# File: docs/ai-providers.md
+
+# AI Providers
+
+Shannon Lite works best with Claude models. Anthropic API keys are recommended for most users, and Shannon Lite also supports AWS Bedrock, Google Vertex AI, and custom Anthropic-compatible endpoints.
+
+## Anthropic
+
+Run the setup wizard:
+
+```bash
+npx @keygraph/shannon setup
+```
+
+Or export an API key directly:
+
+```bash
+export ANTHROPIC_API_KEY=your-api-key
+```
+
+Source-build mode can use a `.env` file:
+
+```bash
+ANTHROPIC_API_KEY=your-api-key
+CLAUDE_CODE_MAX_OUTPUT_TOKENS=64000
+```
+
+## AWS Bedrock
+
+Run `npx @keygraph/shannon setup` and select **AWS Bedrock**. The wizard prompts for region, bearer token, and model IDs.
+
+Or export environment variables directly:
+
+```bash
+export CLAUDE_CODE_USE_BEDROCK=1
+export AWS_REGION=us-east-1
+export AWS_BEARER_TOKEN_BEDROCK=your-bearer-token
+export ANTHROPIC_SMALL_MODEL=us.anthropic.claude-haiku-4-5-20251001-v1:0
+export ANTHROPIC_MEDIUM_MODEL=us.anthropic.claude-sonnet-4-6
+export ANTHROPIC_LARGE_MODEL=us.anthropic.claude-opus-4-7
+```
+
+Source-build `.env` equivalent:
+
+```bash
+CLAUDE_CODE_USE_BEDROCK=1
+AWS_REGION=us-east-1
+AWS_BEARER_TOKEN_BEDROCK=your-bearer-token
+ANTHROPIC_SMALL_MODEL=us.anthropic.claude-haiku-4-5-20251001-v1:0
+ANTHROPIC_MEDIUM_MODEL=us.anthropic.claude-sonnet-4-6
+ANTHROPIC_LARGE_MODEL=us.anthropic.claude-opus-4-7
+```
+
+Shannon Lite uses three model tiers:
+
+- **small** for summarization
+- **medium** for security analysis
+- **large** for deep reasoning
+
+Set `ANTHROPIC_SMALL_MODEL`, `ANTHROPIC_MEDIUM_MODEL`, and `ANTHROPIC_LARGE_MODEL` to Bedrock model IDs available in your region.
+
+## Google Vertex AI
+
+Create a service account with the `roles/aiplatform.user` role in the GCP Console, then download a JSON key file.
+
+Run `npx @keygraph/shannon setup` and select **Google Vertex AI**. The wizard prompts for region, project ID, service account key file path, and model IDs. The key file is copied to `~/.shannon/google-sa-key.json`.
+
+Or export environment variables directly:
+
+```bash
+export CLAUDE_CODE_USE_VERTEX=1
+export CLOUD_ML_REGION=us-east5
+export ANTHROPIC_VERTEX_PROJECT_ID=your-gcp-project-id
+export GOOGLE_APPLICATION_CREDENTIALS=/path/to/your-sa-key.json
+export ANTHROPIC_SMALL_MODEL=claude-haiku-4-5@20251001
+export ANTHROPIC_MEDIUM_MODEL=claude-sonnet-4-6
+export ANTHROPIC_LARGE_MODEL=claude-opus-4-7
+```
+
+Source-build `.env` equivalent:
+
+```bash
+CLAUDE_CODE_USE_VERTEX=1
+CLOUD_ML_REGION=us-east5
+ANTHROPIC_VERTEX_PROJECT_ID=your-gcp-project-id
+GOOGLE_APPLICATION_CREDENTIALS=./credentials/google-sa-key.json
+ANTHROPIC_SMALL_MODEL=claude-haiku-4-5@20251001
+ANTHROPIC_MEDIUM_MODEL=claude-sonnet-4-6
+ANTHROPIC_LARGE_MODEL=claude-opus-4-7
+```
+
+Set `CLOUD_ML_REGION=global` for global endpoints, or use a specific region like `us-east5`. Some models may not be available on global endpoints.
+
+## Custom Base URL
+
+Shannon Lite supports pointing the SDK at an Anthropic-compatible endpoint with `ANTHROPIC_BASE_URL`. For proxy-based routing, use an LLM proxy such as LiteLLM configured to expose an Anthropic-compatible endpoint.
+
+> [!IMPORTANT]
+> Only Claude models are officially supported. Shannon Lite's evaluations, internal testing, and agent harness are optimized for Claude. Smaller or alternative models, including non-Claude models routed through a proxy, may not reliably follow Shannon Lite's instructions or tool-use constraints. Use them at your own risk.
+
+The experimental `claude-code-router` integration is being removed. If you rely on it, migrate to an Anthropic-compatible proxy such as LiteLLM before upgrading.
+
+Run `npx @keygraph/shannon setup` and select **Custom Base URL**, or export variables directly:
+
+```bash
+export ANTHROPIC_BASE_URL=https://your-proxy.example.com
+export ANTHROPIC_AUTH_TOKEN=your-auth-token
+export ANTHROPIC_SMALL_MODEL=claude-haiku-4-5-20251001
+export ANTHROPIC_MEDIUM_MODEL=claude-sonnet-4-6
+export ANTHROPIC_LARGE_MODEL=claude-opus-4-7
+```
+
+Source-build `.env` equivalent:
+
+```bash
+ANTHROPIC_BASE_URL=https://your-proxy.example.com
+ANTHROPIC_AUTH_TOKEN=your-auth-token
+ANTHROPIC_SMALL_MODEL=claude-haiku-4-5-20251001
+ANTHROPIC_MEDIUM_MODEL=claude-sonnet-4-6
+ANTHROPIC_LARGE_MODEL=claude-opus-4-7
+```
+
+---
+
+# File: docs/platforms.md
+
+# Platforms and Networking
+
+This guide covers platform-specific notes and Docker networking behavior.
+
+## Windows
+
+Shannon Lite on Windows is supported through WSL2. Native Windows, including Git Bash, is not supported.
+
+### Ensure WSL2
+
+```powershell
+wsl --install
+wsl --set-default-version 2
+
+# Check installed distros.
+wsl --list --verbose
+
+# If you do not have a distro, install one.
+wsl --list --online
+wsl --install Ubuntu-24.04
+
+# If your distro shows VERSION 1, convert it to WSL2.
+wsl --set-version 2
+```
+
+Install Docker Desktop on Windows and enable the WSL2 backend under **Settings > General > Use the WSL 2 based engine**.
+
+Run Shannon Lite inside WSL:
+
+```bash
+npx @keygraph/shannon setup
+npx @keygraph/shannon start -u https://your-app.com -r /path/to/your-repo
+```
+
+Source-build equivalent:
+
+```bash
+git clone https://github.com/KeygraphHQ/shannon.git
+cd shannon
+cp .env.example .env
+./shannon start -u https://your-app.com -r /path/to/your-repo
+```
+
+To access the Temporal Web UI, run `ip addr` inside WSL to find your WSL IP address, then navigate to `http://:8233` in your Windows browser.
+
+Windows Defender may flag exploit code in reports as false positives. Add an exclusion for the Shannon Lite directory or use Docker/WSL2 isolation.
+
+## Linux
+
+Linux works with native Docker. Depending on your Docker setup, you may need `sudo`. If output files have permission issues, ensure your user has access to the Docker socket and workspace directory.
+
+## macOS
+
+macOS works with Docker Desktop installed.
+
+## Testing Local Applications
+
+Docker containers cannot reach `localhost` on your host machine. Use `host.docker.internal` instead:
+
+```bash
+npx @keygraph/shannon start -u http://host.docker.internal:3000 -r /path/to/repo
+```
+
+Source-build equivalent:
+
+```bash
+./shannon start -u http://host.docker.internal:3000 -r /path/to/repo
+```
+
+## Custom Hostnames
+
+If your local stack uses custom hostnames mapped in `/etc/hosts`, Shannon Lite forwards those entries into the worker container at scan start.
+
+To disable forwarding:
+
+```bash
+export SHANNON_FORWARD_HOSTS=false
+```
+
+In source-build mode, you can also add this to `.env`:
+
+```bash
+SHANNON_FORWARD_HOSTS=false
+```
+
+---
+
+# File: docs/workspaces.md
+
+# Workspaces and Resuming
+
+Shannon Lite uses workspaces to store scan state, logs, prompts, and deliverables. Workspaces allow interrupted or failed runs to resume without re-running completed agents.
+
+## How Workspaces Work
+
+- Every run creates a workspace.
+- Auto-named workspaces use the target hostname and a session ID, such as `example-com_shannon-1771007534808`.
+- `npx` mode stores workspaces in `~/.shannon/workspaces/`.
+- Source-build mode stores workspaces in `./workspaces/`.
+- Use `-w ` to give a run a custom name.
+- To resume a run, pass the same workspace name with `-w`.
+- Each agent's progress is checkpointed so resumed runs can skip completed work.
+
+> [!NOTE]
+> The URL must match the original workspace URL when resuming. Shannon Lite rejects mismatched URLs to prevent cross-target contamination.
+
+## Examples
+
+Start with a named workspace:
+
+```bash
+npx @keygraph/shannon start -u https://example.com -r /path/to/repo -w my-audit
+```
+
+Resume the same workspace:
+
+```bash
+npx @keygraph/shannon start -u https://example.com -r /path/to/repo -w my-audit
+```
+
+Resume an auto-named workspace:
+
+```bash
+npx @keygraph/shannon start -u https://example.com -r /path/to/repo -w example-com_shannon-1771007534808
+```
+
+List all workspaces:
+
+```bash
+npx @keygraph/shannon workspaces
+```
+
+Source-build equivalents:
+
+```bash
+./shannon start -u https://example.com -r /path/to/repo -w my-audit
+./shannon start -u https://example.com -r /path/to/repo -w example-com_shannon-1771007534808
+./shannon workspaces
+```
+
+---
+
+# File: docs/safety.md
+
+# Safety and Limitations
+
+Read this before running Shannon Lite in a new environment.
+
+## Authorized Use Only
+
+Shannon Lite is designed for legitimate security auditing. You must have explicit written authorization from the owner of the target system before running Shannon Lite.
+
+Unauthorized scanning or exploitation of systems you do not own is illegal. Keygraph is not responsible for misuse of Shannon Lite.
+
+## Do Not Run on Production
+
+Shannon Lite is not a passive scanner. Exploitation agents actively execute attacks to confirm vulnerabilities. This can mutate application state and data.
+
+Do not run Shannon Lite against production systems. Use sandboxed, staging, or local development environments where data integrity is not a concern.
+
+Potential mutative effects include:
+
+- Creating new users
+- Modifying or deleting data
+- Compromising test accounts
+- Triggering unintended side effects from injection attacks
+- Generating unexpected outbound traffic
+- Writing exploit artifacts to reports or deliverables
+
+For maximum isolation, run Shannon Lite inside a disposable virtual machine.
+
+## LLM and Automation Caveats
+
+- **Verification is required**: Shannon Lite uses a proof-by-exploitation methodology, but final reports can still contain weakly supported or incorrect details. Human review is essential.
+- **Model support**: Shannon Lite is officially supported only with Claude models. Alternative models may be incomplete, inaccurate, or unstable.
+- **Prompt injection risk**: Do not point Shannon Lite at untrusted or adversarial codebases. AI-powered tools that read source code can be influenced by malicious repository content.
+
+## Scope of Analysis
+
+Shannon Lite currently targets exploitable vulnerabilities in these classes:
+
+- Broken Authentication
+- Broken Authorization
+- Injection
+- Cross-Site Scripting
+- Server-Side Request Forgery
+
+Shannon Lite's proof-by-exploitation model means it does not report issues it cannot actively exploit, such as many vulnerable dependency, insecure configuration, or broad policy findings.
+
+For broader coverage, Shannon Pro adds black-box and white-box agentic pentesting, graph-based static analysis, SCA reachability, secrets detection, business logic testing, remediation workflows, SLA tracking, and reporting dashboards.
+
+## Cost and Performance
+
+A full test run typically takes roughly 1 to 1.5 hours. LLM API costs vary by model pricing, target complexity, selected provider, and concurrency.
+
+If you use subscription-based model access, consider the rate-limit guidance in [Configuration](configuration.md).
+
+---
+
+# File: docs/coverage-roadmap.md
+
+# Coverage and Roadmap
+
+Shannon Lite focuses on exploitable findings that can be validated against a running application.
+
+## Current Shannon Lite Coverage
+
+- Broken Authentication
+- Broken Authorization
+- Injection
+- Cross-Site Scripting
+- Server-Side Request Forgery
+
+## Reporting Philosophy
+
+Shannon Lite follows a proof-by-exploitation model. Findings that cannot be demonstrated with a working proof of concept are not included in the final report.
+
+This reduces speculative noise, but it also means Shannon Lite does not aim to report every possible security issue in a repository. In particular, many dependency, policy, configuration, and broad static-analysis findings are outside the core Shannon Lite workflow.
+
+## Roadmap Direction
+
+Planned coverage areas should continue to live in the repository's canonical roadmap document if one exists. The README should link to that document rather than carrying detailed roadmap history inline.
+
+For organizations that need broader static and organizational coverage now, see [Shannon Pro](shannon-pro.md).
+
+---
+
+# File: docs/shannon-pro.md
+
+# Shannon Pro
+
+Shannon Pro is Keygraph's commercial continuous pentesting and AppSec platform for teams running security across many repositories, services, and environments. While Shannon Lite is a local white-box pentesting CLI, Shannon Pro is a full platform: it combines parsed-code SAST, source-to-sink analysis, black-box and white-box agentic pentesting, verified remediation, CI/CD gating, SLA tracking, and reporting for security and compliance teams.
+
+This repository contains Shannon Lite, the AGPL-3.0 open-source CLI for strictly white-box pentesting. Shannon Pro supports both white-box and black-box agentic pentesting and adds static analysis, finding management, remediation workflows, reporting, and enterprise deployment options.
+
+## Who Should Consider Shannon Pro
+
+Shannon Pro is intended for organizations that need:
+
+- Continuous AppSec coverage across many repositories and services
+- White-box pentesting when source code is available
+- Black-box pentesting against deployed applications and APIs without source-code access
+- Agentic SAST, SCA with reachability, secrets scanning, IaC scanning, container scanning, and business logic testing
+- Canonical finding management, deduplication, ownership, status tracking, and severity tracking
+- Sync into developer workflows, including ticketing and source-control systems
+- User-initiated remediation with verification before delivery
+- SLA tracking, reporting dashboards, and compliance evidence
+- Commercial support
+- Self-hosted, air-gapped, BYOK, and customer-controlled LLM gateway deployment options
+
+## Full Vulnerability Lifecycle
+
+Shannon Pro is designed to cover the full vulnerability lifecycle, not only discovery:
+
+1. **Find** exploitable issues with white-box pentesting, black-box pentesting, SAST, SCA, secrets, IaC, container, and business logic testing.
+2. **Normalize** results into canonical findings so duplicate scanner outputs become one tracked vulnerability per repository.
+3. **Prioritize** findings using exploit evidence, reachability, severity, ownership, and business context.
+4. **Sync** work into developer workflows through ticketing and source-control integrations.
+5. **Remediate** with user-initiated patch generation when teams want help moving from evidence to code changes.
+6. **Verify** fixes by re-running the relevant scanner or exploit workflow before a remediation is delivered.
+7. **Track** ownership, status, SLAs, MTTR, and drift over time.
+8. **Report** through dashboards for risk, trends, compliance evidence, and security program operations.
+
+## Pentesting Modes
+
+Shannon Lite is strictly white-box: it requires access to the target application's source code and repository layout.
+
+Shannon Pro supports two pentesting modes:
+
+- **White-box agentic pentesting**: Agents use source-code context to understand architecture, identify realistic attack paths, and validate exploitability against the running application.
+- **Black-box agentic pentesting**: Agents test deployed applications and APIs without source-code access, useful for third-party surfaces, production-like external validation, or environments where source access is unavailable.
+
+Both modes follow the same core principle: do not report what might be vulnerable when an exploit can prove what is vulnerable.
+
+## AppSec Coverage
+
+Shannon Pro combines agentic pentesting with broader AppSec coverage:
+
+- **Agentic SAST**: Code Property Graph analysis with LLM reasoning for data flow, context, and sanitization decisions.
+- **SCA with reachability**: Dependency vulnerability analysis that prioritizes issues reachable from application entry points.
+- **Secrets scanning**: Detection and validation of credentials, tokens, and API keys.
+- **Business logic testing**: Authorization bypass, IDOR, workflow abuse, state-machine flaws, race conditions, and other application-specific logic issues.
+- **IaC scanning**: Terraform, CloudFormation, Kubernetes, Helm, and related infrastructure configuration checks.
+- **Container scanning**: Vulnerable packages, exposed secrets, and misconfigurations across image layers.
+
+## Static-Dynamic Correlation
+
+Static-dynamic correlation is a core product difference. A static finding, such as unsanitized input reaching a SQL query, is not treated as a purely theoretical issue. It is sent to an exploit agent, tested against the live application, and traced back to the exact source-code location when confirmed.
+
+The result is a finding with proof of exploitability, source context when available, ownership, status, SLA, remediation history, and reporting metadata.
+
+## Enterprise Deployment
+
+Shannon Pro supports enterprise deployment patterns for teams with strict data, model, and network requirements:
+
+- **Self-hosted deployments** inside the customer's cloud or infrastructure
+- **Air-gapped deployments** for isolated environments
+- **Strict BYOK model access** using customer-managed model credentials
+- **Customer-controlled LLM gateway patterns** for routing, policy, logging, and isolation
+- **Enterprise identity and provisioning** such as SSO and SCIM
+- **Deep integrations** with source control, ticketing, chat, registries, and cloud environments
+
+Deployments can be designed so source code, scan results, prompts, completions, and model traffic remain inside the customer's security perimeter.
+
+## Capability Comparison
+
+| Need | Shannon Lite | Shannon Pro |
+| --- | --- | --- |
+| Licensing | AGPL-3.0 | Commercial |
+| White-box pentesting | Yes; source code required | Yes; source-aware testing with platform workflows |
+| Black-box pentesting | No | Yes; autonomous testing without source-code access |
+| Code analysis / SAST | Prompting and source pass-through to guide pentesting | Actual code parsing, Code Property Graph analysis, source-to-sink path analysis, and agentic SAST |
+| AppSec coverage | OWASP-focused agentic pentesting | Agentic pentesting, SAST, SCA, secrets, IaC, containers, and business logic testing |
+| CI/CD and gating | Manual/local CLI runs | Headless commercial CLI for CI/CD gating across enterprise CI/CD platforms |
+| Finding lifecycle | Local Markdown reports | Canonical findings, deduplication, ownership, status, SLA tracking, workflow sync, and reporting dashboards |
+| Remediation | Manual | User-initiated remediation with verification before delivery |
+| Fix verification | None; manual reruns only | Targeted verification without rerunning the entire scan, completing the remediation lifecycle |
+| Enterprise deployment | Local CLI and Docker worker | Self-hosted, air-gapped, BYOK, and customer-controlled LLM gateway options |
+| Support | Community | Commercial support |
+
+## Contact
+
+Learn more on the [Keygraph website](https://keygraph.io), start a free trial, book a [Shannon Pro demo](https://cal.com/team/keygraph/shannon-pro), or contact [shannon@keygraph.io](mailto:shannon@keygraph.io).
diff --git a/llms.txt b/llms.txt
new file mode 100644
index 0000000..24187d4
--- /dev/null
+++ b/llms.txt
@@ -0,0 +1,36 @@
+# Shannon
+
+> Shannon is an autonomous AI pentesting project by Keygraph. This repository contains Shannon Lite, the AGPL-3.0 open-source white-box pentesting CLI. Shannon Pro is Keygraph's commercial continuous pentesting and AppSec platform.
+
+Use this file as the concise entry point for AI agents and LLMs reading this repository. For a single combined context file, use [llms-full.txt](llms-full.txt).
+
+## Start Here
+
+- [README](README.md): Main project overview, product line, quick start, Shannon Lite capabilities, Shannon Pro positioning, safety notes, licensing, and support links.
+- [Full Combined Context](llms-full.txt): README and documentation combined into one file for agents that need maximum local context.
+
+## Shannon Lite
+
+- [Development](docs/development.md): Source-build workflow, common CLI commands, repository paths, and output locations.
+- [Configuration](docs/configuration.md): Authenticated testing, login flows, rules of engagement, report filters, credential precedence, adaptive thinking, and rate-limit settings.
+- [AI Providers](docs/ai-providers.md): Anthropic, AWS Bedrock, Google Vertex AI, and custom Anthropic-compatible endpoint setup.
+- [Platforms and Networking](docs/platforms.md): Windows/WSL2, Linux, macOS, Docker networking, local applications, and custom hostnames.
+- [Workspaces and Resuming](docs/workspaces.md): Workspace storage, naming, resuming interrupted scans, and examples.
+- [Safety and Limitations](docs/safety.md): Authorized-use requirements, non-production guidance, mutative effects, model caveats, scope limits, cost, and performance.
+- [Coverage and Roadmap](docs/coverage-roadmap.md): Current Shannon Lite coverage and roadmap direction.
+
+## Shannon Pro
+
+- [Shannon Pro](docs/shannon-pro.md): Commercial continuous pentesting and AppSec platform, including black-box and white-box pentesting, parsed-code SAST, source-to-sink analysis, remediation workflows, CI/CD gating, SLA tracking, reporting, and enterprise deployment.
+
+## External Links
+
+- [Keygraph website](https://keygraph.io): Company and commercial product information.
+- [Shannon Pro demo](https://cal.com/team/keygraph/shannon-pro): Demo and trial contact path.
+- [Community Discord](https://discord.gg/cmctpMBXwE): Community support and discussion.
+
+## Optional
+
+- [Sample Juice Shop report](sample-reports/shannon-report-juice-shop.md): Shannon Lite sample report for OWASP Juice Shop.
+- [Sample c{api}tal API report](sample-reports/shannon-report-capital-api.md): Shannon Lite sample report for c{api}tal API.
+- [Sample crAPI report](sample-reports/shannon-report-crapi.md): Shannon Lite sample report for OWASP crAPI.