A team of hackers against your app

What it is and why it matters

Before you launch an app built with AI, the question is always the same: is there a hole I can't see? You use the app from the inside, with your own account, and it works. Whoever wants to break it looks at it from the outside.

Claude Security is an official Claude Code plugin, and it isn't a single check: it's a team of agents. One maps your architecture, one builds the threat model, meaning who would attack your app, from where and to take what, and others hunt for vulnerabilities. Independent verifier agents analyze every flaw found before it goes into the report, so the report stays short and free of false alarms. At the end it prepares the fixes as patches, and you apply them yourself.

The hackers are fake in the good sense: the plugin reads your code, in your session, and doesn't attack the live app or the real database. It's for anyone about to launch an app that holds people's data.

Its status, checked against the official Claude Code documentation on October 22, 2026: the plugin's page doesn't label it as a preview or beta, and it installs from Anthropic's official marketplace. Don't confuse it with the managed service of the same name that monitors repositories continuously: that's a separate product, for the Enterprise plan.

1. What you need

• A paid Claude plan, the Anthropic API or a provider such as Amazon Bedrock, Google Cloud or Microsoft Foundry. The scan uses Claude Code's dynamic workflows, a script that coordinates many agents at once. On the Pro plan, you turn them on from /config, in the Dynamic workflows row.
• Python 3 reachable as python3 (try python3 --version). The plugin only uses the standard library, installs nothing, and if your version is too old its menu tells you.
• Git, to scan only your changes and for the patches. The full scan works without it. Mac, Linux or Windows are all fine.

There's no separate key: the plugin doesn't call models on its own, it uses your session, and the agents run on the model you picked with /model. Every scan counts toward your usage, can use a lot of tokens and needs Claude Code left open until it finishes.

2. Install the plugin

In your project folder, start Claude Code with claude and type:

/plugin install claude-security@claude-plugins-official

The plugin's page opens, where you choose who to install it for: you in every project, everyone on the repository or just you in this repository. If the summary says “Run /reload-plugins to apply.”, type /reload-plugins. If instead it says the plugin isn't in the marketplace, refresh the catalog with /plugin marketplace update claude-plugins-official and try again.

3. Run the scan

1. Type /claude-security and pick Scan codebase.
2. The plugin reads the repository and offers you all of it or one part, such as the API or the login, with the file count and relative cost of each option. If you don't know, answer “I don't know” and it picks for you.
3. Confirm: nothing runs before that. Then leave Claude Code open. The detail, agent by agent and with each one's tokens, is under /workflows, and you can also stop everything from there.

It works best in auto mode, where a second model reviews the actions instead of you and the agents don't ask your permission at every step. On a big project, go one area at a time: login, payments, API.

Only your changes, before merging

If you work on a branch, the menu offers to scan only what changed against the base; you can also ask for a single commit or one of your open pull requests. Only what's already committed counts. You can also ask in plain words:

/claude-security scan only the changes on my branch

4. Read the report

Every scan writes a CLAUDE-SECURITY-<timestamp> folder into the repository. It's the only thing that changes in your project, and it has its own .gitignore, so it doesn't end up in a commit by mistake. Inside:

• CLAUDE-SECURITY-RESULTS.md, the report to read: each flaw has an ID (F1, F2…), its impact, an attack scenario, the severity, how confident the finding is and what to do.
• The same flaws in .jsonl for programs and in .sarif, the standard format read by GitHub code scanning and other security tools, with each flaw's CWE category.
• A stamp, CLAUDE-SECURITY-REVISION-<commit>.json, that records which commit was scanned and at what effort, so every report stays tied to the code it describes.

Start with the most severe, high-confidence flaws, and before fixing, have the scenario explained to you:

Open the Claude Security report and explain flaw F1 to me as if I knew nothing about security: who can exploit it, what they get, which screen or address of the app it goes through and how likely it is. Tell me whether it touches real users' data. Don't change anything.

5. You apply the fixes yourself

Type /claude-security again, pick Suggest patches and then the flaws. Each patch is drafted in a separate copy of the repository and reviewed by another agent, which runs the tests if there are any. It's delivered only if it closes that flaw, opens no others and changes nothing else; if not, you get a note explaining why.

The patches go into patches/ inside the report, one per flaw (F1.patch, F2.patch…), and they're never applied automatically. You apply one from the terminal like this:

git apply CLAUDE-SECURITY-<timestamp>/patches/F1.patch

One patch per pull request, so each one gets reviewed and tested on its own. Or have Claude do it:

Apply patch F1 from the Claude Security report on a new branch, run the tests and open a pull request with only that change. In the description, write the flaw, the fix and how you tested it.

If the touched code has no tests, the patch's note says so: check it by hand before merging. And if that code has changed in the meantime, the flaw is skipped and the plugin offers a fresh scan.

6. The four typical holes in AI-built apps

• The open database. Supabase wants Row Level Security on every exposed table: without it, the public key in the app can be enough to read and write. On Firebase, look for allow read, write: if true, which the documentation says never to use in production. The live test: the PORTA guide (strikt.fit/porta).
• The secret key in the app's code. Supabase's one (secret, or service_role) never in the browser, a shipped app or on GitHub. And VITE_, NEXT_PUBLIC_ and EXPO_PUBLIC_ variables end up in the code that reaches the browser or the app: no keys there. The CHIAVI guide (strikt.fit/chiavi).
• The endpoint that doesn't check who's asking. An endpoint is an address on the server, like /api/orders/123. The classic case: it checks the login, but not that order 123 is yours, so you change the number and read someone else's. It's the first risk in the 2023 OWASP API Security Top 10. The check belongs on the server, not in a hidden button.
• No limit on requests. If an endpoint calls an AI or sends emails or texts, anyone can call it a thousand times and the bill lands on you: it's the fourth risk on the same list. The LIMITE guide (strikt.fit/limite).

For a quick first look, before the real scan:

Check this app's code for the four classic holes in AI-built apps and for each one tell me file, line and severity: 1) database tables with no access rules (Row Level Security on Supabase, security rules on Firebase) or with rules that let anyone who's logged in read everything; 2) secret keys in code that reaches the browser or the app, including NEXT_PUBLIC_, VITE_ and EXPO_PUBLIC_ variables; 3) endpoints that don't check who's making the request and whether the requested object is theirs; 4) endpoints with no request limit, especially the ones that cost money (AI, email, SMS). Don't change anything and never print the value of a key.

It's a single pass, without the plugin's verifiers. And database rules created from the dashboard, not in the code, are invisible to both this check and the plugin: for those you need the live test.

Common mistakes

• Starting with a whole large repository. The first time, pick one area, like login or the API, and watch what it uses in /workflows.
• Asking for a changes scan with your work not yet committed. That scan only looks at commits.
• Applying all the patches at once. One per pull request, each reviewed and tested.
• Taking a clean scan to mean a secure app. Scans vary from run to run and read the code, not the live settings: run them again and do the live tests too.
• Removing a secret key found in the code and stopping there. It has to be revoked and replaced, because it stays in the history.

Checklist

• Paid plan or API, dynamic workflows on (on Pro, from /config).
• python3 and git working, plugin installed.
• First scan on an area with people's data: login, payments, API.
• Report read starting from the most severe flaws.
• Patches applied one per pull request, the ones without tests checked by hand.
• The four typical holes checked on the live app too.
• Scan run again before every major launch.

Frequently asked questions