Topic starter
02/08/2026 9:44 am
TL;DR: 15 previously unknown IDOR vulnerabilities and 93 false positives were found across Claude Code and OpenAI Codex runs, according to Semgrep’s analysis, with the strongest results in simple cases where authorization was missing or localized to one file. The bigger lesson is that context, not syntax, determines whether automated reasoning can safely identify access-control flaws.
Editorial analysis by NHI Mgmt Group, based on content published by Semgrep: “Can LLMs Detect IDORs? Understanding the Boundaries of AI Reasoning”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: 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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 12:37 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: LLM IDOR detection still fails when authorization spans files