13 FOCUSED GUIDES
Permissions & row access
Separate public, authenticated, owner and machine access, then verify the boundary with real requests.
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.
Inspect the platform's access model →Why an API key can see rows hidden from users
Machine API keys bypass end-user row policies and use their own table permissions.
Read the guide →PRACTICAL FIELD GUIDEA table without a row policy denies end-user access
A missing policy is not the same as public access.
Read the guide →PRACTICAL FIELD GUIDEPublic reads and owner writes need a clear content model
Public-read and owner-write policies suit content that anyone may view but only its author should change.
Read the guide →PRACTICAL FIELD GUIDEAuthenticated access is broader than owner access
Authenticated mode allows any signed-in user of the project to perform the permitted table operation.
Read the guide →PRACTICAL FIELD GUIDEOwner IDs are assigned from the authenticated caller
On owner-mode creation, ownership comes from the calling user's identity rather than a client-selected owner field.
Read the guide →PRACTICAL FIELD GUIDEUse a custom owner column consistently
A custom owner column must match the table's policy and the data model.
Read the guide →PRACTICAL FIELD GUIDETest owner isolation with two real app users
A two-user test checks the boundary that a single happy-path session cannot.
Read the guide →PRACTICAL FIELD GUIDEPlan a public form without publishing submissions
A public submission form needs write access without exposing its collected records.
Read the guide →PRACTICAL FIELD GUIDEUse a create-only key for a server-side integration
A server job that only inserts records does not need broad read, update or delete privileges.
Read the guide →PRACTICAL FIELD GUIDEAn API key belongs to a different project
A machine key is bound to its project, so using it with another project's URL should fail even when the tables share names.
Read the guide →PRACTICAL FIELD GUIDEFrontend filtering is not an access-control boundary
A hidden row in the UI can remain accessible through a direct API request.
Read the guide →PRACTICAL FIELD GUIDEOwner policies are not organization membership rules
A single-owner policy does not express arbitrary team membership or organization roles.
Read the guide →PRACTICAL FIELD GUIDERevoking a key and verifying that access stops
Key revocation should be followed by a test through the actual data path.
Read the guide →