LLM IDOR detection still fails when authorization spans files

At a glance

What this is: This is Semgrep’s analysis of how coding agents perform on IDOR detection, and the key finding is that they work best when authorization is simple and visible, but struggle when checks are distributed or implicit.

Why it matters: It matters because IAM-style access logic inside applications, including RBAC and object-level checks, is exactly where automated reasoning can overcall or miss a real exposure, creating both false positives and missed authorization gaps.

By the numbers:

• In the first study, 78% of Claude's IDOR findings were false positives.
• The models found 15 real, previously unknown vulnerabilities, as well as 93 false positives.
• Anthropic Claude Code found 13 true positives and 46 false positives, for a 22% true positive rate.
• OpenAI Codex GPT-5-Codex found 2 true positives and 42 false positives, for a 4.5% true positive rate.

👉 Read Semgrep's analysis of how Claude Code and OpenAI Codex perform on IDOR detection

Context

IDOR is not a syntax problem, it is an authorization problem. The vulnerable pattern appears when an application lets a user influence an object identifier, then fails to verify whether that user is allowed to access the resulting object. In identity terms, the control failure sits at the boundary between application logic and access policy, where RBAC and object-level authorization are supposed to agree.

Semgrep’s research shows why this class is hard for AI coding agents to reason about reliably. When authorization is explicit and local, the model can often infer the failure mode. When checks are split across files, hidden in middleware, or dependent on framework conventions, the reasoning task becomes context-heavy and the false positive rate rises sharply. That is a familiar pattern for security teams that depend on code understanding rather than runtime evidence.

Key questions

Q: What breaks when IDOR checks are missing on object identifiers?

A: When an application accepts a user-controlled object identifier without binding it to ownership, tenancy, or role, an attacker can access another principal’s record simply by changing the value. The failure is not in lookup itself, but in the missing authorization decision that should constrain which object the requester is allowed to reach.

Q: Why do IDOR findings get noisier when authorization is spread across files?

A: Because the decision is no longer visible in one place. If route handling, role checks, and policy rules live in different modules, a model or reviewer may miss the effective control path or assume one exists when it does not. That creates both false positives and missed vulnerabilities.

Q: How can security teams tell whether an IDOR fix is actually complete?

A: A complete fix ties the object being requested to the current user’s entitlement, not just to the object’s existence. Teams should verify ownership or tenancy, confirm the right role or relationship, and test a cross-object request that should fail even when the identifier is valid.

Q: Who is accountable when application authorization fails on object access?

A: Accountability sits with the team that owns the application’s authorization model, not just the developers who wrote the endpoint. Where middleware, decorators, and RBAC helpers all contribute to the decision, security and engineering must jointly define, document, and test the effective access path.

Technical breakdown

Why IDOR depends on object-level authorization context

IDOR exists when a request can select a database row, file, or record by identifier, but the application does not verify that the current subject is entitled to that object. The difficult part is not object lookup, it is policy binding. A controller may fetch the correct object and still be unsafe if it never checks tenancy, ownership, role, or relationship constraints. This is why identical-looking code can be either benign or vulnerable depending on the surrounding authorization model. Practical detection requires understanding intended access rules, not just tracing data flow.

Practical implication: map object identifiers to explicit authorization checks, not just to data retrieval paths.

RBAC logic becomes fragile when it is spread across files

Role-Based Access Control can be effective, but automated reasoning weakens when the permission decision is split between route handlers, decorators, helper functions, and configuration files. In that pattern, no single function contains the full truth about whether access is allowed. LLMs and static tools may see a data access call and miss the upstream role gate, or they may miss a missing gate because the policy is implied elsewhere. The issue is not RBAC itself, but the visibility of the policy chain across the codebase.

Practical implication: centralise policy evaluation or maintain traceable references from route to role decision.

Implicit middleware controls create hidden authorization paths

Framework middleware can enforce access rules before a controller runs, which means the security decision may never appear in the code fragment being reviewed. That makes detection harder for tools that inspect only local scope, because the apparent vulnerability may already be blocked earlier in the request lifecycle. The same pattern also creates the opposite problem: a reviewer may assume middleware exists when it does not, or may misread which requests bypass it. Effective analysis needs the full request path, including inherited decorators and automatic hooks.

Practical implication: review authorization at the request lifecycle level, including inherited and framework-applied controls.

Threat narrative

Attacker objective: The attacker wants to bypass application-level authorization and access objects belonging to another user, tenant, or role.

1. Entry occurs when an attacker manipulates a user-controlled object identifier in a request, such as a user ID, invoice ID, or file reference.
2. Escalation follows when the application returns an object without verifying ownership, tenancy, or role-based entitlement for the current user.
3. Impact is unauthorized access to records that should remain isolated, often including PII, financial data, or internal business objects.

NHI Mgmt Group analysis

Authorization visibility is the core failure mode in AI-assisted IDOR detection. The models in this study performed best when the access rule was visible in one place and worst when the policy was distributed, implicit, or hidden behind framework mechanics. That is not a reason to dismiss AI-assisted code review. It is a reminder that detection quality depends on whether the system can reconstruct the full authorization chain, not merely inspect the vulnerable endpoint. Practitioners should treat visibility of policy as a control objective, not a convenience.

Hidden authorization creates the same governance problem for humans and machines. When route decorators, middleware, and config files jointly define access, reviewers must infer the effective policy from multiple sources. That increases the odds of both false positives and missed exposures. In governance terms, the issue is not just whether RBAC exists, but whether the policy is auditable end to end. Teams should prefer control designs that make entitlement decisions explicit, searchable, and testable.

Object-level access checks need a named governance concept: policy traceability debt. This is the accumulation of uncertainty created when entitlement logic is scattered across files, decorators, and framework hooks. As policy traceability debt rises, tool accuracy falls and human review slows. The practical conclusion is simple: if a reviewer cannot reconstruct the access decision quickly, the application is already operating with weak authorization observability.

AI coding agents are useful for narrow authorization gaps, not for replacing security judgement. The study shows real value when the flaw is local and the missing control is obvious. It also shows that broader application awareness is still essential when business logic, RBAC, and middleware interact. The security team that wins here is the one that uses AI to surface candidates and humans to validate policy intent.

What this signals

Policy traceability debt will become a practical benchmark for AI-assisted security work. As more teams use coding agents to review authorization logic, the difference between a visible policy and a distributed policy will matter more. If a control cannot be reconstructed quickly from code, configuration, and middleware, both automation and human review degrade. That is why access review quality increasingly depends on architectural clarity, not just tooling depth.

Security teams should expect AI-assisted vulnerability discovery to remain strongest where access logic is local and weakest where the application depends on framework conventions or hidden hooks. That means the most valuable remediation is often architectural. Make authorization explicit, testable, and easy to trace, and you improve both security assurance and tool accuracy.

For practitioners

• Inventory every object identifier exposed to users Map routes, GraphQL resolvers, and API parameters that reference user IDs, tenant IDs, invoice IDs, filenames, and other direct object references. Then verify that each one has an attached ownership, tenancy, or role check before the object is returned.
• Trace authorization from entry point to policy decision Review the full request path, including decorators, middleware, inherited base classes, and config files, so you can see where access is actually enforced. A controller that looks unsafe may be protected upstream, but a controller that depends on hidden logic is also harder to audit and test.
• Write negative tests for cross-object access attempts Add tests that try to fetch another user’s, tenant’s, or organisation’s object by changing only the identifier. These tests should fail unless the current principal is explicitly entitled to the object being requested.
• Measure policy traceability across the codebase Track how many authorization decisions can be reconstructed from one file versus how many require hopping across multiple modules. The more hops needed, the more likely both human review and AI-assisted analysis will produce noise.
• Use AI findings as triage inputs, not final verdicts Treat model output as a candidate list for security review, especially when the application uses framework-level authorization or custom RBAC. Validate every candidate against the intended access model before accepting a fix or filing a defect.

Key takeaways

• AI coding agents can find real IDORs, but only when the authorization model is visible enough to reason about correctly.
• The main failure mode in this study is not lack of signal, but lack of context, which drives false positives when policy is scattered or implicit.
• Security teams should treat object-level authorization as an auditable control path and use AI output as a triage layer, not a final decision engine.

Key terms

• Insecure Direct Object Reference: Insecure direct object reference is an access control flaw where an application exposes an identifier that allows callers to reach records or objects they should not be able to access. In practice, it means the system trusts the request too much and fails to verify object-level permission on each access.
• Broken Object-Level Authorization: A failure to check whether an authenticated identity may access a specific object, record, or device. The request succeeds because the credential is valid, but the application does not enforce per-object entitlement. In NHI environments, this turns a legitimate token into cross-resource exposure.
• Traceability Debt: Traceability debt is the accumulated inability to reconstruct where data went, who accessed it, and how it was used across a fragmented environment. It becomes a governance problem when teams cannot answer privacy, audit, or incident questions quickly enough to meet regulatory obligations.
• Role-Based Access Control: A model that grants permissions by assigning identities to predefined roles. It works well when jobs are stable and access patterns are predictable, but it becomes brittle when exceptions pile up. In practice, role design must stay small enough to audit and broad enough to avoid endless custom variants.

What's in the full report

Semgrep's full research post covers the implementation detail this post intentionally leaves for the source:

• The four-category breakdown of IDOR cases, including which patterns produced the highest true positive rates.
• The exact prompt structure and repeatability observations that shaped the model comparison.
• The table showing per-model true positives, false positives, and category-level performance.
• The code examples that illustrate how authorization hidden in decorators, middleware, or framework hooks affected detection.

👉 Semgrep's full post shows the category breakdown, repeatability findings, and code examples behind the results.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, machine identity security, IAM, and secrets management. It helps practitioners connect identity controls to broader security programmes without losing policy intent.