Delegating Code Security to Agents: Claude Code's New Security Plugin

Enterprise software teams have long had a gap in their security toolchain. Static analysis tools work on rules: they catch known patterns, but they can't judge whether a vulnerability is actually exploitable or what it means within the architecture as a whole. Anthropic's Claude Security plugin for Claude Code targets exactly that gap — examining a codebase not through individual rules, but through a multi-agent process that mirrors how a security researcher reasons.

What the plugin does

Claude Security is a plugin that runs inside a Claude Code session. It installs from the official Anthropic marketplace with a single command, and the scan runs entirely in the local session; each scan counts against the user's plan limits.

The plugin adds one command, which opens three jobs: scanning the entire codebase, scanning only a set of changes (a branch diff, a pull request diff, or a single commit), and turning findings into patches. On large repositories, instead of scanning the whole tree, a focused area such as the API layer or authentication code can be selected; the report then states explicitly what was and wasn't examined.

Nothing runs before the user confirms. The plugin openly states that a scan may take a while and may consume a significant number of tokens — a meaningful design choice for cost predictability in enterprise use.

How the agent team works

The plugin's distinguishing feature is that it distributes the scan across a team of agents rather than a single model. The process first maps the architecture, then builds a threat model, then hunts for vulnerabilities. The critical step comes last: every finding is reviewed by independent verifier agents before it enters the report.

That separation matters in practice. The classic problem with automated security tools is that false positives make the report unreadable. Admitting findings only after independent verification is aimed at keeping the report short and worth reading.

Results are written into a timestamped directory inside the repository: a human-readable report, a machine-readable line-based JSON file, and a revision stamp. That stamp records which commit was scanned, at what effort, and how thoroughly it was verified — meaning every report stays tied to the exact code state it describes. From an audit-trail perspective, that record is arguably worth more than the security report itself.

One caveat is stated plainly: scans are not deterministic. Two scans of the same code can surface different findings. Regular scanning is therefore recommended.

From finding to patch: the decision stays with you

The plugin's second stage turns selected findings into patches. The same separation logic applies here: an agent independent of the one that wrote the patch reviews the resulting change. If the project has tests, they are run against the patch; the diff is also read on its own terms.

A patch is only written when that review can vouch for three things at once: the change addresses only the finding in question, it introduces no new vulnerability, and it otherwise leaves behavior unchanged. When all three can't be confirmed, the user receives a short explanatory note instead of a patch.

The most important design decision, though, is this: patches are never applied automatically. Each patch lands as a separate file in the report folder, and applying it is entirely the user's call. Patches are drafted in a scratch copy of the repository, so source files stay untouched until the user acts. Anthropic recommends applying each patch in its own pull request.

There's another safeguard against stale reports: when a patch is built, the finding in the report must still describe the code as it exists. Findings whose code has since changed are skipped, and a fresh scan is offered instead.

The trust boundary: your code, or someone else's?

One of the most notable parts of the documentation is where it states plainly what the plugin was not designed for. It is built for scanning code you control — scenarios where the question is which bugs are in the code, not whether the code itself is trying something.

The reason is technical: the scan runs in the user's own session, under the user's permissions, and adds no isolation of its own. The repository's settings, hooks, and instruction files apply exactly as they would in any other session. The system treats everything the repository says — code, comments, findings text — as data under review rather than instructions; but Anthropic states directly that this is not a defense against a hostile repository.

For users who want to scan an untrusted codebase, such as a third-party dependency, the recommended path is to run the entire session inside a sandbox that enforces filesystem and network restrictions at the operating-system level.

That transparency is increasingly rare in AI product messaging: naming the tool's boundary before the user hits it.

Part of a layered security approach

The plugin isn't positioned as a standalone solution. Anthropic frames it as one specific layer in a defense-in-depth stack:

• In session: The security guidance plugin catches common vulnerabilities in code Claude writes, fixed in the same session.
• On demand, single pass: The `/security-review` command runs a one-time security pass over the current branch.
• On demand, deep scan: The Claude Security plugin — the multi-agent, independently verified, patch-producing layer.
• At pull request time: Code Review performs correctness and security review with full codebase context (Team and Enterprise plans).
• Managed: The Claude Security product on the Enterprise plan continuously monitors connected repositories.
• In CI: Existing static analysis and dependency scanners, language-specific rules, and supply-chain checks.

The plugin also has one advantage over the managed product: because it runs locally, it reaches places the managed service can't — repositories hosted on GitLab or Bitbucket, or networks that don't allow inbound connections.

Anthropic's insistence that the plugin doesn't replace existing tools is technically the right framing. Static analysis is deterministic; it returns the same output for the same input, which is indispensable for compliance processes. The plugin, by contrast, reads and reasons about code in context. The two aren't competitors — they're complements.

Conclusion: the scale problem in security review

What this plugin points to is broader than a feature list. Security review is one of the few steps in software development that bottlenecks because it demands expertise. As code generation accelerates with AI tooling, keeping review at human speed isn't sustainable.

Anthropic's approach tries to solve that bottleneck not through automation but through division of labor: scanning, verification, and patch writing are distributed across different agents; each stage is audited by another; and the final link in the chain — the decision to apply — is deliberately left to a person.

That is the real question in bringing AI agents into enterprise workflows: where does the machine decide, and where does the human approve. The Claude Security plugin gives a clear answer — the analysis belongs to the agent, the decision belongs to the user.