The machine writes it. Nobody reads where the data goes.
Assistants produce working, plausible, idiomatic code faster than any team can review it properly. The risk isn’t a bug. A bug gets caught. It’s a destination: one more log line, one more payload field, one more vendor call. The code is correct. The data path is new, and nobody decided on it.
Review asks whether it works. Not where the data went.
A reviewer sees twelve changed lines, not the path those lines opened. A new sink looks like one added argument.
An assistant reproduces the habits of the code it learned from, including logging an identifier for debuggability. It is idiomatic, and that is the problem.
Generation got faster. Review capacity did not, and it was never looking for data paths to begin with.
One line. Written by a person, in a good codebase.
This is not AI-generated. It is human-written code in a mature, well-run open-source project, which is exactly why it matters: it is the pattern assistants learned from, and the pattern they reproduce.
A reviewer reads this and sees a debug log on a null branch. It is reasonable. It also writes an email address, in the clear, to wherever your logs go: a destination nobody chose, on a path nobody drew.
Diff the map, not just the code.
A data map is a comparable artefact. Scrutora rebuilds it on every commit, so the question at review time stops being “does this code look right” and becomes something a person can actually answer:
Did this change send personal data somewhere new?
A new edge is a review item. An unchanged map is a merge. That check does not get slower when your team writes more code, however it is written.
A build failure instead of a breach notification.
The scan runs on your runner and returns SARIF, so a new unprotected destination shows up as an annotation on the pull request that introduced it, next to the diff, while the author still has the context.
Run it on the repo your assistant has been writing in.
Nothing leaves your machine. See how the scan works →