September 10, 2026
Mastering IDOR: Finding Broken Access Control Behind Predictable IDs and UUIDs
Mastering IDOR: Finding Broken Access Control Behind Predictable IDs and UUIDs
Salman Khan
New Update: Our new blog is updated.
Free download
Omair Manzoor is the Founder, CEO, and Chief Hacker of ioSENTRIX, a CREST-accredited cybersecurity firm. With 14+ years in offensive security, he has led penetration tests for Fortune 500 companies including engagements for Amazon, Bank of America, VISA, and the London Underground. His exploits are part of the Metasploit Framework and Immunity Canvas. Omair is a published researcher, conference keynote speaker (DOD, CISA, BSides), and technical reviewer for academic security textbooks.
Your last AI security report names a model. Open the gateway config for that application and count how many models can answer a production request today.
If the second number is larger than one, the report describes one path through a system that has many. Microsoft's model router selects per request from two dozen models across five providers. Teams who build their own cascade start with two or three and add more. Either way, the model your tester exercised and the model that answered your customer are not reliably the same model — which changes what a test plan can claim.
Three pressures pushed routing into the architecture, and none were security decisions: frontier pricing on a high-volume workload is the line item that gets a CFO's attention, a small model answers faster, and the requests that truly need the largest model are a minority you would rather spend on selectively.
A router resolves all three at runtime. In the managed case it is itself a trained model that reads the prompt, scores it on complexity, reasoning demand and task type, and picks a target — Microsoft exposes this as balanced, cost and quality modes that widen or narrow the quality band it will trade away to save money. In the hand-rolled case it is a cascade: everything hits the cheap small model first, a confidence check runs, only weak answers escalate. Agentic designs push the same way, reserving the large model for hard reasoning.
The consequence is the point. The model that handles a request is now a runtime decision, made by software, on input an attacker can partly influence. Your execution path is probabilistic. Your test plan probably is not. And failover is silent by design: when a target is unavailable the router redirects to the next eligible model — good availability engineering, and a degraded-day path nobody has exercised deliberately.
What follows is a synthetic composite, illustrative only. It is not any one client.
A support platform routes conversations across three models: a small open-weight model for classification and short replies, a mid-tier model for most conversation, a frontier model for anything flagged complex or escalated. The assessment was scoped, reasonably, to "the LLM feature," and the tester worked the console against the default deployment — the frontier model. Injection was probed, jailbreaks attempted, the filter held. The report reads clean.
Four things are true that it does not cover.
First, the content filter was configured on the frontier deployment. The small model runs self-hosted on the team's own inference stack for cost reasons, and its input filter is a regex list somebody wrote in a sprint. Even inside one managed platform, parity is configuration you verify, not a property you inherit — default safety policies vary by model family.
Second, the small model's safety behavior is weaker in kind, not only in configuration. Published work on safety alignment notes that SLMs are more vulnerable to jailbreak attacks than larger models, and that heavy refusal training is impractical at that scale because the capacity it consumes degrades the task the model was chosen for. A refusal verified on the large model is not evidence about the small one.
Third, the classifier deciding which model gets the request is reading attacker-influenced text. Research presented at COLM 2025 demonstrated query-independent token sequences that reliably steer LLM routers — appended to any prompt, surviving perplexity filtering, transferring across implementations in black-box conditions. That attack forces traffic *up*, a cost drain matching OWASP's LLM10:2025 Unbounded Consumption. Run in reverse it matters more: steer the request *down*, onto the weaker guardrail, then attack that.
Fourth, nothing in the transcript says which model answered. Of the four properties of a trustworthy autonomous action, reconstructable fails outright, and the other three become unverifiable downstream of it.
Guardrail parity. The question is not whether guardrails exist. It is whether the same probe produces the same refusal on every model in the pool. The test is a pinned suite: a fixed set of adversarial probes — jailbreak families, policy-violating requests, exfiltration prompts, whatever your risk register cares about — run against each model individually, bypassing the router with an explicit model parameter. You are not after a pass rate. You are after the *delta* between the best path and the worst, because the worst is the one an attacker will find. Then repeat with the guardrail stack in front; a filter present on one deployment and absent on another is the most common finding here, and the cheapest to fix. Ordinary LLM security testing, run N times instead of once.
The router as a target. If input influences routing, routing is an attack surface, and it sits at the API and gateway layer rather than inside the model. The test has three parts. Force a downgrade: adapt a suffix that pushes a sensitive request onto the cheapest eligible model, then run your guardrail probes through that path. Force an upgrade, the cost-drain case, and see whether anything alerts. Then trigger failover and confirm you land on a model you have assessed. Distinct from prompt injection testing: the payload is not changing the model's behavior, it is changing which model you get.
Path evidence. A finding you cannot attribute to a path is not actionable; an incident you cannot attribute to a path is not investigable. The test is a reconstruction exercise: take twenty consequential responses from last week and determine, from logs alone, which model produced each, under which routing mode and filter configuration, and whether failover occurred. Where the chain breaks, seed a marker — the canary technique works for path attribution as well as data egress, if each model carries a distinguishable instruction and you check which comes back.
Full coverage is not on offer, and pretending otherwise is the failure mode. The path space is the product of models, guardrail configurations, routing modes, tool sets and failover states, and it multiplies faster than any test window. So sample deliberately, and write the rule down.
Ours is worst-case-first, in four passes. Enumerate the pool from configuration rather than documentation, because the eligible model list is version-pinned and moves, the way model drift moves. Test the weakest path first: cheapest model, thinnest filter, highest-privilege operation it can reach. Test the boundaries second — the escalation threshold in both directions, and the failover target. Test the majority path third, where volume-driven risk lives. Then state which combinations were not exercised, and why. NIST's AI RMF asks for that discipline in both directions: MEASURE 2.3 wants assurance criteria demonstrated under conditions similar to the deployment setting, and MEASURE 1.1 wants what cannot be measured documented.
"Four of the eleven reachable paths, here is which four and why" beats "the LLM feature was tested," and it stays honest when someone adds a twelfth model next quarter. That makes it a design-review question as much as a testing one, aging the way any point-in-time test ages, only faster.
None of this eliminates the risk of a system that picks its own execution path. It reduces it, and reveals what you are carrying. Aligning to a framework does not certify any of it; even ISO/IEC 42001, which is certifiable, certifies a management system rather than the proposition that a guardrail held on your cheapest model under attack.
For a self-check, take one routed application that is live today. Can you list every model that can answer a production request, from configuration rather than memory? Can you show the same probe refused on the cheapest path, not only the default one? Can you show what happens when input tries to steer the routing decision, in both directions? Can you reconstruct, from evidence, which model produced one specific answer a customer received last week? And can you name the paths you did not test?
If the honest answer to most of those is "probably," that is where nearly everyone is. It is also the gap, and much cheaper to find on purpose.
We assure routed AI systems across representative paths, not one scripted path: enumerating the reachable model pool from your configuration, testing guardrail parity model by model, treating the routing decision as an attack surface, and handing back the four things that separate evidence from a claim — the attempt, the observed result, the artifact, and the conditions. On a routed system, the model, routing mode and filter configuration *are* the conditions. We also name the paths we did not reach.
A governance review confirms a control exists; a platform's telemetry is the vendor grading its own homework. Independent adversarial testing produces the evidence, whoever performs it. We stay services-first and assure the stack you chose.
If your architecture routes across models and your test plan does not, let's have that conversation.
