PRACTICAL FIELD GUIDE
A table without a row policy denies end-user access
A missing policy is not the same as public access. End-user and anonymous requests need an explicit policy, even if an administrative key can use the table.
MCPBackend editorial team · · Examples are illustrative
Put it into practice
- Confirm that the table has a configured read and write policy.
- Choose modes based on the intended audience and operations.
- Test anonymous, signed-in owner and another user before connecting the screen to real data.
What this looks like
ILLUSTRATIVE EXAMPLE
The dashboard shows records while the app receives no_policy. Administrative visibility does not mean the end-user boundary has been configured.
A boundary to keep clear
Do not default every new table to public to remove setup errors. Choose the intended access model.
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.