Independent validation of what Claude Code built

Reads the source: where secrets live, whether authorisation is enforced on the server or only in the interface, whether data access is injection safe, and which dependencies carry known critical vulnerabilities. Findings cite the file they came from, so a result is checkable rather than asserted.

Builds and runs the application in an isolated environment and probes the running system. This is the layer that answers questions reading code cannot: whether the deployed configuration actually refuses an unauthorised request, and whether error responses leak internals under real conditions.

Tests the deployed application from outside, the way any visitor reaches it: transport security, security response headers, and what the running service discloses about itself. It needs nothing but the address, and what it observes it observes against the running system. Its limit is reach rather than strength: a URL can never establish authorisation, data-layer or backup posture, and those controls stay uncovered.

Authorisation applied on some routes and not others

A session that adds a feature usually copies the pattern in front of it, and the pattern in front of it is whatever the previous session left. That is why the ownership check is present on the routes written early and missing on two written a month later. Nothing regressed, the convention simply never reached them, and a green test run does not notice.

One problem solved three different ways

Three sessions met the same question about validating input, or shaping an error, or deciding who may read a record, and each answered it well. The repository now holds three answers. Every one of them has to be right, changing the rule means finding all three, and the weakest of them is the one that gets exercised.

Tests that assert the feature works, and nothing else

Generated suites are good at proving the happy path. They rarely assert that a stranger cannot reach the record, because nobody asked for that behaviour in the prompt that produced the feature. The absence is invisible: the suite is green either way, and a passing test is exactly what a founder reads as reassurance.

Configuration and secrets moved for convenience

During a long refactor a value gets moved to where the code that needs it can see it, because that is the shortest path to the build passing. The move is fine in the session it happens in and is rarely revisited. A credential that ends up somewhere a client can read it is published from that moment, and taking it out later does not unpublish it.

Dependencies added to solve one problem, then left alone

A package arrives because it answered a question in one session, and no session afterwards has a reason to look at it again. Known vulnerabilities in those packages are public by definition, which makes them the cheapest class of finding to fix and the hardest to defend leaving in place.

The author and the reviewer being the same reader

Asking the agent to review its own work is genuinely useful and it is not the same as an independent check. It sees the files in its context rather than the repository, it cannot run the deployed system, and it carries forward the assumptions it made while writing. What it produces is a conversation. What a buyer, an investor or an enterprise customer asks for is evidence.

What is a Claude Code security audit?

An independent check of a repository that an AI coding agent largely wrote. It tests named controls against published standards, cites the file a source finding came from, and records how strong the evidence behind each result is, so the answer holds up with someone who was not in the sessions that produced the code.

Is code written by an agent less secure?

We would not claim that, and the audit is not built on it. What changed is throughput: far more software now reaches production without anyone having deliberated over the decisions inside it. That makes independent validation worth more than it used to be, whoever or whatever did the typing.

Why not just ask the agent to review the code?

Do that as well, it catches real things. It is not independent. The same model that made the assumptions is checking the assumptions, it sees what is in its context rather than the whole repository, and it cannot probe the running system. It ends in a transcript, and an audit ends in graded evidence you can hand to someone else.

Do you need access to my repository?

For source-level evidence, yes, through a read-only connection. Without it you can still run a URL scan and runtime validation, which establish facts about the deployed system rather than the code. How source is handled is described on the security page rather than summarised here.

What does the audit look at that a code review would miss?

Behaviour. Reading code tells you what should happen when an unauthorised request arrives; runtime validation builds and runs the application and finds out what does happen. Where a run cannot reach a control, it is reported as uncovered rather than assumed to pass.

What do I get at the end?

A result for each control with its evidence grade, an explicit list of the controls the run could not cover, remediation guidance on what failed, and a Passport you can publish if you want to. Publishing is your decision, and nothing becomes public because a scan ran.