Security review has to follow the change

A small pull request can change who is allowed to read a record. It can give a background job a new credential or connect a file parser to an upload endpoint. The size of the diff doesn’t tell you the size of the security decision.

AI-assisted development makes producing those changes easier. The useful question for security teams is how to review the consequences as the application evolves.

Follow the boundary beyond the diff

A changed authorization helper deserves a look at its callers. A new endpoint needs to be understood alongside the middleware that runs before it. An apparently harmless dependency update can alter how an application parses untrusted input.

Static analysis, dependency checks, targeted tests, and human review each contribute information. An agent can help connect that information, inspect related code, and construct a test for a specific hypothesis.

It still needs the right context. A model looking only at one function may miss the upstream check that makes the path safe. A model given the whole repository may spend its budget on irrelevant files. Selecting and preserving context is part of the engineering problem.

Ask for a demonstration

The most useful output is a finding another engineer can evaluate. State the entry point, the attacker’s starting permissions, the behavior observed, and the boundary crossed.

For an access-control candidate, use accounts with different roles or owners. Show what the restricted account can access and what should have been denied. For a parser candidate, preserve the input and the build that produced the failure.

A script alone isn’t sufficient. Its assertions must measure the claimed effect, and its setup must match the threat model. A test that begins with administrator privileges cannot establish that an ordinary user became an administrator.

Keep review in the workflow

Automation can perform repeatable checks and challenge a candidate in a fresh context. Engineers still need to assess impact, intended behavior, and whether the proposed fix fits the system.

Our blind verification work grew out of that need. Separating discovery from verification gives a candidate another chance to fail before it becomes someone else’s task.

The same discipline applies to dependency research. Public advisories are useful evidence of specific issues and fixes. A download count doesn’t tell us how many deployments use an affected path, and a collection of findings doesn’t prove comprehensive coverage.

Start where mistakes are expensive

A practical rollout can begin with changes to authorization, tenant isolation, credential handling, parsers, and privileged integrations. Use the existing review process to decide which findings were actionable and which tests missed relevant context.

Track the time engineers spend reproducing reports, the confirmed bugs the workflow catches, and the known cases it misses. Those measures say more about usefulness than the number of comments an agent leaves.

Security review keeps pace by making each change easier to understand and test. Generating more assessments helps only when the team can act on them.