LLM grounding beats F1, but IDOR recall still hits a wall

At a glance

What this is: This is an analysis of LLM-based IDOR detection benchmarks, showing that grounded findings are more reliable than F1 alone suggests, but recall remains weak across models.

Why it matters: It matters because teams adopting AI-assisted code review need to understand that trustworthy-looking detections can still leave most vulnerable paths undiscovered, especially where authorization logic is distributed across handlers and resource types.

By the numbers:

• Of the 27 real IDORs in this repo, 19 were missed by every model.
• 17 minutes.
• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments.

👉 Read Semgrep's analysis of groundedness, F1, and IDOR detection

Context

IDOR detection is a good test case for AI-assisted code security because the vulnerability often looks simple while the real control failure sits deeper in the request path. In practice, models can detect a familiar pattern without proving they understand the authorization logic that makes it unsafe, which is why benchmark design matters as much as the raw score.

For identity and access teams, the same problem shows up in non-human identity governance and agentic AI security. A system can appear to recognise access risk while still missing the ownership, entitlement, or lifecycle control that would stop misuse in production.

Key questions

Q: Where do AI code scanners fail in practice on IDOR vulnerabilities?

A: They fail most often when authorization is distributed across multiple request steps, resource lookups, or downstream services. A scanner may recognise a familiar unsafe pattern, but still miss the deeper ownership logic that should block access. That means teams need to review not just the vulnerable line, but the full control path from request to resource.

Q: Why do grounded findings matter more than raw F1 scores for security tools?

A: Because F1 can look strong even when a model is arriving at the right answer for the wrong reason. Grounded findings survive patching, renaming, and repeated scans, which means they are more likely to generalise outside the benchmark. For practitioners, that is the difference between a useful detector and a brittle pattern matcher.

Q: How do security teams know whether an AI-assisted scanner is trustworthy?

A: Look for repeatability, sensitivity to small code changes, and consistent discrimination between real vulnerabilities and safe look-alikes. If a tool flags different issues on every run or collapses when identifiers change, its output is too unstable for automated triage. Trust should come from reproducible behaviour, not a single impressive result.

Q: What does weak IDOR coverage mean for code security programmes?

A: It means the organisation may believe it has coverage because the tool finds obvious cases, while deeper authorization flaws remain untouched. That creates a false sense of control, especially in systems with layered handlers and mixed resource types. Programmes should combine AI review with manual threat modelling and targeted access-control testing.

Technical breakdown

Why F1 can hide weak security reasoning in LLM scanners

F1 combines precision and recall, but it says nothing about whether a model reached a finding by genuine reasoning or by pattern matching. In code security, that distinction matters because a model can be consistently right on familiar examples and still fail when the surrounding structure changes. Groundedness tests whether the finding survives counterfactual patching, semantic renaming, and look-alike negatives. That makes it closer to a control test than a scorecard, because it asks whether the model is responding to the actual flaw rather than the surface shape of the code.

Practical implication: evaluate AI-assisted scanners with grounding tests, not only aggregate accuracy metrics.

Why IDOR detection fails when authorization is spread across the request path

IDOR is not just a missing if-statement. In many real applications, ownership checks, ACL lookups, and resource validation are distributed across handlers, services, and downstream data access methods. That creates a reasoning problem for scanners, because the vulnerability is only visible when the model traces the full path from request to resource. This is why deep IDORs are harder than tutorial examples. The model must infer that access control is absent even when no single line obviously exposes it.

Practical implication: prioritise code review and scanning coverage for multi-hop authorization flows and resource ownership checks.

Why coverage and stability matter more than one-off catches

Coverage measures how many distinct vulnerabilities a model can surface, while stability measures whether it finds the same issue repeatedly across scans. A tool with high coverage but poor stability may be guessing, and a highly stable tool may be conservative enough to miss broad classes of flaws. The benchmark shows that these trade-offs are real: some models are wider but flaky, others are narrow but consistent. For security operations, that means confidence in a result is only useful if the model can reproduce it under slightly different conditions.

Practical implication: require repeatable scan results before using AI findings to drive remediation priorities.

NHI Mgmt Group analysis

Groundedness is now a baseline requirement for AI security tooling, not a research curiosity. A scanner that cannot distinguish real authorization failures from surface similarity is not fit for operational use. This benchmark shows why reasoning quality matters separately from headline precision and recall, especially in code security where false confidence can be worse than a missed alert. Security teams should treat groundedness as a control property, not a nice-to-have metric.

Coverage collapse exposes the real control gap: distributed authorization logic. The hardest IDORs in this benchmark were not the obvious file-download mistakes that tutorials teach, but the deeper cases where ownership checks were buried across request flows and unfamiliar resource types. That is the same class of failure that appears in NHI governance when entitlement logic is fragmented across systems. Practitioners should assume the visible pattern is not the real risk boundary.

Model diversity does not automatically create security coverage diversity. The study’s union recall only marginally improved over the best individual model, which means multiple scanners can still share the same blind spots. That is a warning for programmes that believe ensembling alone solves detection gaps. The better question is whether your tooling stack can surface different failure modes, not whether it can re-label the same easy ones.

For identity programmes, the lesson extends beyond code scanning into governance. If a system can appear to understand access risk without consistently proving it, then reviewers need stronger lifecycle controls, entitlement scoping, and audit evidence around both human and non-human access paths. This is where identity governance and security engineering meet: the model is only useful if the surrounding control plane can absorb its misses. Practitioners should align AI-assisted review with access governance, not substitute it.

What this signals

Groundedness will become a procurement and governance filter for AI-assisted security tools. Teams will increasingly need to ask whether a scanner can prove why it flagged something, not just how often it flags. That shifts evaluation toward reproducibility, control-path coverage, and auditability, especially for codebases where access logic is fragmented and easy to misread.

Identity governance needs to absorb AI-assisted review rather than assume it replaces manual control. In programmes that manage human and non-human access, the real risk is delegating judgment to a system that still misses the deepest authorization flaws. The safer operating model is to use AI for prioritisation while keeping entitlement review, access certification, and exception handling under explicit governance.

Coverage gaps in scanners mirror coverage gaps in identity control planes. When the visible pattern is easy but the real failure is buried in workflow depth, the organisation needs stronger control mapping, not just better detection. That is why access governance, code review, and runtime verification should be treated as linked controls rather than separate teams.

For practitioners

• Test AI scanners for groundedness, not just accuracy. Run counterfactual, metamorphic, selectivity, and stability checks on the same codebase so you can see whether findings survive patching, renaming, and repeated scans. Use these results to separate genuine reasoning from pattern matching, then gate production use on reproducibility rather than a single strong run.
• Map authorization paths before trusting model output. Inventory every multi-hop access decision where object ownership, ACL checks, or downstream validation are split across services. That makes it easier to spot the deep IDORs models miss and to focus human review on the request paths most likely to hide missing enforcement.
• Pair AI-assisted review with identity governance controls. For applications that expose user-scoped resources, tie scanning results to ownership enforcement, entitlement reviews, and change control so a missed finding does not become a silent access gap. This is especially important where non-human identities or service accounts can traverse the same paths as users.
• Measure repeatability before operationalising findings. Track whether the same vulnerability is detected across multiple runs, model variants, and small code changes. If findings are flaky, treat them as investigative leads rather than remediation triggers, and require human validation before assigning risk priority.

Key takeaways

• LLM security benchmarks need groundedness because F1 can mask pattern matching that does not generalise to real code paths.
• IDOR recall remains weak across models because the hardest failures live in distributed authorization logic and unfamiliar resource types.
• Security teams should validate repeatability, control-path coverage, and auditability before trusting AI-assisted scanners in production workflows.

Key terms

• Groundedness: Groundedness is the degree to which an AI response can be supported by verifiable source material. In practice, it measures whether the model answered from evidence rather than inference, memory, or fabrication, which is critical for RAG systems and any workflow that drives decisions from model output.
• 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.
• Selectivity: Selectivity is the ability of a detection system to avoid flagging safe code that merely resembles a vulnerability. It is a useful measure because real application logic often contains look-alike paths, and weak selectivity creates false positives that reduce trust in the tool.
• Stability: Stability is the consistency of a model or scanner across repeated runs on the same target. In practice, a stable tool should surface the same issue under small variations, because flaky detection makes remediation priorities unreliable and weakens confidence in the results.

What's in the full report

Semgrep's full analysis covers the benchmarking details this post intentionally leaves for the source:

• The exact per-model grounding results across counterfactual, metamorphic, selectivity, and stability tests.
• Repository-specific scan behaviour that shows where open-weight and frontier models diverge on IDOR detection.
• The full method for validating whether repeated scans are stable enough to use in production triage.
• A second benchmark direction on SSRF grounding that extends the same reasoning test to another vulnerability class.

👉 Semgrep's full post covers the benchmark method, per-model results, and the SSRF preview.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through the NHI Foundation Level course, the industry's only accredited NHI security programme. It helps security and IAM practitioners build a stronger control model for the systems that govern access, delegation, and lifecycle risk.