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.
Two firms quote you for "an AI penetration test." One comes back at the low end of a normal application testing range. The other comes back at four times that. Same system, same weeks, same described deliverable.
Neither firm is trying to cheat you. They scoped two different engagements, and the quote is the only place that difference became visible. The first priced a chat interface. The second priced an agent that can call your ticketing system, read a retrieval corpus your support team writes into, and act under a service account.
If you cannot tell from a proposal which of those you are buying, the number in it does not mean anything yet.
The cost of an AI penetration test is determined by how much the system can do, not by how large it is. The pricing question is not how many pages or endpoints exist. It is how many actions the model can take, how many data sources can influence it, and how many of those sit inside your control. A chatbot that only answers from a fixed corpus is a small engagement. The same model wired to tools, memory, and other agents is a substantially larger one.
That is the whole reason a single headline price for "AI penetration testing" does not survive contact with a real system. Our general penetration testing cost guide sets out the ranges for conventional engagements, and AI work is priced from the same day-rate economics. What changes is how many days the scope honestly requires — and that is a function of the drivers below.
Because the attack surface is not the code, it is the behavior. In a web application test, the surface is enumerable: routes, parameters, roles. You can count it before you start, and it does not change while you are testing. An AI system's surface includes everything that can reach the model's context — prompts, retrieved documents, tool responses, prior conversation turns — and much of that is populated at runtime by people and systems outside the application.
OWASP makes the same point structurally. The OWASP AI Testing Guide argues AI systems need a dedicated methodology because they "learn, adapt, generalize, and fail in non-deterministic ways." Non-determinism has a direct cost consequence that is rarely stated out loud: a finding you can only reproduce sometimes takes more attempts to establish than a finding that reproduces every time. Testing effort is partly a function of how many times a tester has to run something before the result is defensible.
It is worth being equally honest about the other direction. CISA's position is that "because AI systems are a type of software system, approaches for AI TEVV must fundamentally be a sub-component of the more established software TEVV," and that "the well-established software TEVV methodology is a perfectly valid approach from which to conduct AI evaluations." AI testing is not a separate discipline that justifies an arbitrary premium. Most of what makes it cost more is scope, not novelty — and scope is something you can inspect line by line before you sign.
Seven things move the number, and every one of them is a fact about your deployment that you can answer today. What follows is a composite of engagements we have scoped, illustrative rather than any one client.
How many tools the model can invoke. This is the single largest driver. Each tool is a distinct action the system can be induced to take, and each needs its own abuse cases. One retrieval function is not the same engagement as eleven functions that include writes. OWASP moved Excessive Agency to third place in its 2026 LLM Top 10, which reflects how much of the real risk now sits here.
Whether the retrieval corpus is attacker-writable. If the documents the model retrieves are curated by two people internally, that is one thing. If they are populated from customer support tickets, uploaded files, or a public wiki, an attacker can write into the model's context without ever touching your application. That converts a content question into a full injection surface and is often the difference between a two-week and a four-week engagement.
Self-hosted or API-hosted models. An API-hosted model puts the weights, the training pipeline, and the serving infrastructure outside your control, which honestly removes work from the scope — you assess those through vendor documentation rather than testing them. Self-hosting pulls infrastructure and model supply chain back in. This is a genuine cost reduction for most mid-market buyers, and a proposal that does not reflect it is not scoped carefully.
Whether the agent has its own identity. An agent running under a human's delegated session and an agent running under a long-lived service account are different tests. The second requires tracing what that identity can reach when the agent is persuaded to use it, which is identity and application security work as much as AI work.
Memory and state that persist across sessions. If something a tester plants in one conversation can surface in another user's session later, that is a test that spans sessions and users, and it takes longer to set up and prove.
Single agent or several. NIST draws this line explicitly in its work on control overlays for securing AI systems, separating single-agent use from multi-agent systems where agents "operate cooperatively." Inter-agent trust is its own surface. Two agents is more than twice one.
How often the model changes. A system pinned to a model version you control is testable once. A system that inherits a vendor's weekly updates has no fixed state to certify, which is the argument for continuous testing rather than a larger one-off engagement.
Notice what is not on that list: how impressive the AI is, or how much it cost to build. Those correlate with nothing.
Ask which of the seven drivers above they scoped, and ask them to show you where each one lands in the proposal. A quote that cannot be decomposed into scope decisions is a number someone chose.
Three questions separate a scoped proposal from a priced guess. Which tools are in scope, named individually? Is the retrieval corpus treated as trusted or untrusted, and why? What happens to the price if the model version changes mid-engagement? A firm that has done this work will have answers ready, because these are the questions they had to settle internally to produce the number. A firm that has not will answer in categories rather than specifics.
The cheap-test failure mode is worth naming here, because it looks different in AI work. It is rarely an unqualified tester. It is usually a real tester running a prompt-injection tool against a chat box and reporting the output as an AI penetration test, when nothing that could actually take an action was ever exercised. The deliverable looks complete. It just tested the one part of the system that could not do anything.
We cannot publish a credible price band for AI penetration testing, and you should be suspicious of anyone who does. No standards body publishes one — OWASP, NIST, MITRE, CSA, ISO and CREST all publish methodology and none publishes pricing — and the honest reason is that the variance between two systems described identically is larger than any band would be useful across.
What we can tell you is that the number should be derivable. If a proposal names the tools, states whether the corpus is trusted, says which model deployment it assumes, and specifies what triggers a retest, then the price follows from the scope and you can argue with the scope. If it does not, you are being asked to trust a figure rather than examine one, and that is the same failure this firm argues against everywhere else: a claim presented where evidence belongs, which is exactly the gap an AI security assessment is supposed to close.
For a self-check before you go to market, write down your answers to the seven drivers. Count the tools. Decide whether your corpus is attacker-writable. Name your model deployment. If you can hand that page to three firms, their quotes become comparable — and if they still differ by four times, you now know which one misread it.
Usually, but not because AI testing carries a premium rate. It is priced from the same day-rate economics as any other engagement. It costs more when the system can take more actions and more untrusted sources can reach it, and it costs less when the model is API-hosted and much of the stack is outside your control.
Because "an AI penetration test" describes at least three different engagements. One firm may have scoped the chat interface, another the tool-calling surface, another the full agent including identity and memory. Ask each to name the tools in scope and the difference usually explains itself.
Generally yes. When the model is hosted by a vendor, the weights, training pipeline and serving infrastructure sit outside your control, so they are assessed through vendor documentation rather than tested directly. That removes real work from the scope.
If the change is material and the system's behavior depends on it, yes — a result established against a build that no longer exists is a historical note. Systems that inherit frequent vendor updates are usually better served by continuous testing than by a single annual engagement.
ioSENTRIX is a CREST-accredited, ISO/IEC 27001 certified offensive security firm. We scope AI and ML penetration testing from the drivers above rather than from a category name, so the proposal you receive can be argued with line by line. Where the system changes faster than an annual cycle, we run it continuously instead of pretending a point-in-time result still holds. We are services-first: we assure the stack you already chose, and we do not sell a competing platform.
If you want help turning a vague AI testing requirement into a scope you can price, get in touch.
