Platform privacy

1. Who owns the data

Your workspace content (records, files, data captured from your systems, conversations and history) belongs to you. We build the software and operate the cloud resources it runs on.

Operating those resources means our cloud administrators have access to them. That is the only such access: the application itself cannot rewrite or delete the record it writes.

2. One environment per customer

Each customer has their own PostgreSQL database, backend processes, storage, source data store, log service and sign-in organization. We operate it; nothing is installed in your own cloud account.

Nothing is shared between environments, so no request can reach another customer's data. Another customer is another environment, not another row in a shared table.

3. What is stored, and where

Each store in an environment holds one kind of data.

• PostgreSQL holds the append-only record of operations, file references, a catalogue of source captures without their content, conversations and agent state. It holds no rows captured from your systems.
• A private storage bucket holds file contents. The application cannot overwrite or delete a stored version.
• The source store holds documents captured from your connected systems and their history, plus a copy of platform objects that can be rebuilt from the record.
• A separate bucket holds attachments prepared for a model request. It is private and unlisted, and its contents are deleted automatically after a set time.
• A secrets manager holds credentials. Configuration holds references to them only; the values never appear in files, logs or responses.

4. Data that stays in your systems

You choose, for each source, whether its data is copied. A virtual source stays in your own database: we query it when needed and keep no copy.

A captured source is copied periodically into the source store, and never into PostgreSQL, file storage or the record. Systems inside a private network are reached through a relay you host, which only makes outbound connections and holds none of our credentials.

5. Sign-in and access

WorkOS handles sign-in, sessions, single sign-on, multi-factor authentication and your directory. We keep no copy of your directory: no user table, no invitations, no copy of role assignments.

Roles from your identity provider map to permissions that are checked on every request. A record you may not see behaves as if it does not exist.

Revoking access takes effect immediately for any change, approval, file write or erasure. Plain reads may continue until the current browser token expires, within a configured limit.

6. Model providers

A model is called only when something explicitly asks for it. Each call goes to the provider the deployment is configured for, with provider-side storage turned off, one answer requested and no tools offered.

Attachments are not uploaded to the provider. It receives a link to our private bucket that expires with the request. The provider gets that request and nothing else: no credentials and no path into your workspace.

What a provider does after answering is governed by our account terms with that provider. Zero data retention is available on the accounts we use; that is an arrangement on the account, not something this page can guarantee. We do not train models on customer data, and the platform has no way to.

7. Retention and erasure

Conversations are kept until their owner deletes them. The inputs and outputs of tools used during a conversation stay with the request and are never written to transcripts, the record or logs. After a deletion, only facts without content remain: that something happened, under whose authority, and its outcome.

Chat can read what you can read and propose a change, but it cannot apply one. The change happens only when you confirm it.

The record and file versions are kept indefinitely by default, and nothing expires them in the background. Erasing content is a separate reviewed action that no standing role holds, and it records its own redaction. A legal hold blocks deletion and erasure while it is in force. Privacy requests go through the same reviewed path.

8. The record and its archive

Every change adds an entry to an append-only record that the application cannot edit or delete.

A summary of each entry is also exported to a separate storage bucket run by different administrators and locked against changes and deletion for a retention period. The summary says who, when, under what authority and with what outcome. It does not contain your data, prompts or model responses.

A verification command reads the archive back and checks it against the database. This protects against the application and the database administrator, but not against both administrators acting together; that would need an outside party we do not have.

9. Hosting and providers

We run each environment in one region, on cloud accounts we operate: containers, a managed PostgreSQL database, object storage and a secrets manager. Running in your own cloud account or on premises is not offered. Model calls are the only thing that normally leaves this infrastructure.

Running an environment involves our cloud and database providers, WorkOS for sign-in, the configured model provider, a separate storage bucket for the audit archive, and Stripe for billing. This describes the architecture. It is not a contractual subprocessor list, which belongs in a signed agreement.

10. Our own systems

Accounts, subscriptions and deployments are managed in a system separate from every customer environment. It holds none of your records, files or credentials, and it cannot reach your database. Usage reaches it only as counts and measurements.

Your product configuration lives in its own repository. You sign in to Bijection only; the credentials of the service behind it never reach your browser, command line or Git configuration.

11. Certifications

Bijection holds SOC 2 Type 2 and is HIPAA and GDPR compliant. Everything else on this page describes what is built, not what an auditor has examined. If your review needs the report, a data processing agreement or a breach-notification commitment, ask us and we will tell you what exists today.

This page changes as the platform does, and the date at the top shows the current version. Questions go to contact@bijection.com, or contact our team.