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.
The scope section of the statement of work says: Test the customer-facing AI assistant.
That is one sentence, and it is the sentence the whole engagement will be argued from. Four weeks later, when the report says nothing about the ticketing integration the assistant can write to, everyone will reread it and discover it was never excluded — it was never included either. Nobody was wrong. The scope simply did not resolve to a list of things.
A scope document is the most direct artifact of actually doing this work. It is also the page a buyer reads immediately before signing, which is why it deserves more care than it usually gets.
An AI penetration test scope should enumerate every surface that can influence the model's behavior or be reached by it, and state explicitly which of those are in scope and which are not. At minimum that means the application and its interfaces, the prompts and system instructions, the retrieval mechanisms and data sources, memory and stored state, the tools and APIs the model can invoke, the orchestration layer, and the downstream systems that act on the model's output. A scope that names only "the AI" has enumerated nothing.
That list is not ours. It is close to how CREST describes the surface in the Security Testing of AI accreditation it introduced in August 2026, which states that testing "needs to also consider applications, prompts and system instructions, retrieval mechanisms, data sources, memory, tools, plugins, APIs, orchestration layers and downstream systems influenced by AI outputs." It is worth reading that sentence as a scoping checklist, because it is the most complete public enumeration currently available from a testing body.
Because it names a component, and the risk does not live in the component. It lives in what the component is connected to. A model on its own can produce bad text. A model wired to a tool can take a bad action, and the action is what anyone actually cares about.
This is the same failure mode as scoping a web application test by naming the application rather than the routes, with one difference that matters. In a web application, the connections are visible in code. In an AI system, a connection can be created at runtime by a document somebody uploaded. If the retrieval corpus is written to by your support team, or by customers, then the corpus is part of the attack surface even though nothing in your architecture diagram says so. OWASP's own guidance is blunt about the trust boundary: treat "all external data as untrusted (user messages, retrieved documents, API responses, emails)."
The practical consequence is that scoping an AI test is largely an exercise in discovery, and it benefits enormously from having threat modeled the system first. If the scoping call does not produce a list of tools by name and a decision about the corpus, the scope is not finished, and both sides are agreeing to find out later.
Seven, and each needs its own line in the document. What follows is a composite drawn from engagements we have scoped, illustrative rather than any one client.
The interface and its instructions. The prompts and system instructions that shape behavior, and whether they can be extracted or overridden. For a customer-facing assistant this is the surface everyone remembers to test, and often the only one. OWASP's 2026 LLM Top 10 covers this under prompt injection and a new entry for hidden context exposure.
The retrieval layer. Which corpora the model reads, who can write to them, and whether retrieved content is treated as data or as instruction. This is the surface most often left out and most often productive.
The tool and function-calling surface. Every function the model can invoke, named individually, with read and write clearly distinguished. Excessive agency sits third on the 2026 OWASP list, and this is where it is tested. A scope that says "integrations" instead of listing them has deferred the argument.
Identity and privilege. What the agent authenticates as, what that identity can reach, and whether its permissions were scoped for the agent or inherited from something older. OWASP's separate Top 10 for Agentic Applications treats identity and privilege abuse as its own category, distinct from the LLM list.
Memory and persistence. Whether state carries across turns, sessions, or users, and whether one user's planted content can surface in another's session. Testing this spans users by definition, so it has to be authorized explicitly.
Orchestration and inter-agent trust. If more than one agent is involved, how they authenticate to each other and what one can cause another to do. NIST separates single-agent from multi-agent deployments in its control-overlay work for exactly this reason.
Downstream systems. What acts on the model's output without a human reading it first. This is usually where a finding becomes a real-world consequence, and it is usually owned by a team that was not on the scoping call.
The OWASP AI Security Verification Standard is a useful cross-check here: it is a community-driven catalogue of testable security requirements for AI-enabled systems, organized so you can walk a scope against it chapter by chapter and see what you left out.
Four things that a standard rules of engagement document does not cover, because conventional testing never needed them.
The model version, pinned and recorded. A result established against a model build that no longer exists is a historical note. The scope should say which version was tested and what happens if the vendor updates it mid-engagement.
A reproduction standard for non-deterministic findings. Decide up front how many successful attempts make a finding real, and record attempt counts in the report. Without this, every borderline result becomes a negotiation at debrief.
Data handling for anything the model emits. Testing data leakage means the tester may surface real records. Say in advance what happens to them — ideally, test with synthetic canary data so the question does not arise.
What is explicitly out of scope, and why. For an API-hosted model, the weights, training pipeline and serving infrastructure sit outside your control and are assessed from vendor documentation rather than tested. Write that down. An unstated exclusion reads as an oversight when the report lands.
It should say what a finding must contain before it counts. This is the part buyers most often leave to the vendor, and it is the part that determines whether the report is usable afterwards.
Require four things per finding: the attempt, in enough detail to be repeated; the observed result, meaning what the system did rather than what the tester concluded; the artifact — a log line, a response, a captured request; and the conditions, including the model version and the date. That standard is what separates a test from an assertion about a control, and putting it in the scope means you do not have to argue for it at delivery.
A good scope does not make an AI system safe, and it does not cover everything — it cannot. What it does is make the gaps deliberate. Every system has surfaces nobody will pay to test this quarter, and the difference between a mature program and an anxious one is whether those exclusions are written down and chosen, or discovered afterwards in a meeting.
Being clear about our position: this is not a methodology only one firm can run. Testing an AI system is documented work, and several good firms do it well. What we would insist on regardless of who you hire is that the scope resolves to a list — of tools, corpora, identities, and downstream consumers — rather than to a category.
For a self-check, take your last AI testing SOW and try to answer four questions from the document alone. Which tools were in scope, by name? Was the retrieval corpus treated as trusted or untrusted? Which model version was tested? What was excluded, and why? If the document answers all four, you scoped a test. If it does not, you bought a category — which is a normal place to start, and a poor place to stay.
A conventional scope enumerates the application's own surface — routes, parameters, roles. An AI scope has to also enumerate everything that can reach the model's context at runtime, including retrieval corpora and tool responses, and everything downstream that acts on its output.
If anyone outside a small trusted group can write into it, yes. A corpus that is populated from support tickets, uploaded files, or a shared wiki is an injection surface regardless of what the architecture diagram shows.
You test what you control and document the rest. For an API-hosted model, the weights, training pipeline and serving infrastructure are assessed through vendor documentation rather than tested directly, and the scope should state that explicitly as an exclusion.
Yes. Each tool is a distinct action the system can be induced to take and needs its own abuse cases. "Integrations are in scope" is not a scope statement — it is a deferred argument.
ioSENTRIX is a CREST-accredited, ISO/IEC 27001 certified offensive security firm. Our AI and ML penetration testing engagements start by turning "test the AI" into a named list of tools, corpora, identities and downstream consumers, and the scope document says what is excluded as clearly as what is not. Where the system changes faster than an annual cycle, we run it continuously. We are services-first: we assure the stack you already chose.
If you have a draft SOW and want a second opinion on what it leaves out, get in touch.
