{"slug": "raptor-turns-claude-code-into-a-general-purpose-ai", "title": "Raptor turns Claude Code into a general-purpose AI", "summary": "Security researchers Gadi Evron, Daniel Cuthbert, Thomas Dullien, Michael Bargury, and John Cartwright released RAPTOR (Recursive Autonomous Penetration Testing and Observation Robot), an open-source framework built on Claude Code v3.1.0 that automates security research by chaining static analysis, binary analysis, LLM-powered vulnerability validation, exploit generation, and patch writing into a single workflow. The tool, available on GitHub under an MIT license, requires Claude Code with an active subscription or Anthropic API key, Python 3.10+, Node.js 18+, and Semgrep, with CodeQL optional but recommended.", "body_md": "\n\n```\n╔═══════════════════════════════════════════════════════════════════════════╗\n║                                                                           ║\n║             ██████╗  █████╗ ██████╗ ████████╗ ██████╗ ██████╗             ║\n║             ██╔══██╗██╔══██╗██╔══██╗╚══██╔══╝██╔═══██╗██╔══██╗            ║\n║             ██████╔╝███████║██████╔╝   ██║   ██║   ██║██████╔╝            ║\n║             ██╔══██╗██╔══██║██╔═══╝    ██║   ██║   ██║██╔══██╗            ║\n║             ██║  ██║██║  ██║██║        ██║   ╚██████╔╝██║  ██║            ║\n║             ╚═╝  ╚═╝╚═╝  ╚═╝╚═╝        ╚═╝    ╚═════╝ ╚═╝  ╚═╝            ║\n║                                                                           ║\n║             Autonomous Offensive/Defensive Research Framework             ║\n║             Based on Claude Code (v3.1.0)                                 ║\n║                                                                           ║\n║             Gadi Evron, Daniel Cuthbert, Thomas Dullien (Halvar Flake)    ║\n║             Michael Bargury, John Cartwright                              ║\n║                                                                           ║\n╚═══════════════════════════════════════════════════════════════════════════╝\n\n⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⣠⣤⣤⣀⣀\n⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣾⣿⣿⠿⠿⠟\n⠀⠀⠀⠀⠀⠀⠀⠀⢀⣀⣀⣀⣀⣀⣀⣤⣴⣶⣶⣶⣤⣿⡿⠁⠀⠀⠀\n⣀⠤⠴⠒⠒⠛⠛⠛⠛⠛⠿⢿⣿⣿⣿⣿⣿⣿⣿⣿⣿⠟⠁⠀⠀⠀⠀\n⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠉⠛⣿⣿⣿⡟⠻⢿⡀⠀⠀⠀⠀⠀\n⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⣾⢿⣿⠟⠀⠸⣊⡽⠀⠀⠀⠀⠀\n⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢸⡇⣿⡁⠀⠀⠀⠉⠁⠀⠀⠀⠀⠀\n⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠈⠻⠿⣿⣧⠀ Get them bugs.....⠀⠀⠀⠀⠀\n```\n\n**Authors:** Gadi Evron, Daniel Cuthbert, Thomas Dullien (Halvar Flake), Michael Bargury, John Cartwright\n([@gadievron](https://github.com/gadievron), [@danielcuthbert](https://github.com/danielcuthbert), [@thomasdullien](https://github.com/thomasdullien), [@mbrg](https://github.com/mbrg), [@grokjc](https://github.com/grokjc))\n\n**Licence:** MIT, see LICENSE. Note that CodeQL has its own licence and does not permit commercial use.\n\n**Repository:** [https://github.com/gadievron/raptor](https://github.com/gadievron/raptor)\n\nRAPTOR is an autonomous security research framework built on top of Claude Code (but not tied to it -- you can plug in your own analysis layer too). It chains together static analysis, binary analysis, LLM-powered vulnerability validation, exploit generation, and patch writing into a single workflow you can run against a codebase or binary.\n\nIt is not polished software. It was built in free time, held together with enthusiasm and duct tape, and it works well enough that we can't stop using it. If you want to make it better, open a PR.\n\nRAPTOR stands for Recursive Autonomous Penetration Testing and Observation Robot. We really wanted to call it RAPTOR.\n\nRAPTOR is mostly AI-generated code. The humans set direction, review output, and make design decisions; the AI writes the implementation. Mechanical verification (tests, static analysis, corpus calibration) keeps the quality bar where it needs to be regardless of who — or what — wrote the code.\n\n- **Claude Code** with an active subscription (Max, Pro, Team, or Enterprise) or an Anthropic API key. This is the orchestration layer -- RAPTOR runs inside a Claude Code session.\n- **Python 3.10+** and**Node.js 18+** .\n- **Semgrep** (`pip install semgrep` ) for static analysis. CodeQL is optional but recommended.\n\nFor the analysis dispatch layer (the LLM that analyses individual findings), Claude Code itself handles everything by default -- no extra API keys needed. If you want multi-model analysis (e.g. Claude + GPT + Gemini), you will need API keys for each provider. See [Using a different LLM](#using-a-different-llm) below.\n\n```\n# Clone the repo\ngit clone https://github.com/gadievron/raptor.git\ncd raptor\n\n# Install Python dependencies\npip install -r requirements.txt\n\n# Install Claude Code (if you don't already have it)\nnpm install -g @anthropic-ai/claude-code\n\n# Install Semgrep (required for scanning)\npip install semgrep\n\n# Add the launcher to your PATH -- put this in your shell profile to make it\n# permanent. Append rather than prepend, so system directories stay ahead of\n# the repo. (Alternatively, symlink bin/raptor into a directory already on PATH.)\nexport PATH=\"$PATH:$PWD/bin\"\n\n# Launch RAPTOR\nraptor\n```\n\nThe `raptor` launcher is the recommended way to start a session, and it works from any directory -- it resolves the RAPTOR installation, remembers the directory you launched from (so commands like `/scan` default to it), runs the pre-flight trust and project checks, loads the coverage-tracking plugin, and sanitises the environment before handing off to Claude Code. It also takes an optional target path and flags like `--project`, `--continue`, and `--model` -- see `raptor --help`.\n\nRunning plain `claude` from inside the repo directory also works -- Claude Code picks up RAPTOR's configuration from the checkout -- but you skip everything the launcher does above: no pre-flight checks, no coverage tracking, and commands that default to \"the directory you ran this from\" can't see it.\n\n**Important:** RAPTOR loads its configuration from the repo directory. If you run `claude` from any other directory, you get plain Claude Code, not RAPTOR. The `raptor` launcher avoids this failure mode entirely.\n\nUsing containers is a common security practice to restrict agents from accessing areas of your filesystem you don't want them to, as well as limiting the blast radius of any malicious code that may execute (e.g via supply-chain attack). The image is large (around 6 GB). It starts from the Microsoft Python 3.12 devcontainer and adds static analysis, fuzzing, and browser automation tooling.\n\nYou can pull down a pre-built image:\n\n```\ndocker pull danielcuthbert/raptor:latest\n```\n\nor build it locally using the included `Dockerfile`:\n\n```\ndocker build -f .devcontainer/Dockerfile -t raptor:latest .\n```\n\nThe image expects the RAPTOR framework (this repo) to be mounted into `/workspaces/raptor` on startup. You can optionally mount a target folder for local analysis.\n\nTo start the container:\n\n```\ndocker run -it \\\n  -v \"$(pwd):/workspaces/raptor\" \\\n  raptor:latest\n```\n\nTo mount a target folder as well:\n\n```\ndocker run -it \\\n  -v \"$(pwd):/workspaces/raptor\" \\\n  -v \"/path/to/target-folder:/workspaces/target\" \\\n  raptor:latest\n```\n\nAdd `--privileged` if you need the `rr` deterministic debugger.\n\nVS Code devcontainers are also supported. To mount a target folder, add it to the `mounts` section of `.devcontainer/devcontainer.json`:\n\n```\n\"mounts\": [\n  // ...existing entries...\n  \"source=/path/to/target-folder,target=/workspaces/target,type=bind,consistency=cached\"\n]\n```\n\nThen open the repo in VS Code — it will prompt you to reopen in the container:\n\n```\ncd /path/to/raptor\ncode .\n```\n\nEither way, once you're inside the container, run `raptor` to get started.\n\nThe simplest thing you can do:\n\n```\n/scan /path/to/code\n```\n\nThis runs Semgrep (plus Coccinelle when `spatch` is installed; add `--codeql` for CodeQL) against the target, deduplicates findings, and writes a SARIF report. No LLM analysis, no API keys beyond Claude Code. Takes a few minutes on a typical repository.\n\nTo add LLM-powered validation:\n\n```\n/agentic /path/to/code\n```\n\nThis runs the full pipeline: scan, deduplicate, then send each finding through the validation stages (A-F). On a medium-sized codebase with ~50 findings, expect 10-30 minutes and $2-8 in analysis-layer LLM costs (depending on the model). The default cost cap is $10 per run; adjust with `--max-cost-usd`.\n\n**Cost note:** The Claude Code orchestration layer uses your Claude subscription. The analysis dispatch layer makes separate LLM API calls that are billed per token. If you only use Claude Code as the analysis model (the default), there is no extra cost beyond your subscription. If you configure external models (OpenAI, Gemini, etc.), those API calls are billed to those providers.\n\nRAPTOR runs LLM-generated code and analyses untrusted repositories. Subprocesses that handle untrusted content are sandboxed using Linux namespaces, Landlock, and seccomp. The sandbox blocks network access, restricts filesystem visibility, and limits resource consumption. See `docs/sandbox.md` for the full threat model and configuration.\n\nEnvironment variables that could inject code into the launcher chain are stripped at startup (`core/security/_dangerous_env_strip.sh`). File paths from scanned repositories are never interpolated into shell strings — all subprocess calls use list-based arguments.\n\n| Command | What it does | Status | \n|---|---|---|\n| `/agentic` | Full autonomous workflow: scan, validate, exploit, patch | Stable | \n| `/scan` | Static analysis with Semgrep and CodeQL | Stable | \n| `/understand` | Map attack surface, trace data flows, hunt vulnerability variants | Stable | \n| `/binary` | Black-box binary investigation, runtime evidence, graph queries and handoff | Beta | \n| `/ghidra` | Ghidra RE bridge: attach/import `.gpr` projects, cross-version diff, findings export | Beta | \n| `/audit` | Hypothesis-driven, tool-grounded systematic code review | Beta | \n| `/review` | Query audit state: findings, gaps, coverage, operator notes | Stable | \n| `/annotate` | Attach free-form per-function prose annotations (operator review notes) | Stable | \n| `/validate` | Multi-stage exploitability validation pipeline (Stages 0-F) | Stable | \n| `/diagram` | Mermaid visual maps from `/understand` and`/validate` JSON outputs | Beta | \n| `/codeql` | CodeQL-only deep analysis with SMT dataflow pre-screening | Stable | \n| `/analyze` | Analyse existing SARIF findings with LLM, without re-scanning | Stable | \n| `/sca` | Software composition analysis: dependencies, advisories, supply-chain signals, SBOMs, and fixes | Beta | \n| `/cve-diff` | Discover and diff the fix commit for a CVE across OSV, NVD, GitHub, and GitLab | Beta | \n| `/cve-env` | Build and verify a Docker environment running a CVE's affected application at its pre-patch version | Experimental | \n| `/exploit` | Generate proof-of-concept exploit code | Beta | \n| `/patch` | Generate secure patches for confirmed vulnerabilities | Beta | \n| `/fuzz` | Binary fuzzing with AFL++ and crash analysis | Stable | \n| `/crash-analysis` | Autonomous root-cause analysis for C/C++ crashes | Stable | \n| `/oss-forensics` | Evidence-backed forensic investigation for GitHub repositories | Stable | \n| `/project` | Named workspaces to organise runs and track findings over time | Stable | \n| `/describe` | Describe a target: language mix, build system, tool gaps, cost estimate (read-only) | Stable | \n| `/threat-model` | Create, inspect, and maintain per-project threat models | Stable | \n| `/sage` | Persistent memory layer (store, recall, link, corroborate) | Stable | \n| `/ask` | Send a free-form prompt to any configured LLM model | Stable | \n| `/scorecard` | Inspect per-model reliability across decision classes | Stable | \n| `/frida` | Dynamic instrumentation via Frida | Alpha | \n| `/web` | Web application scanning: crawl, ffuf/nuclei integration, oracle-verified injection, blind SSRF callbacks | Beta | \n\nStart by creating a project so all your runs land in one place:\n\n```\n/project create myapp --target /path/to/code   # create a project first\n/project use myapp                             # set it as active\n/understand --map                              # map the attack surface\n/agentic --threat-model --validate             # map, model, scan, validate\n/project findings                              # review everything in one place\n```\n\nFor a compiled artefact, the equivalent starting point is:\n\n```\n/binary investigate /path/to/binary            # build the evidence-backed binary map\n/binary graph <run-dir> --edges --json         # query the persisted graph\n/binary trace-parser <run-dir>                 # collect runtime parser evidence\n/binary harness <run-dir>                      # draft a harness only when the boundary is explicit\n```\n\n`/understand` builds a context map of entry points, trust boundaries, and sinks before a line of scanning happens. `/agentic` then runs Semgrep and CodeQL, deduplicates findings, and dispatches each one for validation using the exploitation-validator methodology:\n\nWith `--threat-model`, RAPTOR runs the map first, creates `threat-model.json` and `THREAT_MODEL.md` if the project does not already have them, then feeds a compact version into `/understand`, autonomous analysis, and `/validate`. Existing project threat models are preserved unless you pass `--threat-model-refresh`; stale fallback maps are refused unless you explicitly pass `--threat-model-use-stale`. It also turns mapped unchecked flows into candidate SARIF so scanner misses do not kill the run. It is operator-owned context, not magic proof: findings still need code evidence or oracle-backed confirmation. See `docs/threat-model.md`.\n\n- Stage A: is the pattern actually a vulnerability, or is the tool pattern-matching noise?\n- Stage B: what does an attacker need to reach it, and what gets in the way?\n- Stage C: does the code path actually exist? can it be reached from outside?\n- Stage D: final call -- is this test code, does it need unrealistic preconditions, is the model hedging?\n- Stage E: binary exploit feasibility (when a compiled artefact is available)\n- Stage F: self-review -- did any earlier stage hedge or contradict itself?\n\nFindings that clear validation get exploit PoCs and patches generated. A cross-finding analysis runs at the end to find shared root causes and attack chains.\n\n`/validate` runs this same pipeline as a standalone step if you already have findings from a previous scan.\n\nFor a compiled artefact, `/binary <path>` now runs an evidence-first\ninvestigation rather than dumping a pile of raw reverse-engineering artefacts\non the operator. Underneath it still builds the SHA-256-bound manifest,\nevidence ledger, context map, checklist and SQLite graph from file metadata,\nimports and radare2 xrefs. Mach-O apps also get slice inventory, bundle\nmetadata and Objective-C / Swift class selectors; high-value pseudocode is\npersisted rather than disappearing inside the run. PE DLL exports, Windows\ndriver dispatchers and Linux kernel-module ioctl handlers are handled as\ntheir own ingress candidates too, with PE architecture read from the COFF\nheader rather than guessed. The investigation layer then queries that graph,\nranks external ingress before generic sink leads, discovers declared\nhelper/sibling binaries, and writes a compact report split into facts,\nstructural inferences and unproven hypotheses. Frida observations, fuzz crash\nwitnesses, explicit Z3 checks and binary diffs can then add stronger evidence\nlater. RAPTOR also keeps the internal call graph needed to recover bounded\ningress-to-parser candidates, so an app callback can be narrowed to the\ninternal function that actually calls `XML_Parse`, `d2i_X509`,\n`jpeg_read_header` or another real parser surface without pretending that is\ntaint proof. `/binary trace-parser <run-dir>` is the explicit dynamic follow-on:\nit runs the narrow Frida parser trace, then refreshes the same context map,\nhandoff, graph and investigation report in place. `/binary investigate --active` maps first and only launches a real\nfuzz campaign when a concrete harness boundary exists; app, DLL and driver\ntargets get a harness or snapshot step instead. `/binary harness` writes an\nevidence-backed harness spec for the chosen ingress and only emits candidate\nsource when the ABI or IOCTL contract is explicit. It does not blag its way from “`memcpy` exists” to “this is\nexploitable”: imports, selectors and call edges stay candidates until\nsomething mechanical proves more. See `docs/binary-analysis.md`.\n\n`/sca` analyses the dependency and supply-chain side of a project. It is not just a requirements-file CVE lookup: RAPTOR discovers manifests, lockfiles, inline install commands, workflow dependencies, and container/base-image package sources, then normalises them into a single dependency view.\n\nThe scan enriches dependencies with OSV advisories, CISA KEV, EPSS, CISA Vulnrichment/SSVC, reachability, exploit-evidence signals, hygiene checks, supply-chain heuristics, licence policy findings, and optional LLM review/triage. It emits RAPTOR-native findings plus SBOM and CI-friendly output:\n\n- `findings.json` - canonical RAPTOR findings\n- `report.md` - human-readable summary\n- `sbom.cdx.json` - CycloneDX SBOM with VEX data\n- `findings.sarif` - GitHub/GitLab code-scanning output\n\nCommon commands:\n\n```\npython3 raptor.py sca --repo /path/to/project\npython3 raptor.py sca --repo /path/to/project --no-llm\npython3 raptor.py sca --repo /path/to/project --fail-on-severity high --fail-on-kev\npython3 raptor.py sca --repo /path/to/project fix\npython3 raptor.py sca check PyPI django 4.2.10\n```\n\nUseful subcommands include `fix`, `check`, `upgrade`, `diff`, `verify`, `health`, `render`, `suppress`, and `clean-cache`. See `docs/sca.md` for the full reference.\n\nRAPTOR has a two-layer Z3 integration (`pip install z3-solver`). It is optional. Everything works without it, but the results are better with it.\n\n**Dataflow pre-screening (CodeQL)**\n\nWhen CodeQL produces a path result, the path constraints are checked for satisfiability before any LLM call is made. Paths that are provably unreachable get dropped immediately. For paths that are reachable, Z3 produces concrete candidate inputs that go into the analysis prompt, so the LLM has something specific to reason about rather than abstract patterns.\n\n**One-gadget constraint analysis (binary feasibility)**\n\nDuring binary exploit feasibility assessment, Z3 checks whether a one-gadget's register and memory constraints are satisfiable against the concrete crash state. Gadgets are ranked by actual reachability rather than heuristics, so you spend time on gadgets that can actually work.\n\nZ3 is pre-installed in the devcontainer. For manual installs: `pip install z3-solver`.\n\nRAPTOR's custom rules under `engine/semgrep/rules/` are fully local and run without network access.\n\nFor registry packs (`p/security-audit`, `p/owasp-top-ten`, etc.), the cache directory ships empty. A cache tool (` engine/semgrep/tools/cache-packs.py`) handles population:\n\n```\n# On a connected machine — update the local cache directly:\npython3 engine/semgrep/tools/cache-packs.py update\n\n# Or fetch into a zip bundle for airgap transfer:\npython3 engine/semgrep/tools/cache-packs.py fetch\n# → produces semgrep-cache-YYYY-MM-DD.zip\n\n# On the airgapped machine — import the bundle:\npython3 engine/semgrep/tools/cache-packs.py import semgrep-cache-2026-07-16.zip\n\n# Check what's cached:\npython3 engine/semgrep/tools/cache-packs.py list\n```\n\nOnce populated, the scanner resolves pack IDs to local files and no network call happens. Without the cache, RAPTOR will attempt to fetch registry packs from semgrep.dev at scan time; if offline, it drops uncached packs gracefully and runs with custom rules only.\n\nCodeQL needs network access only during initial setup to download the CLI and query packs. Once installed it runs offline.\n\nRAPTOR ships over 200 custom static analysis rules, adversarially tested to eliminate false positives:\n\n- **Semgrep (145 rules)** — taint-tracking and pattern rules for Python, Go, Java, and JS/TS. Covers SQLi, XSS, SSRF, SSTI, command injection, deserialisation, XXE, LDAP/NoSQL injection, path traversal, open redirect, log/header injection, eval injection, ReDoS, prototype pollution, JWT misconfiguration, weak crypto, insecure TLS, and hardcoded secrets.\n- **Coccinelle (63 rules)** — structural matching for C/C++. Memory safety (double free, use-after-free, free of non-base pointer, free of stack array, mmap'd memory, use-after-close), integer bugs (overflow, sign extension, double sizeof), resource leaks (popen/fclose mismatch, fdopendir double close), buffer handling (strncpy without NUL, copy_user size mismatch, malloc/strlen off-by-one), signal handler safety, API misuse (fcntl flag domain, SIGKILL/SIGSTOP, double byte-swap, inet_ntoa static buffer), compiler dead-store elimination, kernel IS_ERR/PTR_ERR confusion, format string injection, TOCTOU races, and more.\n- **CodeQL (8 queries)** — interprocedural taint tracking for C++ (format string injection, integer truncation, use-after-move, iterator invalidation) and Java (XXE, insecure deserialisation, log injection, Spring SSRF).\n\nBrowse the rules directly: `engine/semgrep/rules/`, `engine/coccinelle/rules/`, `engine/codeql/queries/`. These complement the Semgrep registry packs RAPTOR pulls in (`p/security-audit`, `p/owasp-top-ten`, `p/secrets` always; per-policy-group packs like `p/command-injection`, `p/jwt`, `p/xss` on top) — overlap is minimal.\n\nRAPTOR dogfoods a fair bit of its own security tooling, but it is worth being honest about what actually blocks a PR and what just runs in the background to keep us honest. Some of this is a hard gate, some of it is a scheduled check, and some of it is just a benchmark we keep around so we can tell when we have made things worse. The fuller breakdown, including the actual parameters and how to reproduce the checks, is in `docs/ci-controls.md`.\n\n| Control | What it checks | Trigger | Config / evidence | \n|---|---|---|---|\n| Ruff | Python correctness linting ( `F401` ,`F811` ,`F821` ,`F841` ) | PR diff gate, plus weekly full-tree audit | `pyproject.toml` ,`.github/workflows/lint.yml` | \n| Pytest | Fast unit/integration boundaries, subsystem-specific tiers (via import-graph dispatch), prompt-envelope audit | PRs, pushes to `main` , merge queue, scheduled full suite | `pytest.ini` ,`.github/workflows/tests.yml` ,`.github/workflows/nightly.yml` | \n| CodeQL Advanced | Python, C/C++, and GitHub Actions code scanning with import-graph scope narrowing | PRs, pushes to `main` , merge queue, weekly schedule | `.github/workflows/codeql.yml` ,`.github/codeql/codeql-config.yml` | \n| Workflow hardening | SHA-pinned third-party Actions, least-privilege permissions, command metadata linting | Every workflow change and every lint run | `.github/workflows/` ,`.github/scripts/check_command_metadata.py` | \n| Corpus label lint | Audit corpus label schema validation and upstream pin verification | PRs (changed labels), weekly full sweep | `.github/workflows/corpus-labels.yml` | \n| RAPTOR SCA PR gate | Dependency and supply-chain regressions introduced by a PR | Manifest / lockfile / workflow changes | `.github/workflows/sca-pr-gate.yml` | \n| RAPTOR SCA self-bump | Mechanical dependency hardening and safe upgrade proposals | Weekly schedule, manual run | `.github/workflows/sca-self-bump.yml` | \n| SCA compromise corpus | Whether known dependency compromises still trigger the expected signal | Weekly schedule, relevant PR changes | `test/data/sca-e2e/compromise-corpus/` ,`.github/workflows/sca-compromise-check.yml` | \n| Miswiring scan | Dead-code / wrong-call detection, env-var documentation drift, vocabulary-list guardrails, optional-dep import lint | Daily schedule | `.github/workflows/miswiring-scan.yml` ,`.github/scripts/*_baseline.json` | \n| SCA calibration + stress corpus | Whether risk scoring and parser coverage drift over time | Weekly / monthly scheduled jobs | `packages/sca/data/calibration/` ,`.github/workflows/refresh-sca-calibration.yml` ,`.github/workflows/sca-stress-sweep.yml` | \n| Dataflow corpus | Precision / recall / FP-category tracking for validator behaviour | Developer-run benchmark and corpus tests | `core/dataflow/corpus/` ,`core/dataflow/scripts/corpus-metrics` | \n| CI controls doc guard | Documented paths exist, ruff config matches, README links to the doc | PRs | `.github/tests/test_ci_controls_docs.py` | \n\nNot currently enforced: `mypy` is installed in `requirements-dev.txt` but does not block anything; Ruff formatting is not enforced; Semgrep is part of RAPTOR's scanner surface, but we do not yet have a dedicated \"scan RAPTOR with RAPTOR\" Semgrep workflow.\n\nRAPTOR has two separate model layers, and it is worth knowing how both work before you change anything.\n\nThe **orchestration layer** is always Claude Code. The CLAUDE.md, skills, and commands all run as Claude Code instructions. To change which Claude model orchestrates RAPTOR, use Claude Code's `--model` flag or the `/model` command inside a session.\n\nThe **analysis dispatch layer** is the LLM that analyses individual vulnerability findings. This is separate from the orchestration layer and can be any supported provider. Configure it in `~/.config/raptor/models.json`:\n\n```\n{\n  \"models\": [\n    {\n      \"provider\": \"anthropic\",\n      \"model\": \"claude-opus-4-6\",\n      \"api_key\": \"sk-ant-...\",\n      \"role\": \"analysis\"\n    },\n    {\n      \"provider\": \"openai\",\n      \"model\": \"gpt-5.4\",\n      \"api_key\": \"sk-...\",\n      \"role\": \"analysis\"\n    },\n    {\n      \"provider\": \"anthropic\",\n      \"model\": \"claude-sonnet-4-6\",\n      \"api_key\": \"sk-ant-...\",\n      \"role\": \"aggregate\"\n    }\n  ]\n}\n```\n\nOr skip the config file and set environment variables. RAPTOR will detect them automatically:\n\n```\nexport ANTHROPIC_API_KEY=sk-ant-...    # Anthropic Claude\nexport OPENAI_API_KEY=sk-...           # OpenAI\nexport GEMINI_API_KEY=...              # Google Gemini\nexport MISTRAL_API_KEY=...             # Mistral\nexport OLLAMA_HOST=http://localhost:11434  # Local Ollama\n```\n\nModel roles let you assign different models to different tasks:\n\n| Role | What it does | \n|---|---|\n| `analysis` | Validates and analyses each finding (Stages A-F) | \n| `code` | Writes exploit PoCs and patch code | \n| `consensus` | Second-opinion vote on true positives | \n| `aggregate` | Optional. LLM-written narrative synthesis on top of the deterministic multi-model correlation, written to `aggregation.json` and the final`agentic-report.md` | \n| `fallback` | Used if the primary model fails or hits rate limits | \n\nIf no roles are set, the first model in the list handles everything. For multi-model\nsource-code analysis, configure two or more `analysis` models — you'll get the\ndeterministic correlation by default. The `aggregate` role is optional and adds an\nLLM-written summary on top:\n\n```\npython3 raptor.py agentic --repo /code \\\n  --model claude-opus-4-6 \\\n  --model gpt-5.4 \\\n  --aggregate claude-sonnet-4-6\n```\n\nBudget control:\n\n```\n# Cap analysis-layer LLM spend at $5 for this run (default: $10)\npython3 raptor.py agentic --repo /code --max-cost-usd 5.00\n```\n\nOllama works for analysis but produces unreliable exploit and patch code. For code generation tasks, use a frontier model.\n\nWhen your analysis-tier model has a same-provider cheaper sibling (Anthropic Opus → Haiku, OpenAI 5.x → 4o-mini, Gemini Pro → Flash-Lite, Mistral Large → Small), RAPTOR will use it as a prefilter on consumers that wire into the substrate (codeql today; SCA and others as follow-ups land). The cheap model only ever short-circuits on **confident false positives**; ambiguous cases and confident-TPs always run the full analysis. Trust accumulates per `(model, decision_class)` cell — RAPTOR records cheap-vs-full agreement and only short-circuits once the Wilson 95% upper-bound on the cell's miss-rate falls at or below 5%.\n\nTo inspect what your models are good at, use `/scorecard` (or directly: `libexec/raptor-llm-scorecard list`). The scorecard is global (lessons carry across projects) and persists at `out/llm_scorecard.json`.\n\nWithout a project, each run gets its own timestamped directory under `out/`. With a project, everything goes into one place and you get merged findings, coverage tracking, and diffs between runs.\n\n```\n/project create myapp --target /path/to/code -d \"Short description\"\n/project use myapp\n\n/scan\n/understand --map\n/validate\n\n/project status                # all runs, pass/fail, timestamps\n/project findings              # merged findings across all runs\n/project findings --detailed   # per-finding detail\n/project coverage --detailed   # which files were reviewed\n/project diff myapp run1 run2  # compare two runs\n/project report                # full merged report\n/project clean --keep 3        # remove old runs, keep the last 3\n/project export myapp /tmp/myapp.zip\n/project none                  # clear active project\n```\n\nRAPTOR is two layers.\n\nThe **Python execution layer** (`raptor.py`, `packages/`, `core/`, `engine/`) handles the heavy lifting: running Semgrep and CodeQL, managing subprocesses, parsing SARIF, deduplicating findings, dispatching LLM API calls, tracking costs, writing output files. It does not make decisions. It executes.\n\nThe **Claude Code decision layer** (`.claude/`, `tiers/`, `CLAUDE.md`) makes the calls: which findings to prioritise, how to interpret results, what the attack scenario is, whether the exploit is realistic. Implemented as Claude Code skills, commands, and agents that load progressively.\n\n```\nCLAUDE.md              always loaded -- bootstrap, routing, security rules\n.claude/commands/      slash commands (/agentic, /scan, /validate, etc.)\n.claude/skills/        methodology detail, loaded on demand\ntiers/                 adversarial thinking, recovery, expert personas\n.claude/agents/        specialist sub-agents (offsec, crash analysis, forensics)\n```\n\nThe split means you can run the Python layer from a CI pipeline (`python3 raptor.py scan --repo ...`) and get structured SARIF output without Claude Code, or run it interactively with the full agentic workflow.\n\n`/oss-forensics` investigates public GitHub repositories using evidence from multiple sources: the GitHub API, GH Archive (immutable event history via BigQuery), the Wayback Machine, and local git history. It runs a structured pipeline from evidence collection through hypothesis formation to a final forensic report.\n\nRequires `GOOGLE_APPLICATION_CREDENTIALS` for BigQuery access. See `.claude/commands/oss-forensics.md` for details.\n\nSeven expert personas are available on demand. Load one when you want a different perspective on a finding or a specific technique:\n\n```\nExploit Developer (Mark Dowd)                  Exploit PoC generation\nCrash Analyst (Charlie Miller / Halvar Flake)  Crash analysis and exploitability assessment\nSecurity Researcher                            General adversarial code review\nPatch Engineer                                 Secure fix generation\nPenetration Tester                             Realistic attack scenario assessment\nFuzzing Strategist                             Corpus design and triage\nBinary Exploitation Specialist                 ROP, heap, and memory corruption\n```\n\nTell Claude which one to use, e.g. \"Use the Binary Exploitation Specialist\".\n\nSee `docs/README.md` for the full index. Key guides:\n\n| File | Contents | \n|---|---|\n| `docs/commands.md` | Complete slash-command reference with every flag | \n| `docs/architecture.md` | Codebase structure and directory tree | \n| `docs/llm.md` | LLM provider configuration, Bedrock, multi-model workflows | \n| `docs/sandbox.md` | Process isolation: profiles, Landlock, namespaces | \n| `docs/audit.md` | Systematic code review: hypotheses, tools, strategies, gates | \n| `docs/validation.md` | Exploitability validation pipeline (stages 0--1) | \n| `docs/static-analysis.md` | Semgrep and Coccinelle rules | \n| `docs/codeql.md` | CodeQL integration and autonomous analysis | \n| `docs/binary-analysis.md` | Binary oracle, `/binary` , exploit feasibility | \n| `docs/fuzzing.md` | AFL++ and libFuzzer | \n| `docs/crash-analysis.md` | Autonomous crash root-cause analysis | \n| `docs/sca.md` | Software composition analysis | \n| `docs/frida.md` | Dynamic instrumentation | \n| `docs/security.md` | RAPTOR's own security model | \n| `docs/ci-controls.md` | CI controls, workflows, and benchmark evidence | \n| `docs/threat-model.md` | Per-project threat model feature | \n| `docs/python-cli.md` | Python CLI reference for scripting and CI | \n| `docs/concepts.md` | Core concepts: two-layer model, finding lifecycle, choosing a command | \n| `docs/agentic.md` | Autonomous workflow: `/agentic` pipeline, enrichment flags, multi-model | \n| `docs/sage.md` | SAGE persistent memory: setup, HMAC key, CPU/GPU, use cases | \n| `docs/dependencies.md` | External tools, versions, and licences | \n| `tiers/personas/README.md` | Expert persona reference | \n\nRAPTOR is open source. Good places to start if you want to contribute:\n\n- Browser-engine crawling and DOM XSS coverage for the web scanner (Playwright is pinned but unused)\n- SSRF rule coverage for annotation-driven frameworks (Spring `@RequestParam` , FastAPI typed params) — semgrep cannot match these sources, so alternative approaches are welcome\n- YARA signature generation\n- Ports to other AI coding tools (Cursor, Windsurf, Copilot, Cline)\n- Better firmware analysis coverage\n- Anything you think is missing\n\nReleases are tagged as `vX.Y.Z` and built automatically by CI. Commit prefixes determine what goes in the changelog: `feat:` for new features, `fix:` for bug fixes, `security:` for security changes, `docs:` for documentation. Anything without a prefix lands in \"Other changes\". No strict convention required, but it helps.\n\nSubmit pull requests. Chat with us on the **#raptor** channel in the Prompt||GTFO Slack:\n[https://join.slack.com/t/promptgtfo/shared_invite/zt-3v2b4sll3-SfyzFRw2lykx_XQX7F3uNQ](https://join.slack.com/t/promptgtfo/shared_invite/zt-3v2b4sll3-SfyzFRw2lykx_XQX7F3uNQ)\n\nMIT -- Copyright (c) 2025-2026 Gadi Evron, Daniel Cuthbert, Thomas Dullien (Halvar Flake), Michael Bargury, John Cartwright.\n\nSee LICENSE for the full text. Review the licences for all dependencies before commercial use -- CodeQL in particular does not permit it.", "url": "https://wpnews.pro/news/raptor-turns-claude-code-into-a-general-purpose-ai", "canonical_source": "https://github.com/gadievron/raptor", "published_at": "2026-09-07 09:24:37+00:00", "updated_at": "2026-09-07 09:58:45.159489+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-tools", "ai-agents", "ai-research"], "entities": ["Gadi Evron", "Daniel Cuthbert", "Thomas Dullien", "Michael Bargury", "John Cartwright", "Claude Code", "Anthropic", "RAPTOR"], "alternates": {"html": "https://wpnews.pro/news/raptor-turns-claude-code-into-a-general-purpose-ai", "markdown": "https://wpnews.pro/news/raptor-turns-claude-code-into-a-general-purpose-ai.md", "text": "https://wpnews.pro/news/raptor-turns-claude-code-into-a-general-purpose-ai.txt", "jsonld": "https://wpnews.pro/news/raptor-turns-claude-code-into-a-general-purpose-ai.jsonld"}}