Authorization bug hunting gets cheaper, but validation becomes decisive

At a glance

What this is: This analysis argues that authorization bug discovery has become cheap enough for attackers and defenders alike, so the hard problem has shifted to trustworthy validation of apparent IDOR and access-control hits.

Why it matters: IAM and security teams need to assume the volume of authorization testing will rise, which makes evidence quality, false-positive suppression, and modelable access boundaries more important across API and application programmes.

By the numbers:

• GLM-5.2 scored 39% F1 on IDOR and authorization-vulnerability detection.
• The model found vulnerabilities at roughly $0.17 per vulnerability found.

Context

Authorization flaws are rarely signature problems. They live in the gap between what an API returns and what the caller was supposed to be allowed to see, which means standard scanners can miss them and fast automation can misread them.

That makes the governance problem twofold: discovery has to scale, but so does validation. For identity and access teams, the issue is not only whether an endpoint can be probed, but whether the resulting evidence can be trusted as a real boundary violation.

The article’s core claim is that the economics of authorization testing have changed, so defenders cannot rely on attacker effort as a natural control anymore.

Key questions

Q: What should security teams do first when automation starts finding more authorization bugs than humans can review?

A: Start by defining the access model the application is supposed to enforce. If you do not know which roles, tenants, and user states are allowed to see which objects, automation will mix real boundary breaks with intended access. The first control is not more scanning, but clearer authorization ground truth for validation.

Q: Why do cheap authorization scanners produce so many false positives?

A: Because many authorization failures are only visible when you reason about intent, ownership, and tenancy. A 200 OK can still mean denied access, shared access, public data, or a soft 404. Without context, automation confuses response shape with policy violation.

Q: How can teams tell a real IDOR from intended shared access?

A: Compare the observed response against the application’s role and object model, not just the status code. If the caller is entitled to the resource through a team, tenant, or self-access rule, the result is not an IDOR. If the caller crossed a boundary the model forbids, it is.

Q: How do you reduce false positives in automated authorization testing?

A: Use a second review step that re-reads the evidence against the inferred authorization model before findings reach a human. The reviewer should be able to overturn a fast exploit result when the access was public, self-directed, or otherwise allowed. That is how scale stays trustworthy.

Technical breakdown

Why authorization bugs evade scanners

Authorization defects are logic problems, not pattern-matching problems. An endpoint can look healthy to a scanner while still leaking another user’s record, because the flaw sits in the relationship between caller identity, object ownership, and the response body. IDOR, broken access control, and tenant isolation gaps all require reasoning about intended access, not just HTTP syntax. That is why cheap breadth-first testing is useful, but insufficient on its own. Practical implication: validate authorization findings against the application’s actual access model, not just the returned status code. See the Authorisation Models Guide.

Practical implication: model expected access boundaries before treating any hit as a vulnerability.

Why a second model is used to review successful exploits

The pipeline described here separates exploit generation from exploit validation. The first pass attempts candidates at scale and collects transcripts. The second pass re-reads those transcripts against the inferred roles and user states, asking whether the apparent success was truly unauthorized, merely public, or a response that looked like access but was not. This is a cross-examination step, not more probing. Practical implication: keep the validation gate independent from the exploit generator so speed does not outrun judgment. See the IAM and IGA Basics.

Practical implication: separate generation from validation so volume does not create false confidence.

What counts as a real authorization violation

A real authorization violation is not any 200 OK. It is access that crosses a boundary the application should enforce, such as a low-privilege user reading an admin record, one tenant reaching another tenant’s data, or a banned user doing something their state should prevent. The validator’s job is to distinguish that from self-access, shared resources, soft 404s, empty payloads, and other outputs that can fool an automated hunter. Practical implication: define and test the intended access states explicitly, including public, shared, restricted, and self-access cases.

Practical implication: enumerate permitted states so automated review can separate legitimate access from abuse.

Threat narrative

Attacker objective: The attacker or tester aims to identify and prove access-control failures at scale, turning cheap model output into exploitable authorization findings.

1. Entry occurs through broad authorization testing against an API surface, where cheap model-driven probing generates many candidate access-control failures.
2. Credential or identity context is inferred from supplied personas and roles, then used to decide whether the observed response should have been visible to the caller.
3. Escalation happens when a false positive is mistaken for a real boundary break, or a real cross-tenant or privilege-crossing access is confirmed.
4. Impact is the creation of a short, trustworthy set of genuine authorization findings that a human can act on without re-checking every candidate.

Breaches seen in the wild

• McHire default password flaw 2025: A forgotten test admin account with the password 123456 and an API flaw exposed McDonald's McHire applicant records to researchers.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Authorization testing has crossed the cost threshold where discovery is no longer the scarce capability. When a cheap model can hunt IDOR and broken access control at scale, the limiting factor shifts from finding candidates to deciding which ones are real. That changes the identity governance conversation from scarcity to assurance. Practitioners should assume more automated probing, not less, and treat validation quality as the control that now carries the burden.

Trustworthy validation is now the differentiator in application security operations. A high-volume exploit generator can flood teams with plausible hits, but the only durable edge is the ability to reject false positives without suppressing genuine boundary breaks. That means the programme has to reason about role, ownership, tenancy, and user state as first-class access concepts, not as after-the-fact labels. The implication is that authorization evidence quality becomes a governance problem, not just an engineering one.

End-to-end automation only works when the system is allowed to doubt itself. The article’s strongest idea is not that models can find bugs, but that a second model can overrule the first without new target traffic. That pattern matters for authorisation models because access decisions must be evaluated against the application’s intended policy, not just a response code. Practitioners should treat self-cross-examination as a governance pattern, not a convenience feature.

False positives are now a scale problem, not a nuisance problem. The more cheaply authorization bugs can be found, the more expensive each mistaken alert becomes in engineer time and trust debt. That creates a new operational constraint: teams need a repeatable way to separate intended shared access, public data, and genuine cross-boundary exposure before findings reach humans. The practical conclusion is that validation discipline is now part of access-control resilience.

Runtime reasoning about access must match the application’s real authorization model. This is where machine-driven testing either earns trust or collapses into noise. If the inferred model is wrong, even a successful exploit transcript can be meaningless; if the model is right, the same transcript becomes a reliable indicator of a true breach of access policy. The practitioner takeaway is to make authorization modelling explicit before scaling automated testing.

Read next: Authorisation Models Guide

What this signals

Trust debt will become the main bottleneck in machine-driven authorization testing. The more cheaply bugs can be surfaced, the more important it becomes to prove that each alert crosses a real access boundary. Teams will need validation logic that understands tenancy, role, and object ownership, or they will drown in plausible noise.

Authorization governance is moving from detection to decision quality. In practice, that means the standard for automation is no longer whether it finds more issues, but whether it can distinguish intended access from a genuine policy break. Programmes that do not invest in that distinction will spend their gains on manual rework instead of risk reduction.

For practitioners

• Define the application’s intended access states Document which roles, tenants, and user states can see which objects before automated testing begins. Include public, shared, self-access, restricted, and admin-only cases so validation has a ground truth to compare against.
• Separate exploit generation from exploit validation Keep the high-volume probe stage and the decision stage independent so a fast model cannot self-certify weak evidence. Require the reviewer to weigh ownership, tenancy, and response meaning before any finding is accepted.
• Treat 200 OK responses as evidence, not proof Inspect response bodies, resource ownership, and state transitions before classifying a hit as a real authorization failure. A successful HTTP call is only meaningful when the caller crossed a boundary it should not have crossed.
• Record false-positive reasons as first-class outcomes Capture why a candidate was filtered, such as public data, self-access, shared resources, soft 404s, or defensive blocks. That history improves reviewer trust and helps tune future authorization checks. See the NHI Lifecycle Management Guide.

Key takeaways

• Authorization testing is getting cheaper, which means the quality of validation now matters more than the volume of candidate findings.
• The most common failure mode is confusing a successful request with a real access-control breach.
• Teams that define their access model clearly can let automation scale without handing humans a flood of false positives.

Related NHI Mgmt Group resources: Authorisation Models Guide · IAM and IGA Basics · NHI Lifecycle Management Guide · Ultimate Guide to NHIs: Key Challenges and Risks

Key terms

• Authorization Model: An authorization model is the structure an organisation uses to decide who can do what, and under which conditions. It combines decision logic with enforcement so access is granted or denied in a consistent way across applications and services.
• IDOR: Insecure Direct Object Reference is a vulnerability where an application exposes internal object identifiers and fails to verify whether the requesting principal is entitled to access them. The flaw often produces unauthorized reads, writes, or account-level actions.
• False Positive Validation: False positive validation is the process of re-checking an apparent vulnerability against the real access model before a human sees it as fact. For automated authorization testing, this means proving whether a response truly crosses a policy boundary or only looks suspicious.
• Tenant Isolation: Tenant isolation is the practice of separating identities, tokens, sessions, logs, and data so one tenant cannot access another tenant's resources. It can range from full physical or logical separation to carefully controlled shared services with strict tenant-aware policy enforcement.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.