Finding a vulnerability is one thing. Knowing how far to go to prove it is another.
Broken access control remains a serious problem. In Edgescan’s 2026 Vulnerability Statistics Report, three of the four most common critical and high-severity vulnerabilities on public-facing systems map to OWASP A01, Broken Access Control. Insecure direct object reference (IDOR) accounts for 5.37% of them on its own.
This piece follows one IDOR through an Atomic, AI-powered penetration test assessment, from the first sign of it to the evidence that reaches your platform. It also takes on a question every autonomous testing product has to answer: once AI finds a vulnerability, how far should it go to prove it? The scenario is illustrative, and the steps reflect how Atomic works.
Why authorization flaws are easy to miss
An IDOR happens when an application checks that a user is logged in but doesn’t check whether the record they’ve requested belongs to them. Change an ID in a request, and one customer can read another customer’s data.
Scanners struggle with this class of flaw. The request is well formed and the response is a normal success. Nothing about it looks like an attack unless you know who owns the record and who is asking for it. Finding it means testing as more than one user and comparing what each can reach.
That’s why authorization testing depends on test identities. With a single account, a tester can spot the signs of a flaw but can’t confirm it. With two accounts at the same privilege level, plus one at a different level where roles matter, the flaw can be demonstrated and measured.
Teams preparing for any penetration test, automated or expert-led, get more from it when they supply those identities up front.
Finding the candidate
Atomic starts with what Edgescan already knows about the application, including its attack surface, known endpoints and previously validated findings. Reconnaissance agents build on that context, and one of them analyzes client-side JavaScript for functionality the interface doesn’t link to.
In this case, the JavaScript references an API endpoint that returns account documents by ID. Nothing in the visible interface calls it directly. The endpoint is recorded as an unconfirmed candidate for the access control team to test.
Testing it
Atomic can use multiple test identities. Working as one user, it will request a document belonging to a second.
The request is checked against the harness-approved scope, and the harness controls whether it can be executed.
The application returns the document
That’s the critical moment. A user has been able to retrieve information belonging to another account, but before that becomes a confirmed vulnerability, the result needs to be independently verified.
Deciding how far to go
At this point, a human attacker would widen the search, looking at other IDs, other record types and write access. Some of that matters for your team. A read-only flaw on one record type carries different risk from one that lets any user modify any account.
Each step further also carries a cost in a live application. Retrieving large numbers of records would expose real customer data during a test meant to protect it. Writing to a record could corrupt data the business depends on.
Atomic’s proof is designed to establish impact without damaging data or disrupting the application. The test identities make that possible, because the flaw can be demonstrated against data that belongs to the test.
Agents choose from vetted test points and payloads, and the Harness refuses any action outside what the engagement permits.
Confirming the finding
A separate verification agent reviews what the testing agent did and independently attempts to reproduce the result.
Only findings that pass independent verification are reported to the Edgescan platform, with the evidence needed to understand what was tested and why the result matters.
Had the engagement supplied only one test identity, Atomic would have surfaced the candidate as unverified, with the reason stated. The gap could then be closed before the next run. Retest agents later re-examine confirmed findings to establish whether they’ve been fixed.
What your team receives after your AI-Powered penetration test
The finding arrives with its history: how the endpoint was discovered in the JavaScript, why it was selected for access control testing, the requests made as each identity, the responses returned and the verification steps that confirmed it.
Findings are ranked by real impact and appear in the Edgescan platform alongside scanning and penetration testing results.
For a developer, that history shows exactly where the ownership check is missing. For a security lead, it shows what ran against the application and why the result can be trusted.
Because finding a vulnerability shouldn’t mean creating another security problem in the process.
See how Atomic proves what it finds. Book a demo.
Want to see Atomic for yourself? Join the Atomic Under the Hood sessions with Michael and see how it works, how we keep autonomous testing safe, what we’ve learned, and how it all stacks up.
