Security and data handling
Your systems stay the only copy.
Most platforms in this category work by copying your email, files and records into their own index, then answering from that copy. We took a different route, and it changes what you are exposed to.
Read on demand, not copied
When you connect a mailbox, a drive, a calendar or a database, we do not import or index it. The agent fetches what it needs from that system at the moment it answers your question, uses it, and does not retain it. Your mailbox stays the authoritative copy. Disconnect the integration and there is no stored content to purge, because there was none.
There are exceptions, and we would rather list them than let you find them. A saved report holds the rows it was built from, because otherwise it is not a report. Conversations and their attachments persist so you can return to them. Agent memory keeps the facts your team taught it. Each one exists because a feature needs it, and each one is deletable.
How access is controlled
The agent’s reach is capped by the person asking. It cannot see anything they could not see directly.
Two layers, both must pass
A member’s role governs what kinds of action they may take. Their access grants govern which specific sources they may touch. Someone with no grant for a mailbox cannot reach it through the agent whatever their role—so the agent can never become a way around your existing permissions.
Row and column rules
Administrators can constrain which rows and columns a member’s queries return. Enforced on the server, including on agent paths, so it holds whether the question arrives through the web app, the API or a messaging client.
Separate read and write credentials
Database connections take read and write credentials independently, and the writable table list must be a subset of the readable one. The agent cannot write somewhere you have not explicitly opened.
Approval before consequence
No database write, no outbound message and no calendar change happens without a person seeing a preview and approving it. Scheduled runs that would send something pause and ask rather than sending on their own.
Credentials encrypted at rest
OAuth tokens and API keys are encrypted before they are written. Once saved, only the last four characters of a key are ever shown again.
Append-only audit log
Access changes, integration changes, database writes, messages sent and administrative actions are recorded with actor, timestamp and context—including which records were used.
Where your data goes
Workmise is operated from New Zealand. Answering a question means sending the relevant content to a language model, and those providers are overseas—principally the United States, the European Union and Australia. So content retrieved from your systems is processed outside New Zealand, and we would rather say that plainly than bury it.
What is sent is your question, the conversation so far, the definitions of your connected sources, relevant agent memory, and whatever the agent retrieved to answer you. It goes under agreements that prohibit the provider training on it. Your data is not used to train models—ours or theirs.
If your organisation supplies its own provider API key, that traffic runs under your agreement with that provider instead of ours, and their terms govern it.
Where a data boundary is a hard requirement, the platform can be deployed in your own environment, with the model, storage and integration architecture agreed against that boundary rather than described with the word "on-premises" and left there.
- What you receive
- The full list of providers that may receive information, and what each one gets, is in the Privacy Policy.
The parts most vendors leave out
Limits we would rather state than let you assume
Isolation between organisations is enforced in the application layer—through scoped queries and authorisation checks—not by database-level row security. It is thorough and it is tested, but it is not a database-enforced boundary, and if that distinction matters to your auditor you should know it now rather than later.
Redaction of personal information in stored traces is optional and off by default. The platform can mask common identifiers such as phone numbers, but it is a setting, not a guarantee. Do not assume stored traces are free of personal information unless you have turned it on.
Rollback of a database write is best-effort and time-limited. For a short window the agent can propose a compensating statement, but that is a convenience, not a transaction. Keep your own backups.
A sent message cannot be recalled. The approval step before it goes is the only undo there is.
AI output can be wrong, including when it is confident and well-sourced. Citations, traces and confidence signals are aids to your judgement, not warranties of correctness.
Questions we get asked before a security review
Can the agent see something a staff member should not?
No. Access is capped by the role and grants of the person asking, so the agent cannot be used to reach around a permission. If someone cannot open a mailbox directly, they cannot get its contents through the agent.
Does our data train an AI model?
No. Not ours and not the providers’. Content goes to a model provider to generate a response to your request and for no other purpose, under agreements that prohibit training on it.
Can we run it inside our own environment?
Yes. The exact design depends on your infrastructure, model choice, integrations and where the data boundary needs to sit. We agree that architecture with you rather than treating "on-premises" as a label.
What happens when someone leaves?
Their access is revoked immediately and their private conversations become inaccessible to them. Context they contributed on the organisation’s behalf—source descriptions, rules, corrections—stays with the organisation, tagged for audit.
Can we see what the agent actually did?
Yes. Every significant action is in an append-only audit log with the actor, the timestamp, the records used and the action taken. Conversations also keep an execution trace showing which sources were queried and what each returned.
What if we publish a view externally?
A published view link contains an access key, and anyone holding it can see that view’s data without signing in. It is scoped to that view’s stored data and it is read-only, but treat the link itself as the credential and revoke it when it is done.
Send us the security questionnaire.
If you have a standard vendor assessment, send it before we meet. We would rather answer it in writing and have the awkward questions out of the way early.