Test user permissions in an AI app: two identities and direct resource requests

A worked example: where the task becomes difficult

A fictional project tracker has owners, collaborators and viewers. The interface hides the delete button from viewers, but the delete endpoint only checks that someone is signed in. A viewer can call it directly. Build a permission table before testing and use fake projects owned by two separate accounts. Test the resource identifiers and operations outside the ordinary navigation path.

Decisions to make before implementation

Define the actor, resource ownership and operation separately. Access can change after invitations are revoked, so session state alone may not be enough. Check list filtering, record detail, updates, exports and file URLs. Denial should avoid leaking the private record through error text. Keep tests reversible and restrict destructive cases to explicitly controlled resources.

A practical sequence for the work

Use the sequence below as a task boundary, not as a claim that the example has been executed. Work with approved inputs and the project’s actual architecture. If a required integration or permission is unavailable, keep that stage visibly incomplete rather than generating a plausible substitute result.

• Write the role/resource/operation matrix from approved product rules.
• Create fake resources under two controlled identities.
• Exercise direct requests for permitted and denied operations.
• Retest after membership changes and inspect private-file access separately.

A detailed brief you can adapt for your agent

Replace the illustrative context with your approved facts and controlled inputs. Keep the stated boundaries when adapting the brief. The expected deliverable matters more than a particular tool name: ask for an explanation grounded in the inspected material and evidence for the requested outcome.

Verify the supplied permission matrix using two controlled accounts and fake projects. Test direct reads, writes, exports and downloads, not only button visibility. Include membership revocation. Preserve production data and do not broaden permissions as a workaround. Report each allowed or denied result with the tested resource and revision.

Failure modes that an attractive preview can hide

Testing only the happy path as an administrator misses the core boundary. Also watch for bulk endpoints that omit checks used by single-record handlers. Do not test against another real customer’s account without authorization. Use controlled fixtures whose ownership is known and report unavailable test roles rather than pretending the matrix is complete.

Technical references: MDN: practical security implementation guides

Acceptance checks and the evidence to retain

Keep the matrix, controlled identities, observed outcomes and untested boundaries. Passing representative checks supports the access model but is not a complete security certification.

Specific answers

Common questions