Claude Code Security: What It Scans—and What It Doesn’t
Claude Security—previously called Claude Code Security—scans source code. It analyzes a defined scope, reports potential vulnerabilities, and can propose fixes for review. It does not control what a coding agent may access or what happens when that agent runs commands. Permissions, sandboxing, network egress, secret handling, and host isolation sit in a separate runtime security layer.
For AppSec and engineering teams, this is the essential boundary: a scan can add evidence about code risk, but it cannot show whether an agent session is adequately contained.
Status check (August 24, 2026): Anthropic described Claude Security as a public beta available to Claude Enterprise customers and identified Claude Code Security as its previous name.
What Claude Code Security means today
The current name, Claude Security, refers to source-code security analysis, not a general security mode for Claude Code. In Anthropic’s managed service, a user selects a repository to scan. Each reported finding includes a CWE category, confidence and severity ratings, and a suggested fix.
The outputs support an investigation. They do not prove that a vulnerability exists or that a proposed change is safe. Because “Claude Code Security” can suggest a broader capability than the documentation describes, a more precise working definition is: code analysis that produces security findings and reviewable fix proposals for a selected scope.
What goes into a scan
Every scan has an explicit scope. The local Claude Security plugin can scan a repository or directory, or focus on a changeset such as a branch diff, pull-request diff, or single commit. Its documented result files include a Markdown report, JSONL findings, and revision-specific JSON.
The managed service accesses code differently. An administrator installs the Anthropic GitHub App to provide repository access, and a scan can optionally be limited to a directory or branch. Either way, the input is code within a chosen boundary—not the full operating context of a coding agent.
This is where two kinds of scope are easy to conflate. Repository and changeset scope define which code is analyzed. They do not define which files, processes, credentials, or network destinations an agent can reach while working.
From findings to reviewed patches
The functional flow is scan → finding → proposed patch → review. In the local plugin, patches are built against suitable committed code in a scratch copy. An agent that did not author the patch reviews the diff and runs project tests when the project provides them.
Automated review adds a check; it does not grant approval. Anthropic states that every patch in the managed workflow must be reviewed and approved by a human. A suggested fix is therefore a code change to inspect, test, and judge in context—not a correction to accept by default.
What the scan does not assure
Anthropic highlights high-severity vulnerability classes including memory corruption, injection flaws, authentication bypasses, and complex logic errors. These are areas of focus, not a claim of complete coverage.
The local documentation says scans are nondeterministic, so repeated analysis can produce different results. It also says the plugin does not replace static analysis, dependency scanning, or code review. Anthropic separately warns that proposed patches can be wrong and should always be reviewed.
The boundary is strict: a clean result does not establish that the code is vulnerability-free, and a finding does not make its suggested patch correct by default. Claude Security contributes another source of security findings, not a security guarantee.
Code scanning versus runtime controls
A code scan asks about the selected code. Runtime controls ask what an agent can do while it operates:
| Control | Question it answers | What it does not establish |
|---|---|---|
| Claude Security scan | What potential vulnerabilities appear in the selected code scope? | What the coding agent can access while running |
| Claude Code permissions | Is a requested action allowed under configured permission rules? | Whether the code being edited is free of vulnerabilities |
| Bash sandbox boundary | What operating-system resources can a Bash command and its child processes reach? | Whether source-code analysis found every relevant flaw |
| Cloud egress and secret rules | Which network access level applies, and how sensitive values are exposed in that environment? | Whether a proposed patch is correct |
Claude Code enforces permission rules outside the model. For sandboxed Bash commands, the operating system enforces the sandbox boundary; built-in file tools use the permission system directly. Anthropic’s cloud environments define a network access level separately. Their documented environment values are readable by anyone using the environment because those environments have no dedicated secrets store.
None of these runtime mechanisms scans for vulnerabilities. In the other direction, a Claude Security result says nothing by itself about filesystem reach, process isolation, egress policy, or credential exposure. For the runtime side of that boundary, see Claude Code sandboxing and runtime isolation.
Conclusion
Use Claude Security for analysis of a selected code scope that returns findings and possible fixes. Use permissions, sandboxing, egress controls, and secret handling for the conditions under which an agent operates. That vocabulary points engineering teams to the evidence they actually need: scan results for code risk, and runtime controls for agent access and containment.