Access control
Each role starts from the screens its job uses, and Bondi derives the data access those screens need, including related records. On Pro, roles reach down to individual rows and fields. Access is enforced in the data layer behind your screens, portals and API, not by hiding buttons.
30-day trial with Pro capabilities · no card required
One system, four identities
A project lead needs the whole delivery picture. Finance needs the money, not the notes. A supplier sees only their own orders, and an integration writes only what its job requires.
| Record or action | Project lead | Finance | Supplier portal | Service Account |
|---|---|---|---|---|
| Projects and deliverables | Allowed | Read only | Not allowed | Not allowed |
| Internal delivery notes | Allowed | Not allowed | Not allowed | Not allowed |
| Purchase orders | Allowed | Allowed | Own orders | Create |
| Order cost and marginField rule | Allowed | Allowed | Not allowed | Not allowed |
| Confirm a delivery date | Not allowed | Not allowed | Own orders | Not allowed |
| Invoice status | Read only | Allowed | Own invoices | Update |
Diagram of a sample access model, built from Pro custom roles, row filters, field rules, a portal and a Service Account. Role names and records are sample data.
Want to see this on your own process? Our team will walk through it with you.
Map your access model with usWhat it does
Choose the screens and actions a role needs. Bondi derives the data access those screens require, including related records, so access follows the work instead of a spreadsheet of grants.
Filter the rows a role can see, and decide which fields its screens and record queries can read, create or update, including access that reaches through related records.
A row condition matched to the signed-in portal user limits a supplier to their own orders and invoices, and a field rule keeps cost and margin off their screens.
Each integration gets its own API key, a Service Account identity scoped to the roles you assign. The token is shown once and stored as a SHA-256 hash. Rotating a key issues a new token and retires the old one, and the key keeps its identity and roles.
When someone asks AI in the apps about live data, each query runs as that person, checked against their permissions and row-filtered before it executes. Workflow agents have no database tool and work only on the records a workflow's steps hand them. On Pro, an approved MCP client reads, and never writes, under one named person's permissions, in a controlled beta.
People, workflows and API keys each write under their own identity, and a manual launch set to run as the caller writes as the person who started it, so the audit row the Data API writes with a direct change, in the same transaction, names that identity. Who decided inside a workflow stays on the completed task. Updates also keep each changed field's value before and after.
Under the hood
The mechanisms behind the page, for the architects and security reviewers evaluating it.
Read the technical documentationIn Bondi's data layer, not PostgreSQL row-level security. GraphQL and REST record reads and writes, from screens, portals and role-scoped API keys, apply the caller's table, row and field grants. In-app AI queries run as the signed-in person, and MCP reads apply the connected person's grants.
Each workflow runs under its own automation identity, with workspace-wide data access, so the steps you configure decide what it reads and writes. A manual launch can instead be set to run as the person who started it, under that person's grants.
Grants attach to your team's roles, to shared links to a screen and to portal sign-ins. Each covers readable, creatable and updatable columns, deletion and row filters, including access through related records via EXISTS conditions, plus role inheritance. The current user is resolved from the authenticated identity.
Each API key is its own Service Account identity, with a SHA-256-hashed bondi_pk_ token, role or administrator scope, rotation and revocation. People sign in with email and password or a verified Google account; changing your password while signed in signs out every other session. Multi-factor sign-in has no self-service enrollment yet.
Designed boundaries
CSV export applies each role's table and row rules, but not its field rules yet.
Single sign-on (SAML/OIDC) and SCIM provisioning are not offered yet.
Discuss identity requirementsOrganization owners and administrators have full access to data in every workspace, and an API key issued with administrator scope has full access within its environment. Your administrators assign roles, revoke access and review what each role's screens grant.
Shared responsibilitiesAvailability
Questions buyers ask
Not yet; both are next on the identity roadmap, and we can talk you through timing. Today people sign in with email and password or a verified Google account. Self-service multi-factor enrollment is not available yet either.
No. Bondi's data layer builds each role's row filters and related-record conditions into the queries it runs for screens, portals, the API and MCP, so access rules live with the roles you configure rather than in database policies.
Standard enforces the access each role's screens require. Pro adds custom roles, row and field rules, portals and Service Accounts.
No. Portal users never take a paid seat, and Pro sets no portal-count or external-user seat limit. Resource quotas, rate limits and each portal's permissions still apply.
Only if a workflow hands it that data. A workflow's AI agent has no database tool; it works on the records earlier steps pass it, and those steps run under the workflow's own automation identity, or as the person who started it when a manual launch is set to run as the caller. AI in the apps queries only what the signed-in person can read.
Next step
Bring your roles, your external users and your auditors' questions. We'll map them to screens, rows and fields with you.
