The agent fixed the bug. The flaw moved one route over.
Hey there,
In this week’s issue: one thought on agents that fix the bug and miss its twin, five security articles worth your time, and Podcast Corner.
This week’s thought: the flaw one route over
Say your team finds an invoice endpoint that lets a user read another customer’s invoice by changing the ID. Classic IDOR. You ask an agent to fix it. It adds an account check, writes a regression test, and the build goes green.
You look at the patch. It does what you asked. The original request is blocked. You’re ready to close the finding.
Then you open the invoice export endpoint. It calls a different helper and still fetches the record using only the ID. The patch is correct. The same flaw is sitting one route over.
That’s the question I want in every security fix review: where else did we make the same assumption?
Last week I said an AI review still needs evidence. This week, push that evidence past the changed lines. A finding tells you how the app failed. Here, the code trusted an ID without asking whether the caller owned that invoice. That’s a rule, and rules show up in more than one place.
Agents are great at “find me more of these” when you hand them a real example. Give it the finding, the before-and-after diff, and the rule the fix enforces. Point it at neighboring handlers, callers of shared helpers, and any other read or export path for the same object. Have it tell you why each candidate breaks the rule. Then you check its work. That part’s still yours.
Don’t let it hand you every query that takes an ID, either. Some paths already have a middleware check. Some are admin operations on purpose. I’d rather get three real candidates than fifty maybes.
If you keep finding the same missing check route after route, you don’t have a bug. You have a paved-road problem. Authorization should go through one control every route uses.
So close the finding with an answer about its neighbors. Sometimes they already enforce the rule. Sometimes it’s another fix. Either way, you should know why.
Want to try this with your team? There’s a 20-minute exercise in the web version of this issue.
TRY THIS WITH YOUR TEAM · 20 MINUTES
Ask the agent where the same mistake survives.
Choose one recent security fix and sit down with a developer (or do it yourself). Have the finding, the before-and-after diff, and the patched code ready in a dedicated worktree or disposable checkout. Use an isolated test environment with synthetic data. For the invoice example, prepare two test accounts with separate invoices. Adapt the rule below to your application.
First 3 minutes: Write the failed security rule in one sentence. For example: “A customer user may read or export only invoices belonging to their own account.” Name any intentional exceptions.
Next 7 minutes, ask the agent:
Read this finding and its fix. State the security rule the fix enforces. Then find other places that break the same rule: nearby handlers, callers of the changed function, shared helpers, and other read or export paths. Don’t edit anything. For each candidate, cite the file and function, show the missing check, and say what could make it a false positive. Three candidates, max.
Next 7 minutes, validate one candidate together:
Trace the code: Open the cited functions. Does the caller reach the protected data without the required check? Inspect middleware, shared services, and the query before accepting the agent’s conclusion.
Check the behavior: Use the project’s supported test path to exercise one allowed request and one cross-account request. Confirm the allowed case works and the denied case reveals no protected data. Check the response content, side effects, and status. If setup or time prevents testing, record it as unverified.
Choose the follow-up: If confirmed, assign a fix and a regression test for that entry point. If a shared control could prevent the same mistake elsewhere, review its callers and exceptions before changing it. Record why a rejected candidate is already protected.
Final 3 minutes: Attach the search scope, code references, test results, and unresolved candidates to the original issue or pull request. Give each remaining question an owner. Continue the investigation after this exercise when needed.
Leave with one sentence: “The fix enforces ___; we searched ___ on commit ___, verified ___, and ___ will investigate ___.”
Five Security Articles Worth Your Time
Absentia: Detecting Broken Access Control Vulnerabilities in Web Applications. A framework that walks an LLM agent through one route at a time caught 19 of 30 disclosed access-control bugs. CodeQL and Semgrep caught zero. Chris’s take: Stop waiting for a scanner rule to catch authorization. Write the rule down, hand the agent one route at a time, and make it prove every finding. That’s how you hunt access control now.
Findings from the $1M Vercel Sandbox challenge. 1,285 reports, $242K paid, and one Linux kernel zero-day. Chris’s take: “One policy, one decider” belongs on every AppSec team’s wall. When several components enforce the same rule, they’ll eventually disagree, and an attacker will find exactly where.
1Password’s AI patching benchmark is misleading. Trail of Bits picks apart a 26% “clean fix” headline with real patch data. Chris’s take: Don’t let a scary benchmark talk you out of agent patching. Make the agent prove the fix on a second path to the same bug, then have a human review it.
Continue CLI: chained commands bypass the Bash approval rule. An approval rule matched only the start of a Bash command, so chained commands ran unasked. Chris’s take: An approval prompt isn’t a security boundary unless it parses what it’s approving. If your agents run with broad allow rules, tighten them this week, not after a fix ships.
“Everybody with a $20 account is now a researcher”: How Akrites is tackling the flood of AI bug reports. The Linux Foundation’s shared response team uses AI and about 200 seconded engineers to triage AI bug reports before they hit maintainers. Chris’s take: If your AI finding can’t name the control it bypassed, it isn’t a finding yet. Laura Guazzelli nails it: the robots lack context, so a human proves it before maintainers pay.
Podcast Corner
I love making podcasts. Here’s what came out this week.
Application Security Podcast
Vandana Verma Sehgal joins Robert and me on shadow MCP servers, and why you need to know which integrations can act for your developers.
 | From this episode Shadow MCP Servers Are Shadow IT With Direct Access to ActionVandana on why a shadow MCP server is worse than shadow IT. It runs with the developer’s permissions, and your security team probably can’t see it. |
AI Security Table
Izar, Matt, and I rebrand the show, then argue about agent identity, least privilege, and where access control should actually live.
 | From this episode We Never Gave Humans Fine-Grained Access EitherWe let humans read a file and do whatever they want with it. Agents need that spelled out, with the access check living outside the agent. |
Where to find me: I’ll be at OWASP Global AppSec USA in San Francisco, Nov 5–6, moderating a keynote debate and recording a live podcast. Come say hello.
ONE QUESTION FOR YOU
Where did the same bug show up again?
Reply with a fix that led you to another occurrence, or tell me how your team decides when to stop looking.
Chris
