Security

Ownership and confidentiality

You own everything you put in. We process it to run the product for you and for nothing else. We do not sell it, share it, or mine it. Your material is never used to train a model, ours or a third party's. Your corpus is logically isolated from every other customer's; where a firm's policy requires more than that, a dedicated single-tenant instance is available (see Deployment options, below).

Isolation is enforced in code, not asserted. Every read and write is scoped to the owning collection, and no endpoint or agent tool trusts a client-supplied identifier for authorization.

Encryption

All data is encrypted in transit (TLS 1.2 and above) and at rest (AES-256). That covers your uploaded source files, the database, the search index, and every backup and snapshot. HTTPS is enforced end to end; no plaintext hop carries customer data.

Access and authentication

For your team: single sign-on (SAML and OIDC) and multi-factor authentication are both available.

On our side: production access is least-privilege and limited to the people whose work requires it, multi-factor authentication is required on every account that can reach production, and access is reviewed on a fixed cadence.

Roles and permissions

Access has two layers. Workspace roles — owner, administrator, member, and guest — govern what someone can do: create collections, invite people, see the member list, manage billing. Collection access governs what they can reach, as an explicit read, write, or admin relationship with each collection they belong to. Administering the workspace does not grant access to what is inside its collections; the two layers are deliberately separate.

Workspace membership is the outer boundary, which makes offboarding a single action: removing someone revokes every collection they could reach at once, and reinstating them restores exactly what they had. People invited from outside your organization join as guests, with access to the collections shared with them and no view of the workspace, its members, or anything else it owns.

Audit logging

Actions that change who can reach what, and actions that delete material, are recorded to an append-only audit log scoped to your workspace. Entries are never edited or removed, and each names who acted and what they acted on at the time, so the record outlives whatever it describes. Reading is not logged: this is a record of administrative and destructive actions, the same scope cloud providers use for management events, rather than a trail of every document opened.

Administrative access to your material is itself an audited action. An administrator can see that a collection exists — its name, its owner, who has access — without being able to read what is in it; opening one means taking an explicit grant, which is recorded and can be released. That grant is also shown to the collection's own members. There is no standing administrative read over your material, and no way to look inside a collection without leaving a record the people in it can see.

Owners and administrators can review their workspace's log in the product; every member can see the entries that concern them.

Infrastructure and hosting

The product runs on Amazon Web Services in the US West (Oregon) region, us-west-2. Compute and data sit inside a private VPC. The database is in private subnets with no public accessibility; only the application tier is reachable from outside, and only over TLS. Data residency in another region is available for enterprise deployments.

How the AI works, and what leaves your boundary

When you search or chat, the passages retrieved from your corpus and the query itself are sent to Amazon Bedrock, running Anthropic's Claude models, to generate the answer. Nothing beyond that leaves. Under the Bedrock terms, the model provider does not retain that content and does not use it to train or improve any model.

If you would rather keep inference in your own hands, our MCP server exposes the corpus to your models and agents. Your AI usage then operates under the terms, pricing, and data handling agreements you already have with the providers you choose.

Subprocessors

We use a small, named set of third parties to run the product. Amazon Web Services provides hosting, storage, the database, and backups, and therefore touches all customer data, encrypted. Amazon Bedrock performs AI inference and receives retrieved passages and queries on a per-request basis; that content is neither retained nor trained on. Stripe processes payments and receives billing contact and subscription metadata - full card details never reach our servers.

We will give notice before adding a subprocessor that touches customer data.

Retention, export, and deletion

You can export everything you have put in (sources, annotations, and writing) at any time. There is no lock-in and nothing is held back. On request or on termination, we delete your data within seven days, including from backups as they age out on their normal rotation.

Incident response

We maintain an incident-response plan and will notify affected customers without undue delay after confirming an incident that affects their data.

Deployment options

Most firms run on our multi-tenant cloud, with the isolation and controls described above. Where a firm's policy requires more, we offer managed, single-tenant instances, or deployment into your own cloud account. More information can be found on the deployment page.

Contact

If you have any questions about any of the above, or something to report - including responsible disclosure of a vulnerability - please reach out to info@thoughtprocess.us.