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.
Pull one row from your audit log: the call your support automation made last Tuesday, the one that exported a customer record. The log line says `svc-support-automation`.
Now answer four questions. Whose request set it in motion. Which component made the call. Which credential it presented. What else that credential could have done.
Most teams answer the first from a ticket and none of the rest from anything. The trail ends at a service account name — a label on a shared key, not an identity. Human identity got twenty years of lifecycle discipline. Machine identity got a secrets manager and a promise to rotate.
Every agent is a principal. So is every MCP server it connects to, every tool connector, every CI job that builds it, every third-party OAuth grant on your SaaS tenant. One agent with six tools is not one new identity — it is a small population, created at build time and never seen by an identity team. Published machine-to-human ratios vary too much to borrow; count your own, across cloud IAM, CI, OAuth grants and the secret store.
The OWASP Non-Human Identities Top 10 maps the failure modes: improper offboarding, secret leakage, overprivileged identities, long-lived secrets, reuse across environments. None of that is new. What is new is the rate at which agentic architecture manufactures more of it, and that the identity now sits behind a component deciding for itself.
A confused deputy is a privileged component acting for a less privileged requester on its own authority: the requester supplies intent, the deputy supplies permissions. An agent is a near-perfect deputy. It holds a credential broad enough to serve every user it might serve, and cannot reliably separate instructions from data — ticket bodies, retrieved documents and tool descriptions all arrive as tokens in one context window. That is the mechanism behind prompt injection, and the identity consequence gets skipped: when the injection lands, the downstream API sees `svc-support-automation` behaving normally, inside its granted scope. OWASP's Top 10 for Agentic Applications files this under identity and privilege abuse.
The tool layer has a mechanical version. The Model Context Protocol's security best practices name two failures worth testing directly. An MCP server acting as an OAuth proxy with a static client ID, while letting clients register dynamically, breaks once the third-party authorization server sets a consent cookie: an attacker-registered client with its own `redirect_uri` rides that cookie, skips consent, and takes the authorization code. And token passthrough — accepting a token never issued for you and forwarding it on — is forbidden outright, because the downstream log then names the wrong principal.
The lifecycle failures are duller and more common. A credential is minted for a prototype and scoped generously, because precise scoping takes an afternoon and the demo is Thursday. The prototype is praised and abandoned. The credential has no owner, no expiry, and never surfaces in an access review — reviews look at people. Nobody offboards a bot. And because credentials get copied between environments, revoking one is frightening enough that nobody does.
A synthetic composite, not a real client or incident. A support agent reads tickets and queries a customer database through an internal API. Its database credential was cloned from an old ETL job, so it reads every tenant. Its helpdesk OAuth grant carries admin scope from a pilot. The chain authenticates downstream as one service principal, so every action logs the same actor. None of those is critical alone. Together, a crafted ticket body reads another tenant's data, and the evidence to prove it does not exist.
Impersonation. The chain drops the original actor. The orchestrator authenticates as itself and the tool never knows a human was involved. Effective privilege at the last hop is not the requesting user's — it is the union of every user that service principal can act for. Front-door authorization becomes decoration.
Inherited scope. The orchestrator's token is reused verbatim at every hop, so the least trusted component — often a third-party MCP server you did not write — runs with the broadest grant in the system.
OAuth 2.0 Token Exchange (RFC 8693) is the vocabulary for doing this properly: at each hop, swap the token for a narrower one, audience-bound to that resource and carrying an `act` claim that records the delegation, so a log can name both subject and actor. Most stacks did not choose impersonation over delegation; they arrived at it because the SDK made it the shortest path. NIST SP 800-207 already treats per-request authorization as the baseline.
Naming a risk is cheap. Here is what we run, and what each returns. They map to the four properties of a trustworthy autonomous action — genuine, authorized, untampered, reconstructable — from AI Integrity.
1. Principal resolution. Perform a known action through the agent, then rebuild the chain from logs alone: initiating human, agent, credential, granted scope, downstream call. Pass condition: a second engineer, given only the logs, reaches the same answer. Tests *reconstructable*, and fails most often.
2. Privilege ceiling. Take the credential out of the agent and exercise it directly against the API — everything it is permitted to do, not what the workflow uses. Then diff granted scopes against scopes exercised over thirty days of logs. That delta is the blast radius, and it is a number.
3. Cross-boundary access. Two seeded tenants. Drive the agent from tenant A's context toward tenant B's data, first by parameter manipulation, then by planted instruction. If the agent's credential reads both, isolation was never enforced where it mattered. Tests *authorized*.
4. Confused deputy. Plant an instruction in content the agent will read — a ticket body, an indexed document, an MCP tool description — asking for a privileged action. Record whether it executed and whose identity the downstream system logged. Then test the OAuth path: re-register a client with a changed `redirect_uri` and see whether a fresh consent screen appears, and present a token minted for another audience to see whether it is accepted. Finally, diff the request the orchestrator emitted against the one the downstream tool received: an intermediary that rewrites scope or parameters breaks *untampered*. Tests *genuine* and *untampered*.
5. Revocation. Not "do you rotate secrets." Revoke the credential, have the agent do its job, and measure time to failure. If it keeps working, something cached it and revocation is a document, not a mechanism.
6. Offboarding. Decommission a test agent by your documented process, then hunt its identity everywhere: cloud IAM, CI, SaaS OAuth grants, secret store, downstream API key lists. Whatever survives is your offboarding gap, as a count.
Tests 1 through 4 need adversarial conditions, which is why a control review and a penetration test are different exercises. Tests 5 and 6 you can run yourselves this quarter. Two limits: threat modeling the chain comes first, because scoping an unmapped chain wastes the engagement; and framework alignment is not proof — ISO/IEC 42001 certifies a management system, not that a scope held. None of this eliminates the risk; it reduces it.
Six questions for your team this week. Can you name the human behind an agent action from logs alone? Do you know the delta between granted and exercised scope for your top five machine identities? Has anyone driven the agent across a tenant boundary on purpose? Has anyone planted an instruction in content it reads and checked whose identity the downstream log recorded? When you revoke a credential, how long until the agent notices? When an agent retires, how many of its identities outlive it?
If four of those get an honest shrug, the gap is not tooling. It is that nobody has been asked to prove it.
We test non-human identity the way we test everything else: by trying to break it and writing down what happened. That means mapping the agent-to-tool chain, enumerating the identities it creates, measuring granted against exercised privilege, and running the confused-deputy and cross-boundary cases in a scoped environment. What comes back is not a maturity score — it is the attempt, the result, the artifact and the conditions.
Independent adversarial testing produces that evidence, whoever performs it. If you are running agents in production and cannot answer the four questions at the top of this post, that is the conversation to have.
