Database users and access
A database identity is a user that the database can recognize and give permissions to. Configure that access separately from organization membership. The redesigned console is a local preview; its drafts do not enforce live permissions.
Screenshots show the current local console with sample data. They do not show live credentials or confirm a production change.
- Select the databaseOpen its access controls.
- Create or select an identityUse the identity intended for this person or application.
- Assign its permissionsChoose the required roles and policies.
- Test effective accessConfirm allowed operations succeed and forbidden operations fail.
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 → API for the complete OC_URL and the credential instructions for that deployment. Keep its path unchanged. Database login provides separate PostgreSQL credentials. Save one-time secrets when shown; demo values cannot connect 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 | What to check |
|---|---|
| Personal token | The owner’s access and the grants selected for the token. |
| Organization token | The explicit grants and associated database identity. |
| Instance key | Whether this deployment still requires it for the selected API. |
| PostgreSQL password | The separate database login, its host and TLS settings. |
Revoke or rotate the credential through its issuing screen. Confirm the resulting status and test the affected connection; control-plane rejection and propagation to an engine are separate events.
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. |