Trust is a feature. So is honesty.

Who can access my content?

Content is isolated by tenant and workspace. Every read is checked in the database against the caller’s readable envelope, so an agent or person outside the boundary receives no content — and the response is the same whether a record exists or is simply inaccessible.

• People reach a workspace through their account and role. Workspaces can be linked read-only where a team needs a shared view.
• Agents reach a workspace through an approved grant with explicit permissions. A first request is not served until a human approves the grant.
• Operators run the service. We do not claim that infrastructure administrators cannot access plaintext. Emergency access is governed by documented controls with approval, duration, audit and customer notification.

Where do data, backups, logs and embedding requests go?

Each tenant has a fixed home_region. The first region is ap-southeast-2 (Sydney, Australia), where the primary database and its encrypted backups live.

“Hosted in Australia” is not a claim about every processing path. Embedding is the clearest example: when an embedding provider is bound, content used for that request goes to that provider, which may be a disclosed subprocessor in a different region. The list is published as data at /subprocessors.json.

Processing	Where	Notes
Primary database	ap-southeast-2	Tenant-isolated, row-level security.
Ordinary database backups	ap-southeast-2	Encrypted; not edited in place. Retention published in the terms.
Diagnostic application logs	ap-southeast-2	Content-free; retention published in the terms.
Self-hosted embedder	ap-southeast-2	In-boundary; no disclosure.
Amazon Bedrock (Titan v2)	ap-southeast-2	In-region processor; disclosed, switchable to keyword-only.
OpenAI text-embedding-3-small	United States	External processor; only if explicitly enabled by the tenant.

The hosted deployment at sbrain.app binds the in-boundary self-hosted embedder, so semantic retrieval runs there and no content leaves for embedding. A deployment with no bound provider runs keyword-only, and a tenant can switch to keyword-only. Only facts are embedded today; pages and playbooks stay keyword-only.

Is content used for training?

No. Customer content is not used to train or tune any model. It is not sent to a model to complete onboarding, determine billing status or choose a tenant. Changing this would require a product and privacy review and consent where required — never a silent settings change.

How do export, deletion and revocation work?

• Export. You can export your readable content and your instructions as jobs, then download the result through an authenticated link that re-checks access at download time.
• Deletion. A tenant deletion request revokes credentials first, then runs a resumable purge that reports its progress. Legal holds are supported for the cases that need them.
• Revocation. Revoking a principal ends its access going forward, and caches that follow the change feed are told to re-sync.

What we do not claim

• Revocation does not reach back. It ends access going forward. It cannot remove content already disclosed to third-party models, clients, logs, exports or backups.
• Backups are not edited in place. A deleted record cannot be brought back into service, but a residual copy may remain in backups until the published window passes.
• One home region per tenant. There is no active-active multi-region write path.
• We run it. There is no customer-hosted production, customer-managed key or confidential computing offering.
• Audit is actor-recorded, not tamper-proof. Secret scanning is defence in depth, not a guarantee.
• No certification is claimed. We do not hold or claim SOC 2 or ISO certification.

Policies and contacts

• Terms of Service — including the published retention windows.
• Subprocessors — the machine-readable list.
• [email protected] — general and privacy requests.