PRACTICAL FIELD GUIDE
Test owner isolation with two real app users
A two-user test checks the boundary that a single happy-path session cannot. Use separate accounts and known rows so every allowed and denied operation has an expected result.
MCPBackend editorial team · · Examples are illustrative
Put it into practice
- Create one disposable row as user A and another as user B.
- List, fetch, update and delete using each user's token against both records.
- Verify anonymous access separately and retain the results with the release checklist.
What this looks like
ILLUSTRATIVE EXAMPLE
User A can edit their task while user B's direct request for that task returns a protected result. Both list and single-record routes need checking.
A boundary to keep clear
Do not use a machine key in the isolation test. Its access model bypasses the row policy you are trying to verify.
MCPBackend context
MCPBackend row policies apply to anonymous callers and end-user tokens. Machine API keys bypass those row policies and are instead constrained by their own table permissions. Owner mode is based on the calling user's identity; it is not an organization-membership or arbitrary custom-policy engine.
Take the next step
Inspect the current project contract, try the change with disposable data, and verify the result through the same credentials your app will use. Record the expected response and one denied-access case before release.
Sources and further reading
These references explain the underlying protocols and design principles. For supported MCPBackend operations and exact request shapes, inspect your project’s generated API contract.