If you want to use Claude Code for secure code review, do not start by asking an agent to scan the whole company. The useful part of the Alberta case is the auditable chain: a rules engine flags known patterns, Claude Code reviews them and cites files and line numbers, and engineers approve the fixes.
The trigger is Anthropic's July 6, 2026 Alberta government case study (Anthropic case study, checked July 7, 2026). Anthropic says Alberta has used Claude Code with Opus and Sonnet models since 2025 to review government systems. Its technical team evaluated about 466 million lines of code in roughly 20 hours, with about 50 agents running in parallel across the government codebases it maintains; fixes still required engineer review and approval before release.
Do not use Alberta's scale numbers as your team's ROI forecast. What transfers is the pilot order: limit the assets and rules first, require reviewable evidence, let AI draft fixes and tests, and keep merge, disclosure, and release decisions with humans.
Teams that should try this first
A Claude Code security review pilot fits teams that already have code owners, test entry points, and a vulnerability-handling flow. If those basics are missing, the agent will mostly amplify false positives and review load.
| Team state | Recommendation |
|---|---|
| More than 10 services, legacy debt, and a security backlog | Pick one clearly bounded system for the pilot |
| Existing SAST, dependency scanning, or internal security rules, but limited remediation capacity | Use Claude Code for second-pass review, fix drafts, and test drafts |
| Legacy systems with incomplete docs and changing maintainers | Start with security checklists and technical documentation, not production code edits |
| No CI, no owner, no security contact | Add the process first; do not launch broad agent review |
| Repositories contain production secrets, undisclosed vulnerability details, or sensitive customer data | Use isolated copies and sanitized inputs before discussing agent access |
Alberta was dealing with large public-sector legacy systems. Anthropic says its Ministry of Technology and Innovation maintains systems for 27 provincial departments, about 1,280 applications, and 3,400 code repositories, many of which had never received systematic security review. Your team does not need that scale to justify a pilot, but it does need a clear asset boundary.
Do not scan the whole company in round one
The first round should only prove that a security review loop can work: candidate findings can be explained, patches can be tested, and accountable owners can approve them. Do not start by trying to reproduce Alberta's 466-million-line scan.
Use these 6 filters when choosing the repository:
| Selection filter | Passing standard |
|---|---|
| Business boundary | One service, one app, or one clearly defined subsystem |
| Code owner | At least 1 owner can review the result |
| Test entry point | Unit tests, integration tests, or a minimal validation command exists |
| Risk type | Only 2-3 issue classes, such as auth, input validation, dependency versions, or log leakage |
| Data boundary | No need to expose production secrets, real customer data, or undisclosed vulnerability material |
| Rollback path | Failed fixes can be reverted without directly affecting production |
Avoid payment systems, identity core flows, production deployment scripts, cloud permissions, DNS, key management, and unsanitized whole monorepos in the first round. Security review is not better just because it is larger; the first pilot needs measurable true-positive rate, fix cost, and review burden.
Organize agents as a two-stage review
In Anthropic's case study, Alberta did not let the model freely search the entire repository for risk. The described mechanism is two-stage: a rules engine first marks known patterns, then Claude Code reviews those marks and cites specific files and line numbers for developers to verify.
Run the first round like this:
- Prepare the rule set: Choose 10-30 rules from historical vulnerabilities, SAST rules, dependency policy, and internal coding standards.
- Run deterministic scanning first: Let a rules engine or script produce candidate findings. Do not let Claude freely search every possible risk.
- Ask Claude Code to review candidates: Each candidate must include trigger conditions, impact scope, file path, and line number.
- Request fix drafts: Only allow minimal patches inside selected directories.
- Add tests before code changes when tests are missing: If no automated test proves the patch is safe, ask Claude to write the test first, then consider implementation changes.
- Require human approval: The owner or security engineer confirms true positive status, severity, patch, and tests before merge.
This workflow leaves reviewable evidence for every result. The security team should see what rule matched, how Claude reasoned, which line is affected, and where the patch and tests are.
A task template for Claude Code
The pilot prompt should specify permissions, inputs, outputs, and stop conditions. Adapt this template:
You are working in a supervised Claude Code security review pilot.
Goal:
Review candidate findings in security-findings.json. Only handle src/auth and src/api.
Inputs:
- security-findings.json contains candidates produced by a rules engine
- docs/threat-model.md is the threat model for this service
- tests/api contains the currently runnable tests
Allowed:
- Read src/auth, src/api, tests/api, and docs/threat-model.md
- Cite file paths and line numbers when confirming findings
- Generate minimal fix drafts
- Add or update tests under tests/api
Not allowed:
- Scan external systems
- Generate exploit code, attack payloads, detection evasion, lateral movement, persistence, or data exfiltration steps
- Modify deployment, cloud permissions, secrets, CI/CD, or production configuration
- Install new dependencies
- Commit, push, or release automatically
Output:
1. Whether each candidate is a true positive, false positive, or unknown
2. Evidence, including file paths and line numbers
3. Minimal fix recommendation
4. Tests to add
5. Decisions that must be made by a human
Stop conditions:
- You need access to files outside the allowed scope
- You need to modify more than 5 business files
- You need to add a dependency
- You find a high-severity vulnerability or suspected undisclosed vulnerability
Do not ask Claude to "prove exploitability" in this template. The first security review round should produce remediation and review material, not attack reproduction material.
Put a test gate before patch generation
Anthropic says that after Alberta found vulnerabilities, Claude Code generated fixes, tests, and builds; if a system lacked automated tests, Claude wrote tests first. Use the same order in your pilot: add tests first, review the patch second, then build and validate.
Split patch permission into three tiers:
| Patch type | Handling |
|---|---|
| Low-risk fixes, such as input validation, error handling, or log redaction | Claude Code may draft the patch, but it must include tests |
| Medium-risk fixes, such as auth logic, permission checks, or serialization boundaries | Claude drafts the approach and tests; the owner changes core logic manually |
| High-risk fixes, such as identity core flows, payments, production config, encryption, or secrets | Claude only provides impact analysis and a review checklist |
Do not treat "Claude can build it" as "this can merge." Before merge, check:
- The patch only changed allowed directories
- Tests cover the trigger condition and negative cases
- No new dependency or broader permission was introduced
- Authentication, authorization, logging, or data-retention semantics did not change unexpectedly
- A security advisory, CVE, customer notice, or delayed disclosure process is needed
Split continuous review into roles
The Alberta case also says the team built specialized Claude review agents that run during development: one red-team-perspective agent checks the application externally, one blue-team-perspective agent evaluates defenses against international security standards and writes remediation plans, and other agents check code quality and public-facing copy. Each run checks about 95 security controls.
You can borrow that structure, but do not turn version one into a fully automated offense-defense platform. Start with these constrained roles:
| Agent role | First-version responsibility | What it should not do |
|---|---|---|
| Candidate review agent | Review rules-engine findings and cite files and lines | Freely generate attack paths |
| Fix draft agent | Generate minimal patches and test drafts | Merge, push, or release automatically |
| Defense checklist agent | Compare against internal control items | Replace the security owner on severity decisions |
| Documentation agent | Add system notes, risk notes, and runbooks | Invent unverified system behavior |
| Regression agent | Run limited validation commands and summarize failures | Modify tests to hide failures |
If you do use a red-team-perspective agent, keep it inside an authorized test environment and limit its output to risk descriptions, affected components, evidence locations, and remediation advice. Do not put reusable attack steps into ordinary tickets or code review threads.
Track three metric groups
Do not report only "lines of code scanned." Alberta's scale numbers are useful news context, not success metrics for your internal pilot.
Track these three groups in the first round:
| Metric | What to record |
|---|---|
| Accuracy | Candidate count, true positives, false positives, unknowns, duplicate issues |
| Remediation loop | Fix drafts generated, fixes with tests, CI-passing fixes, merged fixes, rollbacks |
| Human cost | Review time per issue, owner modification time, security-owner escalations |
After a two-week pilot, expand only if these conditions hold:
- True positives can be verified by file and line number
- False-positive causes can be categorized and used to improve rules or prompts
- Merged patches include tests or clear human verification records
- No unauthorized reads, sensitive-data leakage, or unapproved external access occurred
- Owners say review burden went down instead of being flooded by low-quality reports
Common mistakes
Treating Claude Code as a SAST replacement
Do not. The Alberta case puts Claude Code after a rules engine. Deterministic tools reliably hit known patterns; Claude explains, locates, drafts fixes, and drafts tests.
Asking the agent for a full attack reproduction
Security remediation does not need full attack steps. For an ordinary pilot, affected files, trigger conditions, risk explanation, and fix tests are enough evidence. The closer the output gets to exploitation, evasion, exfiltration, or persistence, the more it belongs in a controlled security process.
Batch-fixing without tests
If the system has no tests, ask Claude Code to add tests and documentation first. Batch-editing a legacy system directly turns the security pilot into a regression-risk generator.
Ignoring human approval
Anthropic explicitly says Alberta's engineering team reviewed and approved patches before release. Keep that approval line in your workflow. AI can speed up discovery, explanation, and fix drafts, but it cannot replace final security responsibility.
Treating case-study numbers as a promise
466 million lines, 20 hours, about 50 agents, and 95 control items are Anthropic's official description of the Alberta implementation. They only prove Alberta operated at that scale; they do not promise the same speed, accuracy, or cost for your codebase.
FAQ
Can Claude Code be used directly on sensitive government or enterprise code?
Do not start with production-sensitive repositories. Run a pilot with isolated copies, restricted paths, sanitized inputs, audit logs, and human approval. For government, finance, healthcare, or customer-sensitive data, follow your organization's data-handling and vendor-security approval process.
How many agents do we need in the first round?
Do not start with 50 agents. Alberta's roughly 50 agents are the scale in the official case study. Most teams only need 1-3 roles in the first round: candidate review, fix draft, and regression summary. Prove the loop first, then increase parallelism.
What if we do not have an internal rules engine?
Use existing SAST, dependency scanning, lint rules, historical vulnerability lists, or security checklists to produce candidates. Do not let Claude Code freely search for every possible vulnerability without boundaries.
Can Claude Code's security patches merge automatically?
No. Security patches need at least owner review, tests, CI, and security review. High-severity vulnerabilities, disclosure, production configuration, identity permissions, and secret handling must be approved by humans.
How is this different from the Fable 5 cybersecurity prompt article?
The Fable 5 cybersecurity prompt article explains how to avoid out-of-bounds requests and false blocks. This article explains how to place Claude Code inside a security code review process, especially asset selection, two-stage review, patch testing, and human approval.
How is this different from the OpenAI Daybreak / Codex Security article?
The OpenAI Daybreak article covers OpenAI's defender program, Codex Security, GPT-5.5-Cyber, and open-source patch flow. This article only breaks down the Alberta Claude Code case. It fits teams that have decided to try Claude Code but have not yet defined the first repository scope, agent roles, and patch approval line.