"AI finds bugs" is not the story
Anthropic has opened Claude Security as a public beta for Claude Enterprise. It is an agentic capability that scans a codebase for vulnerabilities and proposes targeted patches for human review. Team and Max plans are said to follow.
The easy headline is "AI finds security bugs." For anyone who has actually operated security tooling in a team, that is not where the interesting part is. The real question is signal-to-noise economics: not whether a tool can detect something, but whether its output is worth a human's attention. Get that wrong and you have added one more dashboard nobody opens.
Why traditional SAST loses in practice
Static analysis is not new and it is not immature. It fails in many organizations for a structural reason: how it resolves the precision/recall tradeoff.
A scanner built on pattern matching and a fixed ruleset is terrified of false negatives, so it is tuned loose. The first full scan on a real codebase produces a few thousand findings. Of those, perhaps a few dozen matter. Sometimes a handful.
From there, every team follows the same arc:
- The first couple of sprints, people triage honestly.
- They notice the false-positive rate and realize verification costs more than it returns.
- The "look at this later" label starts filling up.
- The security job in CI is permanently red, and red stops meaning anything.
- Nobody opens the dashboard.
This is false-positive fatigue. The tool did not stop working. It exhausted a finite resource — human attention. Once you reach that point, a genuine vulnerability the scanner finds is buried in the same pile as everything else. Detection-rate arguments become irrelevant.
The other structural weakness is that pattern scanners cannot follow data across files. The auth check lives in middleware/auth.ts, the route that skips it lives in routes/internal.ts, and the string-concatenated SQL it eventually reaches lives in db/query.ts. A multi-component flaw like that matches no single-file pattern. Rulesets find shapes they already know, and real attack paths are usually shapes nobody wrote a rule for.
What an agentic scanner changes
According to Anthropic's announcement, Claude Security does not match fixed rules. It reasons over code context, traces data flows across files, and adapts how it analyzes on each run — which is what lets it surface multi-component patterns like auth bypasses, injection chains, complex logic errors, and memory corruption that fixed rulesets miss.
But the design idea worth studying is not the detection. It is that every finding goes through an adversarial verification pass: Claude challenges its own result before surfacing it.
That is a direct attack on false-positive fatigue. A conventional scanner's contract is "if it looks suspicious, emit it." Putting an adversarial pass in front of the output means the precision filter moves into the tool, and the tool absorbs triage work that used to land on an engineer. The target is not detection capability. The target is how much human attention each finding costs. We think that is the right thing to be optimizing.
Findings can be routed to Slack, Jira, or any ticketing system via webhooks, or exported as CSV or Markdown. That sounds like a minor integration detail, but it reflects the same instinct: pipe into the workflow people already use, rather than build another surface to check.
Public-sector adoption is moving too — California's Department of Technology and CalOES have been reported as deploying Claude Code for security scanning and patching.
What it does not change
Misread this part and you will get hurt. An agentic scanner does not replace:
Threat modeling. A tool that reads code knows what the code says. It does not know what the system is supposed to protect, or from whom. Trust boundaries are still a human design decision.
Dependency and supply-chain scanning. Vulnerabilities you wrote and known CVEs sitting under node_modules are different problems. You still need SCA.
Runtime protection. DAST and a WAF observe execution behavior and real traffic — things static analysis cannot see by construction. Different layer, different job.
And the practical one: it is non-deterministic. Because it is model-driven, the same codebase can produce different results across runs. That is not a bug report; that is the nature of the tool.
The conclusion follows directly. Do not make it a merge-blocking gate on its own. If a PR that passed yesterday fails today for no code reason, the first thing engineers will do is find the bypass. At that moment the tool is effectively disabled, and you still pay for it.
The adoption path we recommend
Here is what we advise clients to do.
1. Run it in parallel with your existing SAST for a few sprints. Do not replace anything yet. The metric to compare is not finding count — it is the confirmed-finding rate: of the issues raised, what fraction did a human review and agree were worth fixing? That single number is the only honest answer to "is this tool worth our attention budget?"
2. Keep humans as the approval gate on patches. Treat proposed patches as proposals. Security fixes frequently carry behavior changes. "Tightened auth, and now every legacy client is locked out" is a perfectly correct patch if all you read is the code.
3. Wire findings into the ticket flow you already have. Do not stand up a new dashboard. Webhook it into Jira or Slack, let it land in the same triage queue as everything else. A dashboard nobody visits is quietly worse than a false positive.
4. Schedule the scan and triage it. Do not block every PR.
Here is what that last one looks like.
# .github/workflows/security-scan.yml
# Runs an agentic security scan on a schedule and files findings as an issue.
# Deliberately NOT a PR gate: a non-deterministic check as a required status
# teaches engineers to hunt for the bypass, which disables it in practice.
name: agentic-security-scan
on:
schedule:
- cron: "0 18 * * 0" # Sundays, 18:00 UTC
workflow_dispatch: # allow manual runs
permissions:
contents: read
issues: write
jobs:
scan:
runs-on: ubuntu-latest
timeout-minutes: 45
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0 # full history: more context for data-flow reasoning
# Placeholder for your scanner's CLI. The contract assumed here is
# simply "write a Markdown report to findings.md".
- name: Run security scan
run: |
./scripts/run-security-scan.sh \
--format markdown \
--out findings.md
continue-on-error: true # a scanner failure must not break CI
- name: File findings as an issue
if: hashFiles('findings.md') != ''
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
gh issue create \
--title "Security scan: $(date -u +%Y-%m-%d)" \
--label "security,needs-triage" \
--body-file findings.md
- uses: actions/upload-artifact@v4
if: always()
with:
name: security-findings
path: findings.md
retention-days: 90The load-bearing lines are continue-on-error: true and the needs-triage label. This workflow blocks nobody. Once a week, it puts one item into a queue a human reads.
Why scheduled-and-triaged beats blocking-on-every-PR, concretely:
- Non-determinism stops being noise. Run-to-run variance is tolerable at a weekly triage granularity. It is not tolerable in a required check.
- You protect the review slot. Interrupt an engineer on every PR and review degrades into reflexive approval. Give them one focused window a week and they actually read.
- Cost and latency stay predictable. A scan that reasons over whole-repo context is too heavy to run on every push, and you will feel it in both the bill and the queue.
Keep your PR-time checks deterministic and fast: lint, types, secret detection, known CVEs in dependencies. An agentic scanner belongs in the deep-but-slow layer. That is not a compromise; it is the correct place for it.
Takeaway
The part of Claude Security worth evaluating is not detection breadth — it is adversarial self-verification, because that goes after the actual reason SAST loses in the field: exhausted human attention.
The non-determinism does not go away, which is exactly why the deployment shape should be scheduled runs, human triage, and your existing ticket flow. Do not start by trusting the tool. Start by measuring its confirmed-finding rate. A few sprints of that number will tell you what to do next.