Part of the AI coding agent security checklist
How to check that AI-written code is secure
An agent can tell you its code is secure. That is an opinion from the same model that wrote it. This guide covers the checks that do not ask the model, where to run them, and what to read in the diff.
Checked against Claude Code's documentation under Sources and ranwhat's source. Published .
Why the agent cannot check itself
Ask an agent whether the code it just wrote is secure and it answers from the same context, with the same gaps, that produced the code. If it missed an injection hole while writing, it is likely to miss it while reviewing. The answer is useful as a prompt to look harder. It is not evidence.
The checks that do not ask the model
A deterministic check gives the same answer for the same input and does not care who wrote the code. Run several, because each one sees a different kind of problem.
| Check | What it catches | What it misses |
|---|---|---|
| Tests | Behaviour that no longer works, including a test for the abuse case you thought of | Anything nobody wrote a test for, and tests the agent edited to pass |
| Type checker and linter | Whole classes of bug, such as unchecked values and unsafe calls the linter has a rule for | Logic errors and anything outside its rule set |
| Secret scanner on the diff | A key or token written into a file that is about to be committed | A secret that only lives in a transcript or in the environment |
| Dependency audit | A newly added package with a known vulnerability | A package with no advisory yet, or a name that is merely a lookalike |
| Static analysis | Known insecure patterns such as injection sinks and weak crypto, using tools like Semgrep or CodeQL | Design flaws, missing authorisation checks, business logic |
None of these proves the code is secure. Together they remove the mistakes that machines can find, so that your review time goes to the ones they cannot.
Run them where the agent cannot skip them
A check that the agent decides to run is a check it can decide not to run, or edit. Put the gate outside its choices.
Read the diff, not the summary
The agent's summary says what it meant to do. The diff says what it did. Claude Code's own guidance is to review the changes it proposes before you approve them.
What ranwhat does here, and what it does not
ranwhat does not review code. It reads the history your agents already keep, and it looks at what the agent did and what it left behind.
check and watch flag risky actions in the history, such as a credential read, a local file sent to the network, a publish, or a destructive command. clean finds secrets that ended up in transcripts on disk. None of that says whether the code is correct or secure, so it sits beside your tests and scanners and does not replace them. It also blocks nothing unless you install its Claude Code hook.
Where to go from here
Set up the boundary before the review: the secure-by-default setup lists the settings that limit what an agent can do in the first place. For a gate in the agent's own loop, read Claude Code hooks for security. The full list is on the guides page.
Sources
- Claude Code securitysafeguards, no system immune, review before approving
- Claude Code sandboxingwhat the sandbox does not cover, including hooks
- Claude Code permissionsdeny, ask, allow order and what a rule matches
- OWASP LLM01: Prompt Injectionhuman approval for high-risk actions, least privilege
- ranwhat READMEwhat check, watch and clean read and flag