A year of AI coding / 10
Using AI security review without outsourcing judgment
An AI security finding becomes useful when reviewers can trace the attack path, reproduce the behavior safely, and verify the proposed fix.
By Grafty team · · 3 min read
Written in .
"Possible authorization issue" is a starting point, not a security finding you can act on. A reviewer needs to know which caller can reach the code, what that caller controls, and which check fails to prevent access.
AI-assisted security review is useful when it helps assemble that explanation. It is less useful when it produces a long list of alarming possibilities with no way to distinguish reachable bugs from hypothetical concerns.
Anthropic introduced Claude Code Security on February 20, 2026 as a limited research preview for eligible organizations and open-source maintainers. It described scanning codebases and proposing targeted patches for human review. The announcement was explicitly about assisted defensive work, not autonomous approval of changes or a guarantee that scanned code was secure.
Open full-size diagram Trace a complete path
Consider an internal document service where a handler accepts a document ID and returns a download URL. The query uses parameterized SQL, so a conventional injection check may find nothing wrong.
The relevant question is whether the query also constrains the document to the caller's organization. To answer it, a reviewer must inspect the authenticated identity, the handler, the database query, and any middleware that enforces ownership. A local code pattern may not tell the whole story.
A useful finding would identify the reachable endpoint, explain the missing ownership check, and show a safe test using two isolated test organizations. It would also identify any upstream control that could invalidate the finding. If the service is not externally reachable, that changes the attack path, although it does not automatically make the bug harmless.
We would ask for enough evidence that an engineer can reproduce the result in a controlled environment. Production data is not necessary for this example, and an agent should not probe unrelated systems to strengthen its report.
Open full-size diagram Review the patch as a separate change
A correct diagnosis does not guarantee a correct fix. Adding an ownership filter may solve the immediate issue while changing how administrative users retrieve documents. The patch needs to preserve intended access and reject unintended access.
That suggests paired regression tests: one showing an authorized request still succeeds, another showing the cross-organization request fails. Depending on the application, returning a generic not-found response may also avoid revealing whether a document exists. The appropriate behavior should come from the service's requirements.
We would keep normal review requirements for the proposed patch. Security changes can affect shared middleware and have a wider impact than the original finding suggests. Generated fixes deserve the same scrutiny as other changes in that area.
Keep the reviewer constrained
Security tooling often benefits from broad visibility, which makes its own access worth examining. What source code does it receive? Can it execute tests? Can it reach the network? Are model requests sent to an external provider, and under which retention policy?
An internal execution environment can help control those boundaries, but it does not answer the inference question by itself. The organization should understand both paths before scanning sensitive repositories.
AI security review should complement dependency scanning, static analysis, threat modeling, and human review. Different methods catch different classes of failure. A clean result from one tool is not a general statement about the system.
Our standard for a useful finding is practical: another engineer can follow the evidence, verify it safely, and understand why the fix changes the relevant behavior. That is a more demanding bar than producing a plausible warning, and a more useful one.