Your agent ships faster than you can review it. So who checked what it wrote?

1. 1 · How it happens

   The risky parts don't look risky.

   Your agent writes a feature in minutes and the diff runs to hundreds of lines. You read the part that looked tricky, try the screen, it works. What never looks tricky: a query that takes the project id from the request, a new table with no row-level security, a key read in browser code, a config line like process.env.APP_URL || "http://localhost:3000". Each one compiles, passes and does exactly what it was asked to.

2. 2 · What it costs

   Every one of them ships green.

   A user changes one id in a request and gets another customer's records, with a valid login of their own and no error anywhere. A deploy that forgets one variable boots, answers, and builds every link, redirect and callback against the wrong host until a user reports it. And if nobody has ever restored a backup, nobody knows whether there is one that works, until the day you need it.

3. 3 · Why you haven't seen it

   Its tests check what it meant to write.

   When the same agent writes the code and the tests, the tests describe the path it had in mind: the right user, the right input, the happy ending. A test that signs in as the wrong customer and expects nothing back is the one nobody asked for, so the paths that carry your security are the untested ones. Green means “does what it was written to do”, not “only does that”.

What the free check shows you

Findings like these, for every gap in your app: how serious it is, what is wrong, where it is, and what it costs you if it stays.

prodready · free checkexample · not your app

criticalSecurity Posture

At app/api/projects/[id]/route.ts:18 the project is loaded by the id in the URL, and nothing checks that it belongs to the signed-in user.

Changing one value in a request returns another customer's records: no exploit, no stolen credential, just an identifier that the caller already sees in their own URLs.

Evidenceapp/api/projects/[id]/route.ts:18

highTesting

4 of 31 test files assert anything about unauthorised, forbidden or invalid requests; the suite tests the path where everything goes right.

The paths that carry the security guarantee are the untested ones, so a refactor that drops a role check passes every test and ships green, and the regression is only ever found by whoever tries the URL they should not have.

Evidencetests/

highDeployment Readiness

The application origin at lib/config.ts:3 falls back to a development default when APP_URL is unset, rather than failing.

A deploy that forgets one variable is not detectably broken: the service boots, answers, and quietly builds every absolute link, redirect and callback against the wrong host until a user reports it.

Evidencelib/config.ts:3

Your report names your own tables, files and lines, with a score for the whole app.

See a full sample report →

claude mcp add --transport http prodready https://mcp.prodready.si/mcp --scope user

After the report: when you want the gaps closed the way serious software teams close them, the same prodready connection runs the SDLC on your project. How that works →