Security

This page describes how sanda protects a workspace, in the same terms as sanda's terms of service and privacy policy. Where the two documents say something, they are the authority and this page follows them.

Keeping workspaces apart

Each workspace gets its own warehouse database and its own credentials, rather than a shared table with a tenant column beside every row. Every query sanda runs on your behalf is checked against the workspace it came from before it is allowed to run. Before sanda serves any workspace data, it checks that this separation is in force. If it cannot prove that, it refuses to serve the data at all, rather than risk answering with someone else's.

Your warehouse is a standard PostgreSQL database, so what is inside it is yours to read, query and take with you. See Close or delete a workspace for how you get a full copy.

Where your data is held

Your warehouse, the data you sync into it, and sanda's own records about your workspace are held in Sydney, Australia.

Some work happens outside Australia, and sanda says so plainly:

• AI features send the part of your data a question needs to an AI model. Those models run outside Australia, mostly in the United States. Every model is called on a zero-data-retention basis: what is sent is used to answer the request and then discarded, and it is not used to train anything.
• sanda search sends the text of the columns you choose, and the searches you run, to an embedding model in the United States. It is off until a workspace owner switches it on.
• Running the service. Requests to the sanda website and console may be handled at a network location outside Australia.

Privacy and your data sets out exactly what is sent and when.

Encryption and stored secrets

• Data is encrypted in transit and at rest.
• Sign-in links and session tokens are stored only in scrambled form. So are your two-step recovery codes, which sanda cannot show again.
• The credentials you give sanda to connect your systems are held only by sanda's sync engine, never in sanda's own database. They are never shown back to anyone, including sanda staff.

Signing in

Sign-in is by a one-time email link, or Google or Apple where offered, with an optional second step. A link works once and expires in 30 minutes. Sessions end after 14 days unused or 30 days from sign-in, and you can see and end them yourself. An owner can require two-step verification of everyone. Each of these has its own page:

• Sign in
• Two-step verification

Roles

Every person has one role: owner, admin, read-only or reader. The role decides what they can open and change. A read-only person changes nothing whatever else is switched on. A reader has no console at all. The matrix is on Members and roles.

Agent access controls

An agent is anything that reaches your workspace from outside: an AI assistant connected over MCP, a script with a token, or Excel reading the feed. You decide what each one can do, and you can take it away at any time. See Agent tokens and Permissions for the detail.

• Questions only by default. A new integration token can ask questions of your semantic fluid and nothing more. Every further ability is a separate switch that starts off: running its own SQL, committing SQL, writing the fluid, seeing connections, starting a sync, loading rows, defining views, adding rows to intake tables, managing search and emailing reports.
• Only owners and admins can grant the sensitive ones. Those abilities also stop working if the person who granted them stops being an owner or admin.
• Set an expiry. When you create a token you can make it expire.
• Seen once. A new token is shown a single time. sanda stores only a hash of it and cannot show it again.
• Revoke to stop. Owners and admins see every token and connected app in Settings · Integrations, with when each was made and last used. Revoke one and its next call fails. Any member can disconnect an app they connected themselves.
• Leaving ends it. A token or connected app stops working when the person who made it leaves the workspace.
• Ask before an agent acts. On Intelligence · Agents, Ask before an agent acts makes risky actions wait for an owner or admin: committing SQL, dropping a derived view or removing a search service. The owners and admins are emailed, and an action nobody decides within 24 hours expires without running. It is off until you switch it on. See Actions and approvals.
• Intake tables are opt-in. An agent can add rows only to tables an owner or admin has opened for that purpose, listed under Intake tables in Settings.
• Report emails are restricted. Report delivery in Settings · Security limits the domains scheduled reports can be emailed to. An agent's emailed report to an address outside your members' domains waits for an owner's approval when approvals are on.
• A closed workspace goes read-only for agents too. Anything an agent holds narrows to questions and reading.
• Plan gates apply everywhere. sanda search is refused on a workspace whose edition does not include it, over MCP and in cherry as well as in the console. See Editions.

cherry, sanda's own agent, has its own switches under Settings · cherry · permissions: what it may change, and whether it asks first.

What sanda staff can see

The privacy policy says what sanda staff can and cannot reach:

• Only the people who operate sanda's production systems can reach them, they sign in separately, and what they do is logged.
• sanda's admin tools sit behind a separate sign-in. They cannot read your chat history or query your warehouse.
• There is no feature that lets sanda staff sign in as you.
• Connector credentials are never shown to anyone, staff included.

What sanda does hold, so it can run and bill the service: sign-in events, sync outcomes, error logs, which features your workspace used, and a record that an AI request ran with which model and what it cost, but not what was asked. When you send a message under System · Support, it goes to sanda with your workspace's own record attached so support already has the context.

sanda keeps an audit record of security-relevant actions (sign-ins, membership changes, SQL run in the shell). It is kept for the life of the workspace and deleted with it.

Availability

sanda does not offer an uptime guarantee unless one is written into a separate agreement with you. Maintenance that needs downtime is announced in advance where sanda can foresee it.

If something goes wrong

No system is perfectly secure, and sanda does not claim otherwise. If a breach is likely to cause you serious harm, sanda will notify you and the Office of the Australian Information Commissioner as the Notifiable Data Breaches scheme requires: promptly, and in any case as soon as practicable after assessing it. sanda will tell you what it knows.

Report a vulnerability

Email security@sanda-os.com.au. sanda also lists hello@sanda-os.com.au as a contact, and both are published at sanda-os.com.au/.well-known/security.txt.

• Ask before you test. The terms ask you not to probe the service for vulnerabilities without asking first. Write with what you plan to do and sanda will agree a scope. sanda always says yes to a genuine, coordinated test.
• Stay in your own workspace. Do not try to reach another workspace's data or degrade the service for others.
• Good faith is safe. Reporting something in good faith is never treated as a breach of the terms.