Claude Security Plugin: a vulnerability scanner in your terminal
Anthropic released the Claude Security Plugin in beta — a multi-agent vulnerability scanner for Claude Code. How it works, where it helps, what it won't replace.
- AUTHOR
- Karol Rapacz / CEO of Breachroad · OSCP · PNPT
- PUBLISHED
- 26 July 2026
- READING TIME
- 16 min read
- TOPIC
- AI Security
On 23 July 2026 Anthropic released a beta of a tool worth a closer look: the Claude Security Plugin for Claude Code. In short, it works like this — from inside an existing terminal session you launch a multi-agent vulnerability scan of a repository, and the findings you select are turned into patch files for you to review and apply yourself. You can scan uncommitted changes before a commit, or run an analysis of the whole codebase without leaving your existing workflow.
The plugin is available in beta to all Claude Code users. Below we take it apart: what it actually does, how it differs from classic SAST, where it’s most useful, what its limits are — and most importantly, how to fit it into a process so it doesn’t become a generator of false confidence.
What the plugin actually does
Three elements of the vendor’s description matter, because each carries practical consequences.
Multi-agent operation. The scan isn’t a single pass by one model but the work of multiple agents. In practice that lets tasks be split — one agent can hunt for flaws in authentication handling, another in database queries, another can trace data flow from user input. That increases coverage and reduces the risk that a single “line of thinking” misses an entire class of problem.
Running inside a Claude Code session. This isn’t a separate product with its own dashboard, but an extension of a tool the developer already uses. The consequence is bigger than it sounds: friction disappears. Historically the biggest problem with security tooling wasn’t detection quality but that it required leaving the workflow — so it got used rarely or never.
Findings → patch files. The tool doesn’t stop at a report. For selected findings it generates a proposed fix as a patch, which a human reviews and applies. That design is right: the model proposes, the human decides. There’s no automatic modification of code without review — which is good, because automatically “fixing” security without verification can be more dangerous than the original bug.
How this differs from classic SAST
Let’s compare it with the tools teams already have in their pipelines.
| Property | Classic SAST | LLM-based scanner |
|---|---|---|
| Basis of operation | rules, patterns, flow analysis | understanding code in context |
| False positives | many, especially untuned | fewer repetitive ones, but confabulation possible |
| Novel/unusual patterns | poor — no rule, no finding | better — needs no prior rule |
| Business logic | essentially undetected | has a chance of detecting it |
| Repeatability | high (same code → same result) | lower (variance possible) |
| Finding rationale | reference to a rule | natural-language explanation |
| Proposed fix | rare or templated | concrete, in-context patch |
The biggest advantage of the model-based approach is detecting business-logic problems — the class of bug where classic tooling fails hardest. A rule-based scanner will happily find string concatenation in a SQL query, but won’t notice that a given endpoint never checks whether the logged-in user owns the object they’re accessing. And broken access control has topped real-world vulnerability rankings for years — we covered it in our guide to the OWASP Top 10 for web applications.
The biggest weakness is repeatability and susceptibility to confabulation. A model may describe a convincing-sounding vulnerability that doesn’t exist, or miss a real one on the next run. So don’t treat output as a verdict but as a hypothesis to confirm — exactly the discipline we described with models finding 0-days, where the crucial step was a human reproducing the bug.
Where it genuinely helps
Before a commit, on changed code. This is the strongest scenario. Scanning only the diff is fast, the context is fresh, and the cost of fixing is the lowest in the entire lifecycle. A bug caught before commit costs minutes; the same bug found in production by an external researcher costs an incident.
As a second pair of eyes in code review. Human reviewers usually focus on functional correctness and readability; security tends to be the third priority, especially under deadline pressure. Automated, context-aware flagging of risky spots complements human review well.
In high-risk areas. Authentication and authorisation, file handling, deserialisation, database queries, building system commands, concurrency. These are where a bug has the greatest consequences — and where it’s worth deliberately spending an extra analysis pass.
In legacy code without tests. Old code nobody wants to touch is a rewarding target for machine analysis: grinding through thousands of lines is exactly the kind of work models are currently good at and where humans lose focus quickly.
What it won’t replace
Honesty is needed here, because marketing around AI security tooling tends to be generous.
It won’t replace penetration testing. A scanner sees code. It doesn’t see the running system: server configuration, headers, how it was deployed, interactions between services, cloud permissions, or what happens when three components meet in production. A huge share of real vulnerabilities stem not from a coding error but from how the code was deployed and connected. We laid out the differences between assurance types in penetration test vs audit vs scan.
It won’t replace threat modelling. The tool answers “is there a bug in this code”, not “are we designing this correctly at all”. Architectural decisions — where the trust boundary runs, what we authenticate, how we isolate components — are made before the first line of code exists. That’s the domain of threat modelling.
It won’t replace dependency analysis. The biggest risk in modern projects often isn’t your own code but the hundreds of packages you pull from registries. An application code scanner won’t answer the question of a malicious package in the supply chain — as the Mini Shai-Hulud worm in npm and PyPI painfully reminded us.
It won’t replace secrets or configuration management. Detecting a hardcoded key in code is valuable, but doesn’t solve rotation, scoping and storage — which we cover in secrets management.
Risks to consider before rollout
It’s a security tool, but deploying it has security implications of its own. Four things to think through in advance.
Where your code goes. Analysis requires processing source code. Before you scan a client repository or a system covered by an NDA, establish the data-processing terms and obtain consent. That isn’t a formality — it’s a basic contractual requirement in most commercial projects.
False confidence. The biggest organisational risk sounds like: “we scanned it with Claude, it’s clean.” A green result means only that the tool found nothing — not that the code is secure. Write that distinction into your process before someone uses a scan as an argument for skipping a pentest.
Automatic patches without understanding. The plugin generates patches for review, which is a good design decision — but only if the review is real. Applying a proposed fix nobody understands shifts risk rather than removing it. Security fixes can be subtle, and it’s easy to break application logic with one.
Prompt injection via analysed code. This risk is specific to LLM-based tooling: the analysed file may contain content addressed to the model (in a comment, a string, a README) attempting to influence its behaviour. When scanning third-party code — libraries, forks, external contributions — that’s a realistic scenario. Treat analysed code as untrusted data and results as requiring verification; we describe the mechanics of this attack class in our prompt injection guide.
How to verify a single finding
Since a model’s output is a hypothesis, you need a repeatable procedure for checking it. The order below usually takes a few minutes per finding and protects against two errors at once: dismissing a real vulnerability and fixing a non-existent one.
1. Check whether the code is reachable at all. Before assessing the mechanics, establish whether the flagged function is called from any externally reachable path. Dead code, a function used only in tests, or a branch unreachable under current configuration drops the priority to nearly zero.
2. Trace the data source. The key question: does the data arriving here come from a user or an external system? If the value is constant or comes from trusted internal configuration, the finding is usually false. If it passes through an HTTP request, a queue, a file or an integration — it’s real.
3. Verify existing safeguards. Models can be overzealous when validation lives in another layer — middleware, a decorator, an input filter, or the ORM. Check the whole path, not just the flagged fragment.
4. Reproduce the behaviour. The strongest evidence is a test. Write a case reflecting the described scenario and check whether the application really behaves as the model claims. If confirmed, you have a regression test for the future — valuable in itself.
5. Assess impact, not bug class. The same class can mean entirely different things depending on context. An injection in a locally run admin tool and one in a public endpoint are two different priorities despite an identical label.
6. Record the decision. Both “we’re fixing this” and “dismissed as false positive” deserve documenting with a rationale. Otherwise the next scan regenerates the finding and the team repeats the same discussion from scratch. A decision log is what separates a process from a one-off exercise.
The wider context: the year AI entered vulnerability work
This release isn’t isolated — it fits a clear 2026 trend. In recent months we’ve seen a real Linux kernel 0-day found with a model’s help, automated security detections built into code review on hosting platforms, and the growth of tools that localise vulnerabilities in large codebases.
The direction is unambiguous: security code analysis is becoming cheaper and more accessible. For defenders that’s good news — with one caveat. The same technology lowers the cost of finding bugs on the attacker’s side too. The advantage therefore goes not to whoever has access to the tool, but to whoever closes the window between finding a bug and fixing it faster.
Frequently asked questions (FAQ)
Will this replace our current SAST? More likely complement it. Classic SAST provides the repeatability needed for CI gates and is predictable; a model-based tool handles business logic and unusual patterns better. A sensible rollout uses both, in different roles.
Can I run it on client code? Only after establishing processing terms and obtaining consent. Analysis requires processing source code, which for commercial and NDA-covered projects is a contractual question, not a technical one. Settle it before the first scan, not after.
Does a green result mean the code is secure? No. It means the tool found nothing on that run. Absence of findings is never proof of absence of vulnerabilities — neither with a rule-based scanner nor with a model. Worth writing into policy, because in practice it gets abused.
Can generated patches be applied automatically? We’d advise against it. The tool deliberately leaves the decision to a human. Security fixes can be subtle, and a change nobody understands can move the problem elsewhere or break business logic. Reviewing the patch is part of the process, not a formality.
Where should we start if we want to trial it? With one moderate-risk repository, comparing results against what your current stack finds. Watch three things: how many findings proved real after verification, whether new bug classes appeared that you weren’t finding before, and how long verification took. If you want an independent assessment of application and process security — get in touch.
Summary
The Claude Security Plugin is a sensibly designed tool: it works where the developer already is, reduces friction to zero, detects bug classes that are hard for rule-based tooling, and leaves the last word to a human by generating patches for review rather than applying them itself.
Its right place is shifting security left — catching bugs before commit, when fixing is cheapest. Its wrong place is being treated as proof of security or a substitute for independent assurance. A green scan and a secure application are two different things, and the gap between them is filled by configuration, architecture, dependencies and deployment — everything a code scanner by definition cannot see. If you want the whole picture verified, not just the code — let’s talk about a penetration test and architecture review.
Sources and further reading: Anthropic — Claude Code documentation, MarkTechPost, OWASP Top 10, OWASP Top 10 for LLM Applications.
