If your company is on Claude Enterprise, you can now point Claude Security at your repositories once and let it keep scanning as code changes, mark findings fixed when the fix ships, and push new findings into your own tools through an API, an MCP connector and webhooks. Anthropic shipped this update on October 21, 2026 as a public beta for Enterprise customers, with up to $25,000 a month in free usage credits for two months (through December 31, 2026). If you are not on Enterprise, the same scanning technology is available as the claude-security plugin for Claude Code, which runs inside your own session and writes Markdown, JSONL and SARIF reports into your repo. This guide walks through both paths, step by step.

Everything here comes from Anthropic’s launch announcement, the Help Center article Use Claude Security, and the Claude Code docs page Scan your codebase for vulnerabilities. We also checked the plugin’s manifest in the official plugin marketplace repo on October 22, 2026 (Beijing time), where it was at version 0.12.0. We do not have Enterprise access, so the hosted-product steps below follow Anthropic’s documentation rather than our own screenshots.

Which path should you take?

Anthropic now has two products with the same name, and picking the right one saves time:

	Claude Security (hosted)	Claude Security plugin for Claude Code
Who can use it	Claude Enterprise, premium seats, usage credits enabled	Paid Claude plan, Anthropic API access, or a third-party provider (Bedrock, Google Cloud’s Agent Platform, Microsoft Foundry)
Where it runs	Anthropic’s hosted agents	Inside your Claude Code session
Scanning model	Claude Mythos (per the Help Center)	Whatever model your session uses
Continuous monitoring	Yes, scans new commits based on risk and complexity	No, you run scans on demand
Fix tracking	Marks findings fixed when the fix lands, reopens them if they return	No, each scan is a new report
Output	Web UI, API, MCP connector, webhooks	CLAUDE-SECURITY-<timestamp>/ folder with .md, .jsonl, .sarif
Zero Data Retention	Not supported	Anthropic’s suggested option if you have ZDR requirements
Reaches private networks	Needs inbound access to your Git host	Yes, it reads your local checkout

Anthropic’s docs spell out when the plugin is the better fit: if you want to run the scanner without Anthropic’s hosted agent infrastructure, have Zero Data Retention requirements, need model access through a third-party provider, or host code on networks that don’t allow inbound connections.

One rule applies to both. The Help Center’s scope-of-use terms say you may only scan code that you or your company owns and has the rights to scan, and explicitly not open-source projects or other third-party repositories outside your company’s codebase.

Part 1: Set up hosted Claude Security (Enterprise)

Step 1: Check the prerequisites

According to the Help Center FAQ, you need three things before anyone can create a project:

1. An active Claude Enterprise plan.
2. A premium seat for each user who will use Claude Security.
3. Usage credits enabled for consumption billing.

An organization owner then turns the feature on in Organization settings > Claude Security. The announcement adds that admins enable it in the admin console and choose who on the team can access it.

Step 2: Decide who can do what

The update adds role-based access control, so plan this before you open the doors. Admins configure which roles can create projects and which can view, triage or manage all projects through custom roles.

Inside each project, the Share button gives members one of three roles:

• Full: manage findings, settings and who has access.
• Triage: view findings, update their status and start fixes.
• View: read-only.

You can also share a project with your whole organization. A sensible starting point is to keep project creation with your security team and give each service team Triage on the project that covers their code, which is exactly the rollout pattern Anthropic describes: open Claude Security to the teams that own the code without letting everyone create projects.

Step 3: Give Claude Security access to your repositories

How you connect depends on where the code lives:

• GitHub.com or GitHub Enterprise Server: an owner installs the Claude GitHub App and grants it access to the repositories you want scanned.
• GitLab, Bitbucket or another Git server: you need the repository address and an auth token. Publicly reachable self-hosted Git servers work too.

If you run GitHub Enterprise Server or another self-hosted Git provider, your instance must allow inbound traffic from Anthropic’s IP ranges. The current list is on the IP addresses page of the Claude API docs.

Step 4: Create a project and pick its scope

A project holds up to eight repositories. Each one is either:

• In scope: Claude scans it and reports findings in it.
• Context only: Claude reads it during scans but reports no findings there.

Both kinds count toward the eight. This is the feature to use for issues that live between services. Anthropic’s example is a backend that trusts input a client was supposed to validate, which a single-repo scanner can’t see. Put the client and the backend in one project.

For each repository you also choose the branch and scope. For a large repository or monorepo, the Help Center recommends setting a folder scope instead of scanning the whole repository and excluding folders you don’t need covered. Claude can still pull context from the rest of the codebase. You manage a project’s repositories on its Resources tab.

Step 5: Let the baseline scan run

When you create the project, Claude reads the code, writes a threat model and runs a deep baseline scan. Anthropic says this can take several minutes or several hours depending on repository size, and you can leave the page while it runs. If you’ve turned on email notifications for Claude Security, you get an email when the scan finishes with new findings.

After the baseline, Claude checks for new commits and scans changes “regularly, based on their risk and complexity.” There is no fixed schedule, so don’t build processes that assume a scan lands within a set number of minutes of a merge.

Step 6: Teach it your environment through the threat model

This is the step that decides whether the findings are useful or noisy. Claude writes the threat model from your code alone, so it can’t know that a service sits behind an authenticating proxy, that an endpoint is internal-only, or that your team has accepted a particular risk.

Open the project’s Knowledge tab to:

• Edit the generated threat model.
• Add documents such as architecture docs.
• Describe how the code is deployed, who can reach it, which security policies apply, and anything a new security engineer would need to know.

Later scans use the threat model to decide what to flag and how to rate it. If a finding describes an attack that isn’t possible in your environment, the Help Center’s advice is to tell Claude why in the project’s chat and ask it to update the threat model. Vanta’s security director is quoted in the announcement making the same point: once they wrote their own risk policy into the threat model, focused on what external users can actually reach, the findings matched how they prioritize.

Step 7: Read a finding

Severity is judged per finding, against the project’s threat model, so the same bug category can land at different severities in different repositories. The Help Center defines the four levels:

• Critical: exploitable over the network by anyone, with no login, no victim action and no special conditions, and the attacker can both read and change data. Example: unauthenticated remote code execution in an internet-facing service.
• High: serious impact but short of Critical, for example the attacker needs a login or a victim’s action, or can read but not change data.
• Medium: limited impact with one realistic precondition such as a login.
• Low: limited impact that also needs network proximity or special conditions outside the attacker’s control.

Each finding has a title, severity, category (with a CWE ID when one applies), location linked to the source, status, assignee, a description of what Claude found (sometimes with an attack-path diagram), how to fix it, evidence grouped by repository with the scanned branch and commit, how the attack works, why Claude believes it, and a full history.

Two behaviors are worth knowing before you triage:

• Scans are stochastic. Anthropic says two scans of the same code can return different results, because an agent adapts its analysis on each run instead of matching fixed patterns.
• Every finding is verified before it’s shown. Findings go through multi-stage verification where Claude reviews its own findings, to cut false positives.

Step 8: Fix, dismiss, and let tracking close the loop

Click Fix on a finding to open Claude Code on that specific vulnerability. If your organization doesn’t have Claude Code in the cloud, you get a prompt to copy into your own Claude Code instead.

You don’t have to fix things inside Claude, though. Claude Security re-checks open findings when the code changes and marks them fixed when the fix lands, whether you fixed it in Claude Code or in a normal pull request. If the issue comes back later, the finding reopens automatically.

When a finding is wrong or acceptable, dismiss it as a false positive, an accepted risk, a duplicate, or for another reason, and add a triage note. Dismissed findings don’t reappear in future scans.

Step 9: Wire findings into your own tools

The update adds three integration points:

1. API. Create a personal access token under Claude Security settings. The token acts as you, so it can see and change only what you can. With it you can list and read projects and findings, resolve and reopen findings, and create and manage projects and their repositories. Anthropic hasn’t published endpoint details in the pages we used, so check the API reference linked from your Claude Security settings before writing code against it.
2. MCP connector. Claude Security is available as a connector in Claude.ai and Claude Code. Claude can list and read your projects and findings and resolve or reopen a finding when you ask, so an engineer can pull up a finding, ask about it, start the fix and mark it resolved in one session.
3. Webhooks. Create a webhook under Claude Security settings to push new-finding events into systems like Slack or Jira.

A practical setup: webhook into your ticketing system for new Critical and High findings, Triage roles for service owners, and the MCP connector for engineers who already work in Claude Code.

Step 10: Put a ceiling on cost

Claude Security is billed at direct token cost only, with no platform fee. Usage covers scans plus the other work it does in a project: writing the threat model, the project chat and checking fixes.

To keep it predictable:

• Set a separate spend limit for Claude Security.
• Open Usage in a project’s settings to see month-to-date and per-day cost.
• Watch the launch credits. Eligible Enterprise organizations get up to $25,000 in promotional credits per month for two consecutive months. Existing Enterprise customers started on October 21, 2026; new customers start on their sign-up date. Unused credits don’t roll over, the offer ends at the end of December 31, 2026 (UTC) even if your two months aren’t up, and organizations that sign up after November 1, 2026 won’t get two full months. Credits apply automatically, with no sign-up, and are used before committed spend. Admins can see the promotional balance in Organization Settings > Usage under Services, or in Organization Settings > Claude Security under Spend limit.

The credits only cover projects created in the new experience. If you used Claude Security before this update, your old projects keep running, but you need to migrate them for the credits to apply. Project owners can click Migrate project inside a project, or Migrate your projects on the Claude Security home page to move everything they own. Migration creates a new project, copies the findings and archives the original. Members, webhooks, excluded directories, scan history and scheduled scans are not copied, so re-create those afterwards. GitHub Enterprise projects can’t be migrated.

Troubleshooting: the page keeps redirecting to “Install GitHub App”

The claude.ai/security page runs a per-user check against your own connected GitHub account, so it can fail for you while it works for colleagues. The Help Center lists four causes:

• No GitHub account connected in Claude. Check under Customize > Connectors.
• Your connected GitHub account isn’t a member of the organization where the app is installed. Connect the account that is.
• SSO isn’t authorized for that organization. If your GitHub org requires SSO, authorize the Claude app for it separately, as described in Use the GitHub integration.
• Your GitHub organization’s IP allow list blocks the check. GitHub’s “Enable IP allow list configuration for installed GitHub Apps” setting covers traffic from the app itself but not this per-user check. Add 160.79.104.0/21 manually as an organization-level allow-list entry.

Part 2: Run the Claude Security plugin in Claude Code (any paid plan)

If you aren’t on Enterprise, or your code can’t be reached from outside your network, the plugin gives you the same style of multi-agent scan on demand. A team of agents maps your architecture, builds a threat model, hunts for vulnerabilities and independently reviews every finding before writing the report.

Step 1: Check the prerequisites

From the Claude Code docs:

• A paid plan, Anthropic API access, or a third-party provider. The scan uses Claude Code’s dynamic workflows to orchestrate its agents; on the Pro plan, turn them on from the Dynamic workflows row in /config.
• Python 3.9 or later on your PATH as python3. The plugin’s tooling uses only the standard library, so nothing else gets installed.

python3 --version

• Linux, macOS or Windows.
• Git for change scans and for turning findings into patches. A full scan works in any directory, with or without version control.

The plugin makes no model calls of its own, so there’s no extra API key. The agents that hunt, verify and write patches run on your session’s model (change it with /model before you start); a few supporting steps such as mapping the repository use the sonnet alias. On a third-party provider, sonnet can resolve to a different version than on the Anthropic API, so pin it with ANTHROPIC_DEFAULT_SONNET_MODEL if your account can’t use the default.

Step 2: Install it

Start Claude Code with claude, then run this at its prompt:

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

Choose an installation scope when the plugin’s details open. If the install fails, the docs map the two common errors to fixes:

# Marketplace "claude-plugins-official" not found
/plugin marketplace add anthropics/claude-plugins-official

# Plugin "claude-security" not found in marketplace "claude-plugins-official"
/plugin marketplace update claude-plugins-official

Retry the install after either one. If the summary says Run /reload-plugins to apply., run /reload-plugins to activate it in the current session. In the VS Code extension or the desktop app, install it from the plugin UI instead.

To remove it later:

claude plugin uninstall claude-security

Step 3: Turn on auto mode

The docs say the plugin works best in auto mode, which lets the scan’s agents proceed without a permission prompt at each step. If you haven’t set that up, our guide to Claude Code permissions and auto mode covers what auto mode allows and how to keep it on a short leash.

Step 4: Run a full scan

1. Run /claude-security and pick Scan codebase.
2. The plugin reads your repository, then offers the whole repository or a focused area, with each option’s file count and relative cost. Pick one, or answer “I don’t know” and it chooses a default based on repository size.
3. Confirm. Nothing runs until you do. The docs warn that a scan can take a while, can use a significant number of tokens, and needs Claude Code left open until it finishes.
4. Watch progress. Each stage is reported as it starts, with details under /workflows.

On a large repository, scan one area at a time, such as your API layer or your authentication code. The report’s coverage section states what was and wasn’t examined.

Step 5: Scan only a branch, a PR or a commit

To check work before merging, run /claude-security on a branch that has commits its base doesn’t, and the menu offers to scan just that diff. You can also ask in plain language:

/claude-security scan my branch

scan commit abc1234

Only committed changes are scanned, so commit or stash in-progress edits first (a full scan reads the working tree instead). Scanning one of your open pull requests is the only step that touches the network, and it’s offered only when your session already has permission to run the GitHub CLI and gh is signed in.

Step 6: Read the report

Every scan writes a timestamped CLAUDE-SECURITY-<timestamp>/ directory in your repository:

• CLAUDE-SECURITY-RESULTS.md: the human-readable report. Each finding has an ID such as F1, plus impact, exploit scenario, severity, confidence and recommendation.
• CLAUDE-SECURITY-RESULTS.jsonl: the same findings, one JSON object per line.
• CLAUDE-SECURITY-RESULTS.sarif: a SARIF 2.1.0 log with CWE categories, which GitHub code scanning and other standard tools can read.
• CLAUDE-SECURITY-REVISION-<commit>.json: a stamp recording which commit was scanned, at what effort, whether uncommitted changes were included, and how thoroughly the run was verified. Outside version control it says UNVERSIONED.

That folder is the only change a scan makes, and it ships with its own .gitignore so a stray git add won’t commit it. If you want the report in history as an audit trail, delete that one .gitignore and commit the folder.

Because the SARIF file follows the 2.1.0 standard, the docs note it works with GitHub code scanning and any other tool that reads SARIF, so you can feed it into the same dashboard as your existing scanners.

Step 7: Get reviewed patches and apply them yourself

Run /claude-security again and pick Suggest patches, or say something like “fix finding F3”, then choose findings. How it works, per the docs:

• Patches are built against committed code. If the code behind a finding has changed since the scan, that finding is skipped with a note and the plugin offers a fresh scan.
• Each patch is drafted in a scratch copy of the repo, so your files stay untouched.
• A separate agent reviews each patch, runs your tests when the code has them, and only writes the patch if it can vouch that it fixes the one finding, adds no new vulnerability and leaves behavior otherwise unchanged. Otherwise you get a note explaining why.

Patches land in the report’s patches/ folder as F<n>.patch, each with an explanatory note. They are never applied automatically. Apply one from your shell, ideally one per pull request:

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

If the patched code has no tests, the note says so, which tells you the review ran without a test pass.

Plugin troubleshooting

• The /claude-security menu opens with a Python warning. Install Python 3, or put a python3 of 3.9 or newer first on your PATH, then start a new session.
• “Safeguards flagged this message” when scanning on a Fable model. The docs say this is expected: Fable’s cybersecurity classifiers flag some requests and Claude Code re-runs them on an Opus model through automatic model fallback, and the scan should still finish. On Bedrock, Google Cloud’s Agent Platform or Foundry the request can end in a refusal instead, depending on how your deployment is set up.

Where this fits next to your other scanners

Anthropic positions the plugin as one layer in a stack, not a replacement for static analysis or dependency scanning. Its own table runs from the security guidance plugin (catches issues as Claude writes code), to /security-review (a single pass over a branch), to the Claude Security plugin (on-demand deep scan), to Code Review on pull requests (Team and Enterprise), to the hosted Claude Security product, and finally your existing CI scanners for language rules and supply-chain checks.

Two points from recent incidents are worth adding. First, none of these replace dependency monitoring: the LiteLLM 1.107.0 package compromise was a supply-chain problem, not a bug in anyone’s own code. Second, engine-level bugs like PHP2Shell live in your runtime, not your repository, so patching servers is still a separate job.

If you’re comparing vendors, OpenAI’s open-source equivalent is covered in our Codex Security guide, and Anthropic’s earlier do-it-yourself version, the open-source defending-code reference harness, is still on GitHub for teams that want to customize the whole loop.

FAQ

Is hosted Claude Security available on Team or Pro plans? No. The October 21 update is a public beta for Claude Enterprise customers. Other plans can use the Claude Code plugin.

Which model does hosted Claude Security use? The Help Center says scans are powered by Claude Mythos and users receive findings without direct model access. The project chat uses a model your team picks from those your organization allows, and some subcomponents may use other models for simpler tasks. The announcement adds that no Cyber Verification Program access is required.

How often does it rescan? There’s no fixed schedule. Claude checks for new commits and scans based on their risk and complexity.

Why did two scans of the same code give different results? Both the hosted product and the plugin are nondeterministic by design. For the plugin, use the revision stamp file to tie each report to the exact commit and settings it covered, and run scans regularly.

Can I scan an open-source library we depend on? Not under Anthropic’s terms. The Help Center limits scanning to code you or your company owns and has the rights to scan.

Does it support Zero Data Retention? The hosted product doesn’t. If you need ZDR, Anthropic points you to the Claude Code plugin.

For more hands-on AI developer guides, browse the latest tutorials on the 7minai homepage.