Implementation worksheet · 2 min read
A two-account permission test for an AI-built app
Test tenant isolation with two accounts in different organizations and an explicit list of protected actions. Use Account A to create a record, then use Account B to request that record through the application's normal API. The server must apply the intended access policy even when the interface hides the record.
Run this only against an application you own or are authorized to test, using synthetic records. Include both read and write actions. A successful login proves identity; it does not prove that the account should access a particular invoice, project or file.
Put it into practice
1. Create a small fixture
Create Organization A and Organization B, one member in each, and one project with a file in each organization. Record which account owns each identifier. Keep the fixture separate from customer data.
2. Test direct reads
As Account B, request Account A's project through the same endpoint used by the application. Check both the response and any file URL returned. Decide in advance whether a forbidden resource produces 403 or a non-revealing 404.
3. Test mutations
Attempt to rename, delete and share Account A's project as Account B. Confirm the stored record did not change. Check bulk endpoints and exports as well as the single-record screen.
4. Change membership
Remove a member, switch organizations and repeat the requests. A cached project list or long-lived session must not preserve access beyond the product's documented revocation behavior.
5. Make the test repeatable
Turn each approved access rule into a regression scenario. Store synthetic fixture setup with the test so future schema or route changes can run the same checks without depending on manually prepared accounts.
Minimal permission matrix
Copy this structure into your review document and record your observed result for each row.
| Actor | Own organization | Other organization |
|---|---|---|
| Member reading a project | Allow if assigned | Deny |
| Member changing settings | Follow configured role | Deny |
| Removed member | Deny after revocation | Deny |
| Unauthenticated visitor | Only intentionally public resources | Only intentionally public resources |
| Administrator | Documented administrative scope | Never assume global access |
A failure worth checking
A download URL may continue working after access to the parent record is removed. Include file delivery, thumbnails and exported reports in the review. Choose an expiration and revocation design that matches the data's sensitivity.
Common questions
Is hiding a button sufficient?
No. The API and resource delivery layer must enforce the same policy when the request is made directly.
Does this replace a security review?
No. It is a focused authorization check. Authentication, secrets, input handling and infrastructure need their own review.
Basis and scope
This is a proposed implementation method using illustrative examples, not a measured benchmark or a customer case study. Prepared with AI assistance. Validate product-specific behavior against current documentation and your own test environment.