Permissions that were designed, not added later
A prompt-driven product has to be stricter than a menu-driven one, not looser: if anything can be asked for, everything has to be checked. The client hides the commands you lack, and the server never trusts that copy.
Who may do what, down to the column and the record.
The security roles as a table, one of them opened as a matrix of depths per table; a record shared with exactly the rights ticked; and the field security profiles that decide who reads which columns.
The model in full
Who may do what
- Security roles with create, read, write, delete, assign and share
- Four depths per privilege: own, business unit, that unit and its children, the whole workspace
- Business units in a hierarchy, and teams that cut across them
- Field security profiles that hide or read-only a column for a role
- Sharing a single record with one person, without touching their role
- The billing owner is the only authority outside the roles, on purpose
What is written down
- An audit trail of who changed what, and when
- A security audit of role, sharing and configuration changes
- Every generation records how many records were described to the model
- Sign-in history and active sessions, revocable
- Run history for every automation
- Invoices and credit notes kept as issued documents
The account itself
- Two-step verification
- Sessions on the server, with a same-site cookie
- Password reset that reveals nothing about who has an account
- Rate limits on sign-in and sign-up
- Content security policy with no inline scripts anywhere
- Secrets a workspace hands us (an IdP client secret, a mail refresh token), encrypted at rest
What reaches the model is your decision, not ours
A prompt goes to a third party the moment a language model is involved, and a business app’s prompts carry customer names. So the rule is that nothing leaves that does not have to.
The deterministic parser runs first and answers most prompts without anything leaving the process. Where a model is used, it is told only about the records the sentence named, capped at ten, almost always that is none.
- Switch the model off entirely and keep the parser: the product still works
- Or keep the model and forbid it from ever being shown a record
- The default is the model on, and only the records you just named
- The count of records described is recorded on every generation
Data protection, handled in the product
A subject access request and an erasure request are things this product does, not things you email us about. The legal page lists the sub-processors in force for your workspace, derived from the deployment, plus a mailbox provider only if you connected one.
Losing a plan costs you generation, deliberately and narrowly. Everything already in the workspace stays readable and exportable. Locking somebody out of their own customer list over a card is not something we do.
- Export everything a person’s record touches, on request
- Erasure, with what it cannot remove explained rather than glossed over
- A recycle bin that holds deletions for thirty days before they are gone
- Backups you can take, download and restore yourself
- Terms are versioned: "they agreed" records which terms, and when
Read the legal page before you commit anything
It is inside the app and it names the sub-processors for this deployment, not a template. Start a trial and read it on day one.