Most platforms can tell you who edited a record. Far fewer can tell you who read it, what the AI retrieved, or whether that person was genuinely permitted to at the time. BuildWithHQ records all of it, and can re-derive the decision afterwards to check that the log is telling the truth.
The set of records a user is allowed to see is computed in a single place, and every feature that reads tenant data draws from that set. It is a filter, not a gate: a record you have no role on is absent from the result rather than refused. This is why the tenth module doesn't leak — there is no second code path to forget, and no rejection branch to get wrong.
Permissions attach to individual records, not just to screens. A user can hold several roles at once, and one record can be shared with several roles without duplicating it. Called DataRoles in the product.
A second boundary alongside roles, for branches, regions, facilities, and territories. The role must allow it and the location must match. Called location scope in the product.
Reading a record, exporting it, and letting the AI read it are three different permissions, not one.
Encrypted fields drop out of search and AI retrieval automatically, and every reveal is authorized and logged.
Pages load with what the person can see. An unentitled record is absent from the result set rather than refused, so nothing confirms that it exists.
Revealing an encrypted field is an explicit operation, separate from rendering a page. It is authorized on its own, it can be refused, and refusals are recorded with the same weight as successful reveals.
Every AI query records the envelope it drew from, so 'what did the assistant see' has an answer. The envelope is resolved before retrieval, so the model is never handed anything to filter out.
Who exported what, and when. Export is a distinct permission precisely so that it can be governed and reviewed separately from reading.
Not just the outcome but the inputs, so the decision can be reconstructed later rather than merely trusted.
This is the capability that turns a log into evidence.
Roles change. People move between locations. Records are reassigned. That means a log entry from March cannot be judged against today's permission table — the honest question is whether the access was permitted at the time.
A verdict, not a reassurance. The result is one of: verified, envelope mismatch, unauthorized retrieval, no longer authorized, or chain broken. Each is a specific finding you can act on, and each replay run is itself recorded.
An audit trail that only records successes is not an audit trail. Refused reveals and failed verifications are the entries that matter most in a review.
Record access resolves as a filter. A user never requests a record they have no role on and gets turned away, because the list, search, or panel they were looking at was built from their entitled set and never offered it. There is no rejection to log because there was no attempt to make.
That is deliberately stronger than refusing. An error response confirms a record exists and usually reveals something about it. Filtering at the source makes an unentitled record and a non-existent record indistinguishable from outside. Refusal is reserved for the operations that genuinely warrant it — revealing an encrypted field, exporting, and privileged actions — where the request is explicit and the refusal is meaningful.
Both, and reads are the part most platforms skip. Encrypted-field reveals, AI retrievals, and exports are recorded as discrete events, including reveals that were refused. Ordinary reads of records a user is already entitled to are routine rather than exceptional.
The platform can re-derive a past access decision using the roles, locations, and record state as they existed at that moment, then compare the result against what was logged. The outcome is an explicit verdict rather than an assurance.
The log rows are chained: each entry folds in the hash of the entry before it. Removing or altering a row breaks the chain, and a broken chain is itself a recorded verdict.
Not yet. The security architecture, encryption approach, audit model, and data lifecycle are all documented publicly so you can evaluate them directly rather than relying on a badge.
Create an account, explore the full builder console, and launch your first application on a custom domain. Nothing is charged while your application is still in development.
No credit card required. The console preview, the documentation, and the architecture reference are all readable before you sign up.
Get started free Read the docsFor records that support Personal, explicitly choose Personal or an eligible DataRole. Personal records belong to their owner and have no location. Chat Rooms, Discussion Boards, Knowledge, Company News and Files are shared-only: choose one DataRole. For shared records, choose an authorized location or All when permitted; a blank location is not All. Child records inherit their parent’s scope. A shared record cannot be converted to Personal.
Read the guideUse the current generated OpenAPI reference and versioned Developer Kit for headless apps, typed clients, webhooks and supported MCP tools. Keep app credentials on a trusted server. Delegated user identity, scopes and action permissions still apply. Sensitive MCP tools require app-level approval; installing an MCP client does not grant write access.
Read the guideChat rooms and messages require current room membership as well as DataRole and location access, including when opened through Graph, Activity or Favorites. Find them in native Chat Rooms search; general and AI search exclude chat content. Administrators add eligible members, and saves check current authority again. Room removal preserves history through soft deletion; an authorized restore does not revive independently removed messages.
Read the guide