By Clara Reed
On July 6, 2026, Anthropic published a case study describing how Alberta’s Ministry of Technology and Innovation used Claude Code to review government systems, identify vulnerabilities and support remediation. Alberta reported scanning 466 million lines of code in 20 hours with around 50 agents working in parallel. The figures belong to Alberta’s implementation and should not be treated as a universal performance benchmark. The more transferable lesson is the workflow: start with deterministic checks, use AI to explain and prioritize findings, create tests before risky fixes, and keep engineers responsible for approval.
This guide turns that reported approach into a practical, safety-first process for an enterprise or public-sector team. It is an operational adaptation, not a claim that every organization will reproduce Alberta’s results.
1. Define the scope before giving an agent access
Begin with an inventory of repositories, applications, owners, environments and data classifications. Work from a read-only mirror or a dedicated branch, and document written authorization from the system owner. The first pass should not have permission to deploy, alter production data, rotate credentials or access unrelated repositories.
Keep commit hashes, tool versions, prompts, model outputs and reviewer decisions with each finding. Establish stop conditions before the scan starts. Findings involving authentication, authorization, cryptography, secrets, personal data or destructive commands should be escalated to a human security engineer rather than handled automatically.
2. Separate detection from interpretation
Alberta’s reported process used a two-stage routine. A rules engine first flagged known patterns, then Claude Code reviewed those findings and cited the exact file and line so developers could verify them. That separation is important: deterministic tools provide repeatable evidence, while an AI model can help explain data flow, likely impact and remediation options.
For each alert, ask the model to produce a structured record containing the affected file and line, the suspected weakness, preconditions for exploitation, possible business impact, confidence and the evidence that supports the conclusion. Do not accept a vague statement that code is insecure. A reviewer should be able to reproduce the reasoning from the repository, configuration and test result.
Prioritize issues that cross trust boundaries: missing authorization checks, unsafe input handling, exposed credentials, insecure defaults, excessive permissions and sensitive data leakage. Preserve false positives and accepted risks in the same system so the next scan can distinguish a reviewed exception from an unknown issue.
3. Make the patch prove itself
For every accepted finding, create a tracked issue and an isolated branch. Ask the AI system for the smallest defensible patch and a regression test. Alberta reported that Claude Code wrote tests first when an application lacked enough automated coverage to establish that a fix was safe. This is a useful rule for any team: if the expected behavior cannot be tested, the patch is not ready for approval.
Run the new test alongside the existing unit, integration and build checks. Review the complete diff, not only the lines changed by the model. Check for weakened validation, altered error handling, new dependencies, accidental logging of sensitive values and changes to access-control behavior. A human engineer should approve the commit before it can enter a release branch. Keep a rollback path and record which evidence supported the decision.
4. Use independent red and blue passes
Alberta described specialized review agents that operate throughout development. A red-team agent probes an application from the outside and maps how a vulnerability might be exploited. A blue-team agent evaluates the defenses against an international security standard and writes a remediation plan that points to the files requiring attention. The case study says Alberta checks each application against roughly 95 security controls on every pass.
For a smaller deployment, reproduce the principle rather than the scale. Run the red-team pass only against an authorized staging target, with network and time limits and no persistence. Keep the blue-team review logically separate so it evaluates the evidence rather than accepting the red-team agent’s conclusions. Map each control to a test, configuration check or human review. After a patch, rerun both passes and the regression suite.
5. Protect the review loop itself
Code, documentation and issue trackers can contain prompt-injection content. Treat repository text as untrusted input, and do not allow instructions found in comments or README files to override the task, permissions or stop conditions. Give agents least-privilege credentials, restrict network access, mask secrets and use an approved data path for any code sent to an external model.
Tool output also needs verification. An agent may claim that a test passed without producing a trustworthy log, or may generate a patch that changes behavior outside the requested scope. Require machine-verifiable test artifacts, signed commits where appropriate and a human checkpoint before merge or deployment. Keep the agent’s permissions narrower than the engineer supervising it.
6. Turn one scan into a continuous control
Connect the review process to pull requests, scheduled repository scans and major infrastructure changes. Track time to triage, verified-fix rate, reopened findings, coverage by repository and exceptions nearing expiry. These measures are more useful than counting model-generated alerts because they show whether the organization is reducing exploitable risk.
Start with one application whose owner can provide fast feedback, then expand after the workflow is repeatable. Train developers to read the evidence, challenge the model’s assumptions and write tests that capture security requirements. Alberta also described an AI Academy intended to extend its approach across government; the organizational lesson is that secure AI adoption needs education as well as tooling.
What to take from Alberta’s case study
Alberta’s reported 20-hour scan and estimated comparison with 6.5 years of traditional review illustrate why AI-assisted security deserves attention. They do not prove that an AI agent can replace security teams, nor do they establish an independent benchmark. The defensible takeaway is narrower: AI can help teams examine legacy code at greater scale when deterministic detection, exact evidence, automated tests, isolation and human approval remain part of the control system.
Before expanding access, verify that your team can answer five questions: who authorized the scan, what data can the agent see, how is each finding reproduced, what test proves the fix, and who can stop the workflow? If those answers are documented, an AI-assisted review loop can accelerate defensive work without turning remediation into an uncontrolled production experiment.
Read Anthropic’s official case study on Alberta’s approach.