Start with read-only requests and agreed expectations. The generated matrix is a test proposal; a pass requires an actual response from the specified build and checks of what that response contains.
Define a small access contract
This original fictional staging API has GET /test-documents/{id}. Its supplied rules say authenticated users may read only their own documents. A permitted request returns 200 with the requested document. A non-owner receives 404 with a generic error containing no document title or body. An unauthenticated request receives 401 and no document content.
These status codes are fixture requirements, not a universal rule for APIs. If your maintained contract uses 403 or another defined policy for denied access, preserve that policy in your test.
| Test fixture | Supplied ownership |
|---|---|
| User A | Owns document D-A |
| User B | Owns document D-B |
| No identity | Owns neither |
Use only these permitted staging identities and records. Do not paste live credentials into ChatGPT. Describe token references as placeholders and let your existing test environment supply its secrets.
Compare access to the same operation
| Case | Identity and request | Required response in this fixture |
|---|---|---|
| A1 | User A reads D-A | 200; ID is D-A and content matches the allowed fixture |
| A2 | User B reads D-A | 404; generic error; no D-A title or body |
| A3 | User A reads D-B | 404; generic error; no D-B title or body |
| A4 | No identity reads D-A | 401; no document content |
A2 changes the identity while holding the object constant. A3 checks the reverse ownership direction. A4 asks a different question: whether authentication is required at all. Keep those purposes attached to the cases.
OWASP's REST assessment guidance, checked October 24, 2026, distinguishes object-level authorization from whether a role may call an operation. This matrix concerns read access to particular records. It does not establish that every administrator operation or write endpoint is restricted correctly.
Require a payload assertion as well as a status
A2 is not satisfied merely because the server returns 404. A response such as an error object containing the protected title still violates the fixture's no-content rule. Inspect the actual body and any relevant headers against the agreed disclosure policy, using harmless marker text in the test document so a leak is recognizable.
For A1, a 200 response carrying D-B would also fail. Assert the record ID and approved fixture content, not only success. Keep expected and observed values separate in the test result so a copied expectation cannot appear to be an executed check.
Copy an access-matrix prompt
Draft read-only API authorization tests for our approved staging scope.
API version/build and endpoint contract: [PASTE]
Allowed staging environment and read-only operations: [ENTER]
Test identities/roles and owned fixture records: [PASTE NO SECRETS]
Ownership and cross-organization rules: [PASTE]
Expected success/denial status and disclosure policy: [PASTE]
Existing test framework and fixture setup/reset: [ENTER]
Create the smallest matrix distinguishing own-object access,
another user's object and no authentication. Include other roles
or organizations only when supplied by the contract and allowed scope.
For each case give identity, fixture, request, expected status,
allowed response fields and forbidden protected content.
Keep actual result blank and execution status Not run.
Flag missing denial policies instead of choosing 403/404 by convention.
Do not send requests, enumerate IDs, use production records or tokens,
change permissions, or mark a case passed.
OpenAI's prompting documentation supports supplying the sources and action boundaries. Here a precise authorization rule is more useful than a request for “all security tests.”
Run the reviewed cases in the maintained test suite
Confirm that the staging fixtures and ownership match the matrix. Execute only the approved read-only cases, recording build, identity reference, fixture, sanitized response and assertion outcomes. A shared cache or stale token can make the actual identity different from the label in your test; establish which identity each request used.
Keep the API's documented response schema alongside these assertions. The schema-to-documentation guide covers field presence and nullability; those checks supplement the access rules instead of replacing them. Retain any unrun role or tenant scenario as untested scope, and add a regression case when a real authorization defect is fixed.