Security
Access control that is not a front-end check.
What we have implemented, described plainly.
- Workspace isolation in the database
- Every business record belongs to a workspace and is protected by Postgres row-level security. Access control is enforced by the database, not by hiding things in the interface.
- Role-based access
- Owners, admins and members use the same system with different levels of control. Billing and role changes are owner-only; imports, deletion and structure changes need an admin or owner. These rules are enforced in the database.
- Authentication
- Sign-in, sessions and password reset use Supabase Auth. Signed-out visitors cannot reach the application.
- Server-side AI calls
- AI requests are made from the server only. The AI provider key is never sent to the browser, and each request is built only from the signed-in user's own workspace.
- Private file storage
- Uploaded imports and call recordings are stored in private buckets, scoped by workspace path, and are not publicly accessible.
- Your data runs your workspace
- Uploaded files, calls and conversations are used to run your own workspace and nothing else. They are not used to train shared models.
- Audit trail
- Key changes to actions, briefings, imports, conversations and team membership are recorded by the database in an activity log.
- Validated input
- Uploads are checked for type and size, and every imported row is validated before it is stored.
Good to know
To generate briefings, answers and conversation analysis, relevant records from your workspace are sent to Google's Gemini API for processing. They are sent only when you run an AI action.
We have not claimed any third-party certification or audit, and no system can promise zero risk or perfect accuracy. AI output can be wrong: it is built to show the figures behind each statement so your team can check it before acting.
To report a security concern, use the address on the contact page.