PRACTICAL FIELD GUIDE
Why an API key can see rows hidden from users
Machine API keys bypass end-user row policies and use their own table permissions. Testing with a key therefore does not prove that a browser user's owner policy works.
MCPBackend editorial team · · Examples are illustrative
Put it into practice
- Identify whether the request uses a machine key or an end-user token.
- Run the intended user request with a real app-user token.
- Review key scope independently and keep machine credentials in trusted server environments.
What this looks like
ILLUSTRATIVE EXAMPLE
An owner-only table returns all permitted rows to a machine integration. That is a different access path from the one a signed-in app user takes.
A boundary to keep clear
Do not ship an API key to the browser as a shortcut around an owner-policy failure.
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.