Security and data governance
Where your donor data goes. Which is: nowhere you did not send it.
This page is written to be forwarded. If you are the person who has to answer for a membership file, an audit or a records request, everything you need to assess us is here — including the parts where the honest answer is “built, but not certified”.
The question everyone asks first
Does our data get sent to an AI company?
Not unless somebody with authority in your organisation decides it should, and that decision is recorded. A new organisation cannot send data to a third-party model even by accident, because the settings that would allow it all start switched off.
| Setting | Default for a new organisation |
|---|---|
| AI features | Off |
| What a model may see | Column names only |
| Processing outside your organisation | Not permitted |
| Dataset values sent to a model | Not permitted |
| Permitted providers | None until named |
| Monthly AI spend allowance | Zero |
Five modes, from nothing to everything
An administrator chooses one. Alongside it they pin which providers and which models are permitted, a maximum monthly spend, a maximum request size, and whether processing may happen outside an approved region.
| Mode | What the model can see |
|---|---|
| Disabled | Nothing. AI features are unavailable. |
| Metadata onlydefault | Column names, types and shapes. Never a value from a row. |
| Sampled data | A bounded sample of values from authorised columns. |
| Full authorised data | Values from columns your organisation has authorised. |
| Local model only | Anything authorised — but only a model running inside your own deployment. |
Below the mode
Governance goes down to the individual column.
Even inside a permitted mode, each column carries its own policy. A donor name can be denied while the gift amount is available as an aggregate — so an analysis of giving patterns runs without any model ever seeing who gave.
Metadata
The model may know the column exists and what type it is.
Aggregates only
It may see totals and averages, never an individual value.
Masked sample
It may see a sample, with values obscured.
Denied
The column is removed before anything leaves your workspace.
Denied columns are removed inside our own control plane, before the request is assembled. They are not filtered out of a response afterwards — they never form part of one.
Why the boundary holds
Four structural facts, not settings.
Settings can be misconfigured. These are properties of how the system is put together, and they apply whatever your policy says.
One process talks to model providers, and it stores nothing
Provider credentials load into a single dedicated service that owns no database and keeps no state. A failure there cannot expose your workspace, because your workspace is not there.
A model can propose an analysis. It cannot run anything
The model returns a plan as structured data. Our servers validate it against a fixed list of permitted analyses, insert the dataset identifiers themselves, and re-check your permissions before anything executes. There is no path by which model output becomes an executed query — no SQL, no code, no shell.
Your data is labelled untrusted before the model reads it
Dataset content is wrapped as untrusted evidence and scanned for injection attempts, and the system instructions take precedence over anything inside it. A spreadsheet containing “ignore your instructions” is treated as a spreadsheet.
Permission is re-checked at execution, not just at request
A background job revalidates who you are and what you may reach at the moment it runs, rather than trusting the request that queued it.
What is in the product today
Controls you can turn on this afternoon.
Identity
- SAML and OIDC single sign-on
- SCIM user and group provisioning
- Multi-factor authentication (TOTP) with recovery codes
- WebAuthn security keys and passkeys
- Step-up authentication on sensitive actions
- Session management, revocation and login-risk scoring
Authorisation
- Organisation and workspace roles
- Per-dashboard view, edit and owner grants
- Restricted regions within a single dashboard
- Column-level governance policy
- Scoped API credentials and service accounts
- Periodic access review
Data lifecycle
- Encryption of stored secrets and credentials
- Customer-managed encryption keys
- Scheduled key rotation
- Retention policy with automated execution
- Legal hold that overrides deletion
- Personal-data discovery and subject requests
- Data residency controls per organisation
Accountability
- Organisation audit log
- A separate AI audit trail: every plan, authorisation, denial and answer
- Privileged operator actions require a written reason
- Compliance evidence export
- Distributed tracing across every service
The part other vendors leave vague
Built is not the same as certified. Here is which is which.
Built and in the product
Everything listed on this page. It exists, it is running, and we will demonstrate any of it on a call rather than asking you to take it on trust.
Not yet certified
We do not hold SOC 2, ISO 27001 or a HIPAA attestation. We are not going to imply otherwise in a footnote. If a certification is a hard procurement requirement for you, tell us — it affects what we prioritise, and we would rather know than lose the deal quietly.
What we can give you today: a security questionnaire answered in full, a walkthrough of the audit trail with your own test data in it, the configuration your deployment would use, and a named person who answers the phone. For a station deciding whether to put a membership file into a new system, that is usually the more useful set of evidence.
Send us your security questionnaire.
We will complete it properly, mark anything that is a roadmap item as a roadmap item, and get on a call with whoever needs to sign off.