Claude Code Security Audit: A Practical 2026 Workflow

What is a Claude Code security audit?

A Claude Code security audit is the practice of using Claude Code as an "AI security reviewer" - reading the meaning of your code to find vulnerabilities, rather than only pattern-matching like a traditional linter. Because the model understands data flow and the intent of a function, it catches issues that regex-based tools routinely miss: user input flowing into a concatenated SQL string, an endpoint missing an authorization check, or an API key dropped straight into source.

The vulnerability classes Claude Code tends to catch include: injection (SQL, command, NoSQL, XXE), broken authentication and authorization (IDOR, privilege escalation, weak sessions), data exposure (hardcoded secrets, PII in logs), weak crypto (poor RNG, bad key management), misconfiguration (CORS, security headers), and supply chain risk (dependencies with known CVEs).

This guide covers two approaches:

• Native /security-review - a built-in Claude Code command plus a first-party GitHub Action from Anthropic, released in August 2025 (anthropics/claude-code-security-review, accessed 08/2026). It reviews pending changes, scores severity, and suggests fixes, with a false-positive filter built in.
• The prebuilt ak-security skill - a packaged prompt bundle covering STRIDE + OWASP A01-A10, stack-aware dependency auditing, multi-persona red-teaming, and a --fix mode, so you never have to hand-write a long prompt.

The official documentation on Claude Code's security model lives at code.claude.com/docs/en/security (accessed 08/2026) - worth reading before you grant the AI permission to run commands in your repo.

Before you audit: setup

Three minutes of prep keeps the session clean and reversible:

• Claude Code installed and signed in. If you are not there yet, follow the Claude Code installation guide.
• A clean Git working tree (git status shows nothing pending). You want a clear diff to tell apart what the AI proposes, and to roll back with git restore if a patch breaks something.
• Decide the scope up front: a single folder (src/api/**), the files you are currently changing, or the whole repo. A narrow scope is faster and cheaper on tokens.
• Only audit TRUSTED code. This is the important warning to raise early: when you let the AI read code from a stranger's repo or PR, malicious content in that code can inject instructions (prompt injection) that trick the model. For untrusted code, review it manually or run it in an isolated environment.
• Check command permissions. Review Claude Code permissions and safe execution so the AI cannot run a destructive command on its own during the scan.

The 6-step Claude Code audit workflow

This is the backbone of the whole session. Work sequentially from narrow to broad so the results stay readable and you do not burn tokens for nothing.

Step 1 - Define the scope

Start by naming exactly what you want reviewed. For a small change, let Claude focus on the diff; for a large repo, fence it off with directory globs on the sensitive areas (auth, payments, uploads, public APIs). Ask Claude to read every in-scope file before analyzing - otherwise the model tends to guess from function names. An opening prompt:

Read all files in src/api/ and src/auth/ first.
Do not change anything yet. Just list the areas with an attack
surface (external input, DB access, auth handling) so I can pick a scope.

Step 2 - Run /security-review on pending changes

For the changes you are about to commit, run the native command right in the Claude Code session:

/security-review

This reviews the pending diff, classifies severity, and proposes a fix for each finding. It runs on the strongest available Claude model (configurable) - think of it as a security reviewer reading your PR before a human gets to it. This is the fastest place to "shift left": catching issues while the code is still warm and has not landed on the main branch yet.

Step 3 - Scan the whole repo with STRIDE + OWASP

To dig deeper than the diff, give Claude a structured threat-modeling prompt. STRIDE maps quite cleanly onto the OWASP Top 10. A copy-paste template:

Audit all in-scope code across the 6 STRIDE categories, mapped to the OWASP Top 10:
- Spoofing -> A07 (identification/authentication failures)
- Tampering -> A03 (injection), A08 (data/software integrity)
- Repudiation -> A09 (missing logging/monitoring)
- Info Disclosure -> A02 (crypto), A01 (access control)
- Denial of Service -> note it, but only report with clear impact
- Elevation of Priv -> A01 (broken access control)

For each finding, record: severity, category, file:line, a short description,
and a concrete fix. Do not report theoretical issues you cannot tie to real impact.

Step 4 - Audit dependencies

Vulnerabilities often live not in the code you wrote but in the libraries you pulled in. Run the right tool for your stack, then let Claude synthesize and prioritize:

npm audit # Node.js
pip-audit # Python
govulncheck ./... # Go
bundle audit # Ruby

Then paste the output to Claude: "Rank these CVEs by real exploitability in my project, and skip anything that only sits in devDependencies and never reaches production." Claude helps cut the noise - not every CVE is on your actual execution path.

Step 5 - Hunt for hardcoded secrets

Ask Claude to scan for API keys, passwords, tokens, and private keys embedded directly in source and config files. A note on credential hygiene: when reporting, mask the real values to <REDACTED_TOKEN> before you log or commit the report - do not let a secret leak out of the very file that audits for it.

Scan the whole repo for hardcoded secrets (api keys, passwords, tokens,
private keys, DB connection strings). For each finding, record only file:line
and the TYPE of secret, and mask the value to <REDACTED>. Do not print real values.

Step 6 - Classify severity and export the report

Ask Claude to collect every finding into one table by severity, with clear action thresholds:

To keep the results, ask Claude to export a Markdown report with a severity count summary at the top ("2 Critical, 3 High...") - that format drops cleanly into an issue tracker or a review for your lead. If you run audits regularly, keep dated reports in a security/ folder (with the sensitive parts gitignored) so you can compare runs and spot which vulnerabilities reappear or slip through review.

A real audit session: how to read findings

Here is the part that both English and Vietnamese competitors almost entirely skip: an actual findings table, not a feature description. Below is an illustrative result from a sample Node/TypeScript project (API + auth) so you can see what the output looks like - run it on your own repo to get your own table:

How to read it: work top to bottom by severity. Finding #1 blocks the release - no argument there. #2 and #3 go straight into the sprint. #4 (IDOR) is often underrated but is an extremely common access-escalation flaw. For each row, open the exact file:line, confirm the issue is real (not a false positive), and only then patch - do not patch blindly off the report.

A quick verification trick before you patch: ask Claude back, "Prove finding #4 is exploitable: write a concrete request that user A would use to read user B's order." If the model can build a specific exploitation scenario, it is a real vulnerability; if it hedges or has to assume unrealistic conditions, it is likely a false positive and you can lower its priority. This adversarial step filters out noise and helps you explain the risk to the rest of the team in concrete attacker language instead of abstract jargon.

Patching a vulnerability - a real before/after

Take finding #1 (Critical, SQL injection) as the example. Here is the kind of code that is easy to get wrong:

// BEFORE - vulnerable to SQL injection
export async function getUser(id: string) {
 const sql = "SELECT * FROM users WHERE id = '" + id + "'";
 return db.query(sql); // the id input flows straight into the SQL string
}

And after patching with a parameterized query:

// AFTER - parameterized, the driver escapes it
export async function getUser(id: string) {
 const sql = "SELECT * FROM users WHERE id = $1";
 return db.query(sql, [id]); // the id value travels through the parameter channel, not the SQL string
}

Why it is safer: in the second version, id is no longer concatenated into the SQL string but passed through a separate parameter channel. The database driver treats it as data, not a command - so a string like ' OR '1'='1 can no longer change the structure of the query.

For an automated flow, the prebuilt skill offers --fix to patch findings one at a time, run a guard test against regressions after each patch, then commit each fix separately. But always review the diff before merging - and when a patch breaks a test, do not guess. Instead, debug a fix that breaks tests with the AI to find the real cause.

Automation: security review on every Pull Request

To have every PR scanned automatically, use the first-party GitHub Action. Add a .github/workflows/security.yml file:

name: Security Review
on: [pull_request]
jobs:
 review:
 runs-on: ubuntu-latest
 permissions:
 pull-requests: write
 contents: read
 steps:
 - uses: actions/checkout@v4
 - uses: anthropics/claude-code-security-review@main
 with:
 claude-api-key: ${{ secrets.ANTHROPIC_API_KEY }}

The Action comments findings directly on the PR, so a reviewer sees them right away.

Required caveat: per Anthropic, this Action is not yet hardened against prompt injection. Only run it on trusted PRs and enable "Require approval for all external contributors" in your Actions settings - otherwise a malicious PR from a stranger could inject instructions that trick the review process.

To round out the defensive layer, combine it with a safe Git workflow with Claude Code and consider adding a pre-commit hook that scans for secrets before code ever reaches the remote.

Advanced red-team: auditing from 4 attacker personas

One STRIDE pass is good, but real vulnerabilities tend to surface when you think like a specific attacker. Running the audit from 4 different viewpoints yields clear information gain:

• Security Adversary - looks for auth bypass, injection variants, IDOR: "If I log in with a regular account, can I read or edit anyone else's data?"
• Supply Chain - dependencies with known CVEs, poisoned CI/CD, typosquatting in packages.
• Insider - horizontal/vertical privilege escalation, bulk data export, abuse of an internal account's permissions.
• Infrastructure - SSRF, secrets leaking in environment variables, misconfigured container/network settings.

Writing out all 4 personas by hand is a lot of work, because each angle needs its own prompt set and checklist. This is exactly where prebuilt, structured threat modeling saves you hours of prompt writing.

Using the prebuilt ak-security skill (skip the prompt writing)

Instead of hand-writing the STRIDE prompt, the 4 red-team personas, and the --fix flow every time, the AgentKit bundle — now $149 (from $198) packages all of it into the ak-security skill (part of the Engineer Kit, $99; the site lists a money-back guarantee and lifetime updates, and does not state a recurring fee). How to use it:

/ak:security src/api/**/*.ts # scan a narrow scope
/ak:security full --red-team --fix # whole repo, 4 personas, auto-patch

It bundles STRIDE + OWASP A01-A10, stack-aware dependency auditing, secret detection, severity scoring, and sequential patching with a guard test. See which security skills the Engineer Kit includes to weigh it against your needs.

To be honest: the skill only makes the prompt writing and the workflow more convenient - it does not "turn the AI into a pentester". Native /security-review is enough for most needs; the kit is worth considering when you audit frequently and want multi-persona red-teaming from a single command.

One line to disambiguate: AgentKit here is a kit for Claude Code (agentkit.best, the ak CLI), not OpenAI's AgentKit (Agent Builder/ChatKit).

Real limits, and when NOT to trust the AI

Security is close to YMYL territory - being honest about the limits matters more than hype:

• Prompt injection. Do not audit unfamiliar code blindly. Untrusted code can inject instructions that steer the model into ignoring vulnerabilities or running unintended commands.
• False positives and false negatives. By default /security-review filters out the DoS, rate-limiting, resource-exhaustion, open-redirect, and input-validation classes it cannot tie to demonstrable impact - so "scanned clean" does not mean "perfectly safe". Conversely, the AI still misses subtle business-logic flaws (race conditions, TOCTOU, complex authorization logic).
• It does not replace a professional pentest. This is a shift-left tool for catching issues early and cheaply, not a security certification. SAST/DAST and manual pentesting are still needed for critical systems.
• Token cost. Scanning a large repo takes meaningful tokens and time; fence the scope to sensitive directories instead of running full every time.

Frequently asked questions (FAQ)

Is the /security-review command free?

The command and the GitHub Action are open source from Anthropic, so there is no separate fee to use them. The real cost is the Claude Code token/usage under whatever plan you are on (Pro, Max, or the per-token API).

How is a Claude Code audit different from traditional SAST?

SAST mostly matches fixed patterns and rules, so it tends to be noisy. Claude Code reads semantics and data flow, so it catches context-dependent issues (like IDOR or authorization logic) that pattern-matching misses - at the cost of being less deterministic and needing human confirmation.

Can AI replace a professional pentest?

No. It is a shift-left layer for catching issues early and cheaply, not a certification. Critical systems still need manual pentesting, alongside SAST/DAST in the pipeline.

Is it safe to audit someone else's code?

There is a prompt-injection risk: untrusted code can inject instructions that mislead the model. Only audit trusted code, or run it in an isolated environment with manual approval enabled for external contributors.

How many tokens and how much time does an audit take?

It depends on scope. Reviewing a small diff takes a few minutes and few tokens; scanning a large repo takes far more tokens and noticeably longer. Fence the scope to sensitive directories to save.

How is the ak-security skill different from writing my own prompt?

It packages STRIDE + OWASP, 4 red-team personas, and the guard-tested --fix flow into a single command, saving prompt-writing effort. On detection capability it is roughly equivalent to writing a good prompt yourself - the difference is convenience and consistency, not being "fundamentally stronger".

Conclusion and next steps

A Claude Code security audit will not replace an expert, but it turns vulnerability hunting into a cheap, fast habit - run /security-review before each release, do a periodic STRIDE scan, and automate it on trusted PRs. Next, expand into comprehensive AI code review and shore up the foundation with security best practices for Claude Code. And do not forget: a periodic audit before every release beats one deep scan you then forget about.