tracemint.Sample report · Synthetic example

AI pentesting / Evidence & follow-through

A boundary tested.
A finding explained.

A scoped review of invoice access across two workspaces. One identity, two known objects, and the evidence needed to understand the difference.

Example engagement
ENG-014
Assessment surface
Web application + API
Finding reference
F-01
01 / Finding

Cross-workspace invoice access

Illustrative severityHighF-01 · Object authorization

A workspace A member receives invoice metadata belonging to workspace B.

The same authenticated member requests inv_A and inv_B. Both responses return 200 OK; the second body identifies workspace B. In this fixture, that crosses the declared ownership boundary.

Supporting exchanges: E-01 and E-02 below.

Why it matters

Invoice identifiers and totals may reveal another workspace’s business information. “High” is an illustrative priority for this disclosure scenario; no CVSS score or application-wide severity assessment is claimed.

02 / Scope

The limits of this engagement.

Target host
invoice.example.invalid
Selected identity
Workspace member · Workspace A
Credential reference
sample-member · value masked
Operating ceiling
120 requests / 15 minutes / 2 concurrent

These are example operating limits, not recorded consumption or elapsed runtime. This document makes no network requests.

Allowed in the example

  • GET /api/invoices
  • GET /api/invoices/*
  • POST /api/session · sign-in only

Explicitly excluded

  • /api/payments/*
  • Third-party origins
Discovery inventory · stated sources in the authored scenario
MethodRouteSourceRole
POST/api/sessionAPI definitionSign-in
GET/api/invoicesBrowser observationCollection
GET/api/invoices/{id}API definitionObject access

Inventory entries show discovery context. Their presence alone does not establish a vulnerability or grant permission to expand the scope.

03 / Method & assumptions

Hold the identity constant.

The hypothesis is precise: a workspace A member may read an invoice owned by workspace B by changing the requested object identifier.

  1. 01

    Define the target

    Set one target, admitted routes, exclusions and a finite request budget.

  2. 02

    Map the application

    Record three routes and their stated discovery sources.

  3. 03

    Establish identity

    Fix the actor to workspace A; establish ownership of both fixture objects.

  4. 04

    Test a hypothesis

    Request the owned invoice, then change only the invoice identifier.

  5. 05

    Inspect the evidence

    Compare the response body with the known owner, alongside the status code.

  6. 06

    Report & reassess

    Describe the fix and repeat the same two requests in an authored after-state.

Assumptions that make the comparison meaningful

The fixture defines inv_A as owned by workspace A and inv_Bas owned by workspace B. The member has no cross-workspace grant. Both identifiers are supplied by the fixture owner; no enumeration is implied. The same workspace A session is used for every exchange, including the retest.

04 / Request & response evidence

The body reveals the boundary.

These are the exact authored exchanges used in the walkthrough. The masked cookie stands for the same workspace A member session in both requests. They are illustrative HTTP text, not captured traffic or independently reproduced results.

E-01Baseline · own object200 OK

Request · Workspace A member

GET /api/invoices/inv_A HTTP/1.1
Host: invoice.example.invalid
Cookie: [REDACTED]
Accept: application/json

Response · Authored fixture

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": "inv_A",
  "workspace": "A",
  "total": 240
}
E-02Comparison · foreign object200 OK

Request · Workspace A member

GET /api/invoices/inv_B HTTP/1.1
Host: invoice.example.invalid
Cookie: [REDACTED]
Accept: application/json

Response · Authored fixture

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": "inv_B",
  "workspace": "B",
  "total": 760
}
Interpretation

E-01 establishes the legitimate path. E-02 changes only the invoice identifier and returns "workspace": "B" with that invoice’s metadata. The known ownership, fixed actor and returned body support the finding within this example. A successful status code by itself would not establish the issue.

05 / Remediation & bounded retest

Restore the ownership check.

Cause in this example

The object lookup in this example does not enforce workspace ownership.

Recommended change

Enforce object ownership on the server before returning invoice data. Derive the workspace from the authenticated session and constrain the lookup to that workspace.

The example after-state returns the owned invoice normally and withholds the foreign object. Both paths matter: the fix should preserve legitimate access as it restores the boundary.

Before / after comparison · Same workspace A actor throughout
Object requestedBeforeAuthored after-state
/api/invoices/inv_AE-01 · 200
Invoice metadata returned		R-01 · 200
Owned invoice remains accessible
/api/invoices/inv_BE-02 · 200
Invoice metadata returned		R-02 · 404
Empty body · no invoice data
R-01Own object · Access preserved200 OK

Request · Same workspace A member

GET /api/invoices/inv_A HTTP/1.1
Host: invoice.example.invalid
Cookie: [REDACTED]
Accept: application/json

Response · Authored after-state

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": "inv_A",
  "workspace": "A",
  "total": 240
}
R-02Foreign object · Access withheld404 Not Found

Request · Same workspace A member

GET /api/invoices/inv_B HTTP/1.1
Host: invoice.example.invalid
Cookie: [REDACTED]
Accept: application/json

Response · Authored after-state

HTTP/1.1 404 Not Found
Content-Length: 0

Response body: empty (0 bytes).

Example retest outcome · Authored, not a closure record

The illustrated after-state satisfies these two checks. It is not evidence that a deployed fix passed, that a model performed a retest, or that the current product has closed this finding. A real closure decision requires a separately authorized retest against the actual changed target and its recorded evidence.

06 / Limits & handoff

Keep the conclusion within the evidence.

This example covers one role, two fixture-owned objects and one endpoint. It does not establish application-wide coverage.

  • The example does not assess other roles, write operations, payment routes, enumeration, session weaknesses or other application paths.
  • No customer system, external target or live model was tested to produce this document. The inventory and all four exchanges are authored fixture content.
  • The HTTP excerpts omit unrelated transport details. The credential placeholder is intentionally masked, and the invoice values are synthetic.
  • Source implementation, a recorded observation, an independently confirmed result and an accepted deployment are separate evidence boundaries.

For a real handoff, carry the target and revision, authorization, selected identity, evidence references, responsible owner and acceptance criteria into the remediation record. Repeat the controlled comparison after the change and record what remains untested.