How AI agents test authorization: differential tests across accounts

An AI agent tests authorization by differential testing: it compares what different callers can do with the same request. It signs in as several test accounts, replays each request under each account, and checks whether the server enforces the rules. The same method finds IDOR (insecure direct object reference), which OWASP's API list calls Broken Object Level Authorization.

What is differential testing for authorization?#

Differential testing sends the same action as different callers and compares the results. The difference, or the lack of one, shows whether access control works. A tester needs one baseline and several variants.

• Baseline: the owner of an object makes a request. This shows what correct access looks like.
• Variants: another account in the same role, an account in a lower role, an account in another tenant, and an anonymous caller make the same request.

If a variant gets the baseline response, the server did not enforce the rule. The first thing to rule out is that the data is public by design. For the manual version of this method, see our sister site's IDOR testing guide.

How does an AI agent run the test?#

The agent follows the same loop for any endpoint. In Incursion, a planner splits the engagement into tasks and workers run them in parallel. A worker handling authorization does this:

1. Map. Sign in as each test account and record every request the app makes, including requests found in client-side JavaScript.
2. Extract identifiers. List each object ID, tenant ID and role value that appears in paths, query strings and bodies.
3. Build the matrix. For each endpoint, note which account owns which object.
4. Replay. Send each request under each other account's session.
5. Compare. Check status, body and headers against the baseline.
6. Run controls. Repeat with nonexistent IDs, wrong record types and another account's token.
7. Prove. For any candidate, read the effect back through the owner's session.
8. Record. Save request, response and timestamp, and link them to the finding.

What does a worked differential test look like?#

The demonstration runs a read test, a write test with read-back, and the controls on a fictional app.

GET /api/notes/1001 HTTP/1.1
Host: harbor.example.com
Cookie: session=A-token

HTTP/1.1 200 OK
{"id":1001,"workspace":"ws-a","title":"Q4 plan","body":"Launch on the 14th"}

GET /api/notes/1001 HTTP/1.1
Host: harbor.example.com
Cookie: session=B-token

HTTP/1.1 200 OK
{"id":1001,"workspace":"ws-a","title":"Q4 plan","body":"Launch on the 14th"}

GET /api/notes/1001   (no cookie)            -> 401
GET /api/notes/999999 (B-token)              -> 404
GET /api/notes/2002   (B-token, B's own)     -> 200 (B's note)
GET /api/notes/1001   (C-token, third tenant)-> 200 (same body)

PUT /api/notes/1001 HTTP/1.1
Host: harbor.example.com
Cookie: session=B-token
Content-Type: application/json

{"title":"changed by B (test data)"}

HTTP/1.1 200 OK
{"ok":true}

GET /api/notes/1001 HTTP/1.1
Cookie: session=A-token

HTTP/1.1 200 OK
{"id":1001,"title":"changed by B (test data)", ...}

Which test cases should an authorization run cover?#

Each row lists what to compare for one kind of flaw and what counts as proof.

OWASP API5:2023 covers function-level flaws. WSTG-ATHZ-04 covers the web version of the object-level test.

What controls keep the agent honest?#

Controls stop the agent from calling a lenient server a vulnerable one. The controls in the demonstration are the ones we run: nonexistent identifiers, wrong record types, another account's token, and anonymous versus signed-in comparisons. The rule behind them comes from our evidence standard: a write is proven by reading the changed record back through another session.

Three more rules limit risk:

• Destructive proofs use only test-owned accounts and records, marked as test data.
• Tests of uploads, password guessing, email sending and paid third-party APIs are bounded, and the report states their cost.
• A person reviews the evidence for each finding (human-in-the-loop pentesting).

AI pentesting false positives covers the failure modes these controls address.

What does an agent still miss?#

An agent cannot test a rule it cannot see. If your app lets a manager approve only invoices under a limit, the traffic does not state the limit. Give the tester an access matrix: roles, objects and the expected result for each pair. The accounts must also hold the right data. Testing signed-in flows covers account setup.

How AI pentesting works covers the full flow from scope to report. The example assessment shows a validated finding next to a rejected one.