OriginDatabase users and access
Use the current console guide for live instance workflows and availability. Screenshots below illustrate the demo workspace with sample data. In the signed-in console, actions operate on the selected instance when your role and its capabilities allow them.
Manage database identities, credentials, network access and row policies for the selected instance.
The signed-in console reads access settings from your instance. Demo screenshots show local proposals only; they do not create credentials or enforce permissions.
1. Open Access Control
Select an instance, then choose Access Control in its sidebar. Roles & grants, Database identities, Policies, Column masking, Effective access, and Audit are grouped here. Organization membership is managed separately under Team.
2. Check database identities
Open Access Control → Database identities. On a connected instance, choose New identity, select API key or password authentication, and assign the intended roles. Permission and instance requirements are shown beside unavailable actions. Organization membership and database identities are separate.
A console member and a database user are separate identities. Adding someone to Team does not establish their right to query records.
Credentials for a connected instance
Use Connect on the instance to find the endpoint and supported client setup. Use the tenant identifier shown there, not the instance identifier. Store one-time secrets before confirming I have stored it. Never use the demo endpoint or sample credentials for an application.
Credential kinds in the service API
Credential scope matters: an organization token, an instance token and a database identity key grant different access. Confirm the issuing screen and the intended client.
| Credential | Scope | Lifecycle |
|---|---|---|
Shared database beareroc_live_… | One per database, shared by everyone and every deployed client. | Rotate replaces it. Every client still using the old value stops working. |
Personal access tokenoc_u_… | Yours alone, one or many per database. Carries read/write or read-only. | Rotate or revoke affects only that token — nobody else's breaks. |
Database-user API keyissued per database user | Belongs to a database user, so queries run as that user with its roles and grants. | “+ key” issues another; deleting the user removes them all. |
A personal token can be rotated or revoked independently. Rotating a shared database bearer invalidates its previous value for every client using it. A database-user key acts with that user's roles and grants; a newly issued secret is shown only once by the issuing service.
3. Prepare network access
From the instance overview, choose Network. Add an address rule using an IPv4 or IPv6 address or CIDR range. A single address is normalized to /32 or /128.
Review the existing IP Access List before saving. On the connected service, an empty list permits HTTPS API requests from every address; it does not open a database wire port. Private connectivity is a request workflow, and submitting a request does not establish a connection. Confirm the applied state returned by the console.
4. Prepare row policies
Open Access Control → Policies, choose New policy, and select a table and role. Enter the read condition, then choose Save policy. The engine validates the condition. Use Test with the intended database identity; administrators are not restricted by these read policies.
Engine policy semantics
The documented read-policy model attaches a USING predicate to a table and role. Its predicate surface includes =, !=, <, <=, >, >=, IN (...), IS [NOT] NULL, AND, OR, NOT, and CURRENT_USER.
For the documented database-user read path, a policy sees real values before column masking; rows failing the predicate are filtered out. A database bearer acting as the administrative superuser is not a test of restricted user access. With no policies on a table, the policy layer supplies no row filter. Verify identity propagation and enforcement separately for each query path before relying on a policy.
Review access changes
Access Control → Audit reads the selected instance’s authorization history in the signed-in console. Use the available verification and export controls to inspect the engine chain. The demo’s local draft history is a separate browser record.
Connected engine audit reference
The engine's authorization audit model is an append-only hash chain. Its documented actions include user.create, user.delete, user.rotate_key, role.create, role.delete, grant.put, grant.revoke, rls.put, and rls.delete. Each entry includes its target, change detail, and previous hash.
Chain verification must recompute the links and identify any first broken sequence. Engine audit exports use NDJSON. Organization events and browser-local draft history are separate records; the signed-in console and the demo show different records.
Before applying a policy
Connect an authenticated service and verify the deployed engine's capabilities. Local policy and role definitions establish no access boundary.
| Control | Boundary to verify |
|---|---|
| Network access | The actual endpoint rules and empty-allowlist policy, independently of database credentials. |
| Read-only token | Write requests are rejected by the service; a browser label alone cannot enforce this. |
| Database identity | Queries propagate the intended database user rather than an administrative bearer identity. |
| SELECT, policies and masking | Reads by that identity are checked for table access, row filtering, and masked columns on every supported query path. |
| Insert, update, delete, references | Verify the deployed engine’s write permissions for the identity and API your application uses. Test denied operations as that identity; an administrator’s successful request is not evidence of a restricted user’s access. |