PRACTICAL FIELD GUIDE
Authenticated access is broader than owner access
Authenticated mode allows any signed-in user of the project to perform the permitted table operation. It does not automatically isolate records by their creator.
MCPBackend editorial team · · Examples are illustrative
Put it into practice
- Write down whether the table is shared across all app users or private to one user.
- Select authenticated or owner mode intentionally for each operation.
- Test with two separate users and verify that the non-owner behavior matches the product requirement.
What this looks like
ILLUSTRATIVE EXAMPLE
A private notes app uses authenticated reads and inadvertently lets every signed-in user read every note.
A boundary to keep clear
A login screen is not row isolation. Authentication identifies the user; the policy determines what that identity can access.
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.