Claude Code Security Plugin — A Multi-Agent Vulnerability Scanner in Your Terminal

by Persephone

Anthropic launched the Claude Code Security plugin in beta on 2026-07-22: a 6-phase multi-agent vulnerability scanner (Opus orchestrator, Sonnet cartographer) that runs a 3-lens adversarial panel — REACHABILITY, IMPACT, DEFENSES — on every candidate finding, with 2-of-3 quorum and confidence hard-capped by quorum. Tally is computed in Python by the report renderer, not by the model that produced the findings, so a finding cannot enter the report unless the vote record proves the panel ran.

Claude Code Security Plugin — A Multi-Agent Vulnerability Scanner in Your Terminal

July 24, 2026

A finding in the new Claude Code Security plugin report cannot exist unless a 3-lens adversarial panel voted it into the report, and the confidence field on that finding is hard-capped by the size of that majority — a 2-of-3 vote is mathematically incapable of claiming “high” confidence (code.claude.com/docs/en/claude-security). That is not a sentence you will read about Snyk, Semgrep, or any of the static-analysis tools currently sitting in CI pipelines. Anthropic launched the Claude Code Security plugin in beta on July 22, 2026, and the design decision worth talking about is not the multi-agent architecture — it is the part where the model that produced a finding is structurally forbidden from certifying it.

What it actually does

/plugin install claude-security@claude-plugins-official — that’s the install. Source is the claude-plugins-official monorepo at v0.10.0 (github.com/anthropics/claude-plugins-official/tree/main/plugins/claude-security). The plugin ships three commands:

  • /claude-security:scan codebase — full inventory sweep of the working tree
  • /claude-security:scan changes — diff-only sweep over a branch, PR, or single commit
  • /claude-security:suggest patches — concrete patch drafts for the findings the panel kept

The output lands in a timestamped CLAUDE-SECURITY-<timestamp>/ directory containing three artifacts: a human-readable CLAUDE-SECURITY-RESULTS.md with F1/F2-style IDs, severity, CWE, sink line, exploit scenario, and recommendation; a machine-readable CLAUDE-SECURITY-RESULTS.jsonl; and a CLAUDE-SECURITY-REVISION-<hash>.json whose verification.status is "verified" only when the vote record proves the panel ran for every finding (Cybersecurity News, 2026-07-23).

The 6-phase workflow

Under the hood, every scan runs the same six phases in order, regardless of effort tier (code.claude.com/docs/en/claude-security; MarkTechPost, 2026-07-22):

  1. Inventory — model the codebase as a graph of components
  2. Threat model — derive which components are in scope
  3. Research — fan out the research categories across those components
  4. Sweep — read-only scan agents inspect each component
  5. Panel — 3-lens adversarial vote on each candidate finding
  6. Adversarial — stress-test the surviving findings

The interesting bit is that the research phase is not a uniform shotgun blast. Four research categories exist — injection-and-input, auth-and-access, memory-and-unsafe, crypto-and-secrets — and the memory-and-unsafe lens is dropped entirely for components that are written in memory-safe languages. A Rust crate is not going to be scanned for use-after-free. A Go service is not going to be scanned for buffer overflow. That is not a marketing line — it is a phase-aware research category selection that changes the actual scan surface per component (MarkTechPost, 2026-07-22).

Four effort tiers, four model tiers, one read-only boundary

Four effort tiers (low / medium / high / max) gate two things: component count — low/medium inspect 12 components, high/max inspect 24 — and researcher parallelism — low/medium run one researcher per cell, high/max run two. The 4-tiers-by-2-dimensions design means the same tool can be tuned for a 30-second pre-commit check or a multi-hour CI sweep.

The model tiering is what makes this practical to run inside a real engineering workflow:

  • Orchestrator: Opus
  • Cartographer + read-only code explorer: Sonnet
  • Scan agents: restricted to read-only tools only (no write, no exec)

That last bullet is the one that should land on a security reviewer’s desk. The agents that touch your code cannot write to your code, cannot execute shell, cannot mutate state. The surface they can affect is the report directory and nothing else (claude.com/product/claude-security; code.claude.com/docs/en/claude-security).

The verification moat

Every competitor in this space — Snyk Deep Code, Semgrep, Codacy, the static-analysis suites inside GitHub Advanced Security — produces findings whose confidence is asserted by the system that produced them. The Claude Security plugin does something structurally different.

Three lenses, each with a single vote. REACHABILITY asks “can an attacker actually hit this sink?” IMPACT asks “if they do, how bad is it?” DEFENSES asks “what’s already in the way?” Each lens votes independently, and a candidate finding only survives the panel with 2-of-3 quorum (code.claude.com/docs/en/claude-security).

Confidence is a function of quorum size, not a free parameter. A 3-of-3 finding can claim high confidence. A 2-of-3 finding cannot — by architectural design, the confidence field on a 2-of-3 finding is capped. The model that ran the analysis cannot decide its own confidence score, and cannot move a finding from “rejected” to “kept” without a vote majority it doesn’t control.

Tally is computed in Python by the report renderer, not by the model. The same model that hallucinated a finding cannot hallucinate the panel’s vote record. If the vote record doesn’t match the findings, verification.status stays at "unverified" and the revision is invalid. This is the rare security tool where the audit trail is the report, not an out-of-band log you have to reconcile against the tool’s output.

Compare that to a typical Snyk or Semgrep run: the tool emits findings, the CI step emits a status, and the two are correlated by timestamp. There is no per-finding quorum. There is no structural guarantee the engine that emitted a finding was not also the engine that certified it.

Why this fits security better than code generation

Multi-agent for code generation is mostly a throughput and specialization story — one agent writes tests, one writes docs, one writes the implementation, and a critic agent reviews. The architecture works because the artifact is text and the success criterion is “does the diff look right to a human reviewer.”

Multi-agent for security has a much harder success criterion: the absence of a finding has to be defensible. A scanner that reports “clean” is making a claim about the entire codebase, and that claim needs to be auditable. The 3-lens panel + quorum + Python-tallied verification record are what turn “Anthropic’s scanner said the code is clean” into something a security team can actually file in a control matrix. The architectural choice that is mostly cosmetic in a coding assistant is load-bearing here.

What to actually do this week

If you are running Claude Code today:

  1. Install the plugin. /plugin install claude-security@claude-plugins-official. Beta is live across all Claude Code tiers (claude.com/product/claude-security).
  2. Start with scan changes on your last merged PR, not scan codebase on the whole repo. The diff sweep is the cheapest place to see what the panel actually keeps vs. drops — that’s where you learn the tool’s tolerance, not in a 30-minute full-repo sweep.
  3. Read the verification.status field before trusting the report. If the revision JSON does not say "verified", the panel did not run on every finding and the results are not auditable. Do not file them as control evidence.
  4. Pin medium effort for CI. Low effort (12 components, 1 researcher/cell) is fine for pre-commit; high or max (24 components, 2 researchers/cell) is what you want for nightly. Don’t run max on PR builds — the latency cost is real.
  5. Compare a finding the panel kept to a finding the panel dropped. The dropped finding’s vote record is in the revision JSON and tells you more about the tool’s threat model than the kept one does.

The Claude Code Security plugin is not going to replace Semgrep in CI tomorrow. It is, however, the first vulnerability scanner shipped by a frontier lab where the verification claim is structurally enforced rather than asserted. That distinction is what to watch as the beta matures.

Sources