The security scanner said the release was clean. Priya rolled it out to production on a Thursday afternoon, and by Friday morning she was rolling it back. In between, a vulnerability slipped past a scan that had evaluated her code without the context her team's coding agent already had.
That mismatch, between what the scanner saw and what the agent knew, is the reason the release went out broken.
Priya runs a small logistics platform. She is the kind of founder who reviews every pull request herself because she hired too fast once and paid for it. On that Thursday, she had approved the deployment of a new customer-facing dashboard after the team's scanner returned zero findings. The scanner looked at each file in isolation and saw nothing wrong. The coding agent that wrote the changes, though, had been holding context for weeks: a deprecated internal API, a rate limit the integration was already bumping against, a config change that had landed in a different branch.
The gap between what tools see
The scanner did its job. It evaluated the code in front of it, against the rules it was given, and found no vulnerabilities. That is exactly what it was trained to do. The problem is that the code alone did not contain the vulnerability. The vulnerability lived in the relationship between that code and the environment it was about to enter.
Priya's scanner did not know the internal API was deprecated because that fact existed in documentation and in the agent's context window, not in the code files being scanned. It did not know the rate limit had been raised for a different service and never updated here. It could not see the config change waiting in another branch that would alter how authentication tokens were validated.
This is the limitation at the heart of most code scanning today: it evaluates artifacts, not intent. It checks whether the code you wrote is safe in isolation, not whether it is safe given everything your team already knows about the system it is joining.
What the agent knew that the scanner didn't
Priya's team uses a coding agent for most of their feature work. By Thursday, that agent had accumulated context across the entire project: the deprecation notices, the rate limit history, the conversation where a senior engineer flagged the config change as risky. It had all the information a careful human reviewer would have, and it was using it to write code.
The scanner had none of it.
So when the agent produced code that called the deprecated API, the scanner did not flag it. The call was structurally valid. The API existed. It would work, right up until the point it did not. The scanner also missed the authentication issue because the problem was a combination of two changes that each looked safe on their own. This is the classic class of bug that scanners miss and humans catch: the one that only exists in the combination.
AWS's preview of Continuum points at exactly this problem. It is designed to scan for vulnerabilities with the context of the coding agent that wrote the code, rather than evaluating each artifact in a vacuum. Planned integrations with Claude Code, Codex and Kiro suggest a direction where the scanner and the agent share context instead of working past each other.
What the rollback cost
Priya caught the issue the Friday morning because a customer's dashboard was loading slowly. Not a crash, just a slowdown, the kind of symptom you might dismiss. She dug in, found the deprecated API call hammering a service that was already degraded, and then found the authentication edge case the scanner had missed.
She rolled back inside two hours. The blast radius was contained. But the costs were real: a customer who noticed the slowdown and sent a worried email, a weekend of monitoring instead of rest, and a Monday spent re-reviewing the rollback instead of shipping the next feature. None of this appears in a security report. All of it is the price of deploying code that was scanned, approved, and still broken.
The lesson is not to stop trusting scanners. The lesson is to understand what they actually see. A scanner evaluates code. It does not evaluate your team's accumulated understanding of the system, the history of decisions that led to the current state, or the context your coding agent has been carrying for weeks.
Closing the loop
The direction of travel is clear: scanning is moving from evaluating code in isolation to evaluating it with the full context of how it was written. That is the change worth paying attention to. In the meantime, there are practical steps that cost nothing.
Keep an up-to-date inventory of deprecated APIs and internal services, and make the coding agent and the scanner read the same list. Add a review step that explicitly asks what changed in the environment since the last deployment, not just what changed in the code. And when a scanner returns zero findings, ask what it could not see, not what it checked.
Priya changed her process after that Friday. Her team now runs a simple pre-deployment checklist that includes the question: what has changed outside the code that this release depends on? It is not a tool, and it does not replace the scanner. But it catches the class of problem the scanner missed, the one that only exists in the gap between what the code says and what the team already knows.
Comments
No comments yet.