LLM IDOR detection still fails when authorization spans files

At a glance

What this is: Semgrep’s analysis shows coding agents can find some real IDOR flaws, but they miss and misread access control once authorization is distributed across files, middleware, or framework-level logic.

Why it matters: IAM and application security teams should treat LLM vulnerability detection as context-sensitive assistance, not autonomous review, because hidden or cross-file authorization logic changes the reliability of findings.

Context

IDOR is an access-control failure, not a syntax error. A request may look harmless at the line level while still exposing private data if the application fails to verify object ownership, membership, or role before returning it. That makes authorization context the real security boundary, especially when checks live outside the visible function.

This article is about how LLM-based code review handles that boundary in practice. Semgrep’s findings show the models are more reliable when authorization is explicit and local, but they struggle once policy is spread across files or enforced implicitly by middleware and framework hooks. That is a familiar governance problem for complex application estates, not an isolated model quirk.

For security teams, the key question is whether machine-assisted review can follow the path from user input to access decision across the full application context. Where that path is fragmented, human review and explicit control mapping remain necessary.

Key questions

Q: What breaks when IDOR authorization is spread across multiple files?

A: Reviewers and coding agents lose the full access-control path, so they can no longer tell whether a request is protected by a check in another module, decorator, or middleware layer. That creates both false positives and false negatives. The practical fix is to trace ownership and role validation end to end before treating a finding as real.

Q: Why do IDOR findings become unreliable when middleware enforces access control?

A: Because the security decision is no longer visible in the endpoint body. If authentication or role checks happen automatically in middleware or inherited classes, a model may misread a protected route as open, or miss a misconfiguration that weakens the policy. Teams should validate the hidden control path, not just the handler function.

Q: What are the signs that automated IDOR review is losing context?

A: A growing mix of false positives, inconsistent reruns, and findings that only make sense after manual tracing are the strongest signals. When the model starts flagging apparently public objects, framework-managed checks, or multi-file RBAC logic without clear evidence, it is probably missing the application’s real authorization boundary.

Q: How should security teams evaluate AI tools for IDOR detection?

A: Evaluate the full workflow, not just the model. A useful tool should show how it discovers endpoints, gathers context, and reasons about object ownership checks. Compare precision, recall, and cost per true positive on the same codebase so you can see whether the harness or the model is doing the real work.

Technical breakdown

Why IDOR depends on authorization context

IDOR occurs when an application exposes an object identifier, such as a user ID, invoice ID, or filename, and fails to verify that the requesting principal is entitled to that object. The vulnerability is rarely visible from a single line of code because the dangerous part is the missing relationship check, not the data fetch itself. That is why two controllers with nearly identical database access can differ completely in security outcome. In practical terms, the analyst has to understand who owns the object, who may access it, and where that decision is enforced.

Practical implication: review the ownership and membership checks that sit beside each object lookup, not just the lookup itself.

Why cross-file authorization defeats simple reasoning

When authorization logic is split across files, decorators, middleware, or framework configuration, the security decision no longer lives in one visible code path. A model or reviewer that inspects only the endpoint function can misclassify a protected route as vulnerable, or the reverse, because the decisive control is imported, inherited, or injected elsewhere. This is common in real web stacks that use route wrappers, policy helpers, or context-specific RBAC. The problem is not only complexity, but distributed control visibility.

Practical implication: trace authorization from request entry point through all imported policy layers before treating a finding as real.

Why implicit framework controls create false positives and false negatives

Framework-level authorization can be effective, but it is also easy to miss because the relevant check is executed automatically rather than in the function body the reviewer is reading. That creates a detection problem for both humans and coding agents: the endpoint appears open, yet the framework may still enforce authentication, role checks, or access gating in inherited methods or decorators. The reverse can also happen when a hidden control is assumed to exist but is misconfigured or incomplete. In other words, implicit policy raises the burden on context reconstruction.

Practical implication: validate middleware, inheritance, and route decorators as first-class security controls, not as implementation details.

NHI Mgmt Group analysis

LLM-based IDOR detection is fundamentally a context reconstruction problem. The models can do well when the relevant authorization logic is compact and explicit, but they degrade as soon as control paths become distributed across files or framework hooks. That means the limiting factor is not just pattern recognition, but the ability to assemble a complete access decision from scattered evidence. For application security teams, the practical conclusion is that model output must be judged against the full authorization path, not the endpoint surface alone.

Authorization visibility gap is the decisive failure mode here. The article shows that IDOR findings become unreliable when the security decision is no longer visible where the data access occurs. That is an important governance lesson for human review as well, because teams often assume a visible function contains the whole policy when in fact the policy is inherited, wrapped, or injected elsewhere. Practitioners should treat distributed authorization as a control-design risk, not a tooling inconvenience.

Simple IDORs remain a useful target for AI-assisted review, but complex ones still need human triage. The strong results in localized cases suggest coding agents can extend the reach of secure code review, especially for missing checks and narrow access-control gaps. But the false-positive burden and non-determinism show that automation has not yet reached independent decision quality for multi-layer authorization. Security teams should use these systems to surface candidates, not to close the loop without review.

AI-assisted vulnerability detection will improve only if the application’s authorization model is made machine-readable in practice. That does not mean rewriting every system, but it does mean reducing hidden policy paths, clarifying ownership rules, and keeping access-control logic easier to trace across components. The article’s results point to a broader truth for both human and machine reviewers: if security decisions are implicit, dispersed, or framework-dependent, they are harder to verify. Practitioners should design for auditable authorization paths.

Machine review for IDOR should be measured by access-control coverage, not by raw finding counts. The 15 true positives are meaningful, but the 93 false positives show why volume alone is not a success metric. Security leaders should judge these tools by how well they preserve reviewer time, reduce missed real bugs, and handle distributed policy without inventing flaws. That frames AI as an accelerator for triage, not a substitute for authorization reasoning.

From our research library:

• Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• Read next: AI Agent Authorisation Guide

What this signals

Authorization visibility gap: the harder it is to trace an access decision from request to policy enforcement, the more likely AI review is to misclassify IDOR risk. That makes code structure itself part of security governance, because hidden checks are harder for both humans and machines to verify.

The practical signal for security teams is simple: when findings cluster around cross-file RBAC, middleware, or inherited controls, model output should move into assisted triage rather than automatic remediation. That is where the review process must be designed to absorb context, not just extract alerts.

For practitioners

• Audit authorization paths across files Map every IDOR candidate from the request entry point through decorators, middleware, inherited classes, and helper functions before deciding whether the access control is complete.
• Separate local checks from implicit policy Tag endpoints that rely on framework-level or inherited authorization so reviewers can distinguish visible control logic from checks that execute automatically.
• Use human triage for distributed RBAC Require manual validation for any finding where ownership, membership, or role checks are split across multiple files or configuration layers.
• Measure model quality by true positives and false positives Track how many findings survive review in simple versus cross-file cases, then use that split to decide where AI-assisted review is actually saving time.

Key takeaways

• LLM-assisted IDOR detection works best when authorization is explicit and local, and it degrades when the access decision is spread across files or enforced implicitly.
• The study found 15 previously unknown vulnerabilities but also 93 false positives, showing that useful findings still arrive with substantial noise.
• Teams should treat these tools as triage accelerators and validate ownership, membership, and role checks across the full request path before acting.

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.
• Distributed Authorization: Distributed authorization is the practice of deciding access when identity, resource, and relationship data live in different services. It requires a shared policy model or a reliable decision service so that access checks stay consistent as applications split apart and business logic crosses boundaries.
• Implicit Access: Access that is not granted directly but is inherited through roles, groups, nested entitlements, or shared paths. It often expands the real exposure surface beyond the obvious permission list and is a common source of governance blind spots.
• False Positive: A false positive is a scanner result that looks like a secret but is not actually sensitive. In secret governance, false positives matter because they consume analyst time, weaken trust in alerts, and can delay response to the findings that truly change exposure and access risk.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and machine identity security. It gives practitioners a structured way to connect identity controls to broader security programmes.