Claude Security (beta): Multi-agent vulnerability scanner for Claude Code that drafts .patch files

Before you hit commit: Anthropic’s Claude Security brings multi-agent scans and draft .patches into Claude Code (beta)

If you’ve ever paused mid-commit wondering whether a tiny change opened an SQL injection or leaked a secret, Claude Security aims to be that safety net inside your Claude Code session. Released in beta, the plugin adds a /claude-security command that runs an in-session, multi-agent vulnerability scan (full repo or scoped diffs), produces a timestamped report, and writes draft .patch files for human review rather than changing your repo automatically.

Quick technical pointers (install, repo, outputs)

Install: run /plugin install claude-security@claude-plugins-official then /reload-plugins. If the marketplace is missing, the docs note you can add it with /plugin marketplace add anthropics/claude-plugins-official. See Anthropic’s docs for the step-by-step flow: code.claude.com, Claude Security.
Repo and source: the plugin’s public code is in Anthropic’s plugins repo: github.com/anthropics/claude-plugins-official/plugins/claude-security (the repository lists the plugin at version 0.10.0 in its files at the time of writing).
Outputs: scans write a timestamped directory named CLAUDE-SECURITY-<timestamp>/ containing human- and machine-readable artifacts (CLAUDE-SECURITY-RESULTS.md, CLAUDE-SECURITY-RESULTS.jsonl, CLAUDE-SECURITY-REVISION-*.json). Draft patches appear in a patches/ folder; they must be applied by you (git apply or create a PR with your authorization).

What it does, in plain terms

Type /claude-security inside Claude Code and you get a small menu with three jobs:

Scan codebase, scan the whole repository or a scoped subset;
Scan changes, scan a branch diff, a pull request diff, or a single commit;
Suggest patches, convert selected findings into draft .patch files for review.

Anthropic’s documentation covers the interactive prompts, an estimated scan cost and size step, and the requirement that a Claude Code session remain open while the scan runs. The plugin is conservative by design. It generates suggested fixes but does not apply them without your explicit action. The docs also describe an auto mode that lets agents proceed without step prompts when you enable it.

Where this fits in your security toolchain

Claude Security acts as a deep-scan layer that complements deterministic tools like SAST, dependency scanners, and CI gates. It reasons about semantics, proposes contextual fixes, and produces artifacts you can feed into triage workflows. Use it when you want explainable findings and suggested remediations. It is not a replacement for static scanners or SBOM-based supply-chain checks.

How the scanner organizes work (and why that design matters)

The plugin uses dynamic orchestration that fans work across smaller agent roles. The public repository contains orchestration and workflow logic that partitions a scan into multiple phases and roles. The repo is the place to inspect those scripts and the report schema.

The workflow splits responsibilities into discovery, modeling, targeted research by security theme, gap-filling sweeps, independent verification, and adversarial review. The plugin’s code declares these stages and the team-sized parameters that scale scans from small diffs to larger components.

Research is scoped to fixed security lenses such as input/injection, auth/access, memory/unsafe, and crypto/secrets. For components the workflow can omit the memory lens when the inventory marks them as memory-safe. For large repos you can pick an effort tier (low, medium, high, max) that controls how many components and researchers the scan spawns. The orchestration scripts in the repo show those operational parameters and caps.

Multi-agent verification: how a candidate finding earns its spot

The plugin requires independent checks before a candidate becomes a report item. In the repository’s verification logic, each candidate is re-assessed by multiple verifier roles that evaluate reachability, impact, and defenses. Verifiers return structured verdicts and point to decisive file:line locations. A quorum is required to keep a finding. The report renderer computes vote tallies and sets the revision stamp’s verification status accordingly.

Key mechanics (as implemented in the plugin code):

Each finding is reviewed by three verifier lenses that return structured TRUE_POSITIVE / FALSE_POSITIVE verdicts and reference decisive file:line evidence.
The keep quorum is 2 of 3, at least two verifiers must mark a finding true for it to be included.
Confidence ceilings derive from the panel vote: unanimous 3/3 permits a higher confidence label; 2/3 caps confidence at a lower level. The renderer (Python) tallies votes and the revision stamp’s verification.status is set to verified only when the vote record proves the panel ran for every finding; otherwise it is marked unverified with a stated reason.

No single agent’s assertion is final. The multi-verifier panel and the recorded vote trail are meant to reduce one-off model errors. The vote tally and verification stamp live in the report artifacts so teams can audit how each finding was decided.

Models, permissions, and the read-only posture

Anthropic’s docs and the plugin code show a model-tiering approach. Orchestration and mapping roles may run on different model tiers, and researchers and verifiers inherit the session model. The plugin enforces a conservative execution posture. Scans write only the results directory in your working tree by default, and patches are generated in a scratch copy for independent review and test runs.

The docs say PR and diff scans require a signed-in GitHub CLI session (gh) when PR discovery is needed. That means CI agents or a user session must provide credentials for PR scanning. The repository makes clear the plugin intends to keep scan agents from mutating your primary checkout, but details about enforcement, sandboxing, tool whitelists, or runtime policy are implementation-level questions. Verify those specifics in the code and with Anthropic if you need formal attestations.

Practical pilot checklist, how to try this safely

Scope your pilot: pick a mid-sized non-sensitive repo or a feature branch. Use “Scan changes” for diffs to keep runs fast and repeatable.
Enable revision stamping and store the report artifact intentionally for audits, the project’s default behavior is to .gitignore the report directory to avoid accidental commits.
Authorize PR discovery intentionally: if you want PR scanning, ensure the session or CI runner has a signed-in gh CLI with the minimal scope required.
Validate patches in CI: treat generated .patch files as suggestions. Run them in a disposable test job before applying to mainline branches.
Measure nondeterminism: run the same scoped scan multiple times, archive the CLAUDE-SECURITY-REVISION-*.json files, and compare results to understand variability for your codebase.
Ask Anthropic about data handling and retention: confirm whether code or artifacts leave your control, retention windows, and any enterprise attestations you require (SOC2, contract terms).

Operational questions the docs don’t fully answer (and why they matter)

Data handling and retention: important for compliance and incident forensics, does scanned code or derived artifacts persist offsite? Ask for documentation and contractual terms.
Read-only enforcement: the plugin writes only a results directory by default, but how are write actions prevented technically? For high-assurance environments, ask for specifics (sandboxing, tool whitelists, runtime policy).
Performance at scale: token and compute costs and scan latency for very large monorepos aren’t documented publicly. Request sample timing or cost guidance for repos of your size.
Integration surface: the plugin produces JSONL and patch files, but if you want direct CI gating or automated issue creation, plan to write small adapters or ask Anthropic about integrations.

These operational details determine whether Claude Security can be part of an automated gating pipeline or should remain an on-demand human-assisted tool in your triage workflow.

Quick illustrative example (representative, not verbatim from a run)

Below is a simplified mock of the shape of a finding and a draft patch so you can picture the artifacts you’ll receive:

Finding (excerpt):
File: services/db/query.go:127, Possible SQL injection via un-sanitized fmt.Sprintf on user input. Panel votes: REACHABILITY=TRUE_POSITIVE (file:127), IMPACT=TRUE_POSITIVE (file:127), DEFENSES=FALSE_POSITIVE (file:127). Kept (2/3), confidence: medium.

Draft .patch (excerpt):
— a/services/db/query.go
+++ b/services/db/query.go
@@ -124, 7 +124, 9 @@ func buildQuery(userInput string) string {
– q := fmt.Sprintf(“SELECT * FROM widgets WHERE name = ‘%s'”, userInput)
+ q := “SELECT * FROM widgets WHERE name = $1”
+ rows, err := db.Query(q, userInput)
+ // use parameterized query to avoid injection
return q
}

Use CI to run tests against patched code in an isolated environment before applying to main branches.

Procurement / security checklist for pilots

Request written data-handling and retention policies from Anthropic (where is code processed and how long are artifacts kept?).
Confirm whether the plugin’s agent execution is auditable (full vote records in revision JSON?) and whether logs are exportable to your SIEM.
Ask for recommended scopes for gh CLI credentials when enabling PR scans (least privilege principle).
Request guidance on cost and latency for representative repos, include token and compute cost estimates if you plan regular scans.
Confirm SLAs, support, and enterprise contract terms if you plan to use this on production-sensitive codebases.

Why business leaders should care, and what to expect

Claude Security brings AI-based reasoning and patch drafting into developer workflows while trying to preserve human control. For security teams it promises deeper, contextual checks and faster triage artifacts. For engineering leaders it can shift part of the remedial drafting workload from senior engineers to a model-assisted pipeline.

Expect trade-offs: the tool’s nondeterminism affects repeatability.