Platform privacy

1. Who holds what

Workspace content — records, files, captured source data, conversations and operational history — belongs to the customer whose installation it is. Bijection builds the software and operates the cloud resources that installation runs on.

Operating managed infrastructure requires deployment-level access to it: cloud administrators and the source-plane administrator remain deployment authority. That is real access. The platform is designed so that it is the only such path — the serving application holds no power to rewrite or delete the operational record it writes.

2. One installation per customer

Each customer environment is provisioned with its own Terraform state, Kubernetes namespace, Cloud SQL database, storage buckets, source-plane cluster and log service, and identity-provider organization.

No resource is selected by a tenant key at request time. A deployment accepts exactly one configured organization and serves exactly one workspace; there is no shared data plane and no request path that could address another customer’s state. Another customer is another environment, not another row.

3. What an installation stores, and where

An environment has a small number of stores, and each owns one kind of data.

• PostgreSQL holds the append-only operational record, file identity and reachability, the content-free catalogue of accepted source captures, conversation and agent state, and rebuildable workflow continuation. It holds no captured source rows.
• A private storage bucket holds platform file bytes. Versions are immutable and the application exposes no overwrite or delete path over them.
• The source plane holds documents captured from your connected systems and their history, keyed so a capture replaces a document rather than accumulating copies, plus a projection of platform objects rebuildable from the operational record.
• A separate egress bucket holds content-addressed renderings of attachments a model request needs. It is private and unlisted, and its objects expire on a bucket lifecycle.
• Secret Manager holds credential bytes as immutable versions. Product configuration in Git carries only references to them; values resolve inside the serving process and stay out of files, logs and responses.

4. Data that stays in your systems

A declared source chooses where its rows live. A virtual source keeps them in your own database: governed reads compile into parameterised queries against that system, and no replica is retained on our side.

A captured source is copied through one periodic capture boundary into the source plane; that copy never reaches PostgreSQL, the platform file bucket or the operational record, and captures are whole published versions rather than a row-level change feed. Sources inside a private network are reached through an outbound-only relay you host: it holds no credential of ours and opens no inbound path.

5. Identity and access

WorkOS authenticates people and owns sessions, organizations, directory membership, multi-factor enrolment and single sign-on. Bijection keeps no copy of your directory — no user table, no invitation store, no role-assignment mirror. A request projects the current principal, uses it, and keeps nothing.

A provider role resolves through a committed binding into an internal capability vocabulary the identity provider never sees, and runtime checks capabilities rather than role names. Access also depends on rules the product itself declares, and discovery is a separate gate from reading: a name you may not discover behaves as if it does not exist.

Revoking access takes effect immediately for anything consequential. Before an operation changes the world, decides a review, writes a file or erases a record, the platform rereads that membership live and refuses a changed authority. Plain reads may ride an already-issued browser token for at most its signed lifetime, which configuration bounds.

6. External model providers

Model inference is one closed path with an explicit trigger; dashboards and validation never call a provider on their own. Each call goes to the provider, model and endpoint the deployment binds, with server-controlled settings: provider-side storage of the request is disabled, prompt caching runs in an explicit mode with no cache breakpoints, one completion is requested, and no tools are offered.

Attachments are not uploaded into a provider’s file storage. The platform writes the rendering it needs into its own private egress bucket and hands the provider a signed URL that expires with the request. A provider receives the content of that request and nothing else — no Bijection account credential, no identity-provider credential, and no path into a workspace.

What a provider does with a request after it answers is governed by the account terms in force with that provider. Zero data retention is available on the accounts we use, and that is where it comes from: an arrangement on the account, not something this page can make true by asserting it. Bijection does not train or fit models on customer data — the platform has no training path at all.

7. What is kept, and how it is erased

Conversation text and its validated citations persist until the thread’s owner deletes the thread. The intermediate material of a turn never becomes a record: raw tool arguments, tool results and transient action proposals stay local to the request and never enter transcript tables, the operational record or logs. What survives a deletion is content-free — that an operation happened, under whose authority, and with what outcome.

Built-in chat stops at planning: it reads what the person in the thread can read and proposes a change, but it has no executor of its own, and the change happens only when that person confirms it through the ordinary governed path. An agent’s private working state is collected once its run finishes.

Operational facts and immutable file versions are kept indefinitely by default; there is no retention setting and no background job that quietly expires them. Erasing the content of a recorded fact is one explicit governed path: the capability belongs to no standing role, and the erasure appends its own redaction fact in the same transaction, so the removal is as auditable as the original write. A legal hold is an append-only decision over one exact subject, and while it is in force it blocks both owner deletion and erasure. Privacy-subject requests take that same reviewed path.

8. The operational record and its audit archive

Every governed change appends a typed fact to an append-only record, and the application’s own database identity cannot update, delete or truncate those facts.

A hash chain whose only copy lives in that same database proves little against whoever administers it. The platform therefore exports content-minimised audit events and chained checkpoints to an independently administered S3 bucket with object lock, versioning and compliance-mode retention; composition refuses a bucket that lacks them. The export carries event identity and time, actor and delegation, outcomes, counts and digests — not payload fields, object keys, action values, conversation text, prompts, captured rows or provider responses.

A verification command reads every retained batch and checkpoint back, recomputes the digests, walks the chain from its root, compares the head against the database’s acknowledged cursor and checks each object version’s retention mode. That is a boundary against the application and the database administrator. It is not a defence against collusion that also spans the archive’s administrator, which would need a third party the platform does not claim to have.

9. Where environments run, and who else is involved

Environments run on Google Cloud: Kubernetes for the application image, Cloud SQL for PostgreSQL, Cloud Storage for bytes, Secret Manager and KMS for credentials and signing. Each environment’s infrastructure is created by its own Terraform state into one selected project and region. Model inference is the one path that ordinarily leaves that infrastructure, and only for the provider endpoint the deployment binds.

Running an environment structurally involves Google Cloud for compute, database, storage, secrets and signing; WorkOS for authentication and directory membership; the external model provider that deployment binds; an independently administered S3 bucket for the audit archive; and Stripe for billing. That is a description of the architecture, not a contractual subprocessor list — a signed agreement, not this page, is where such a list belongs.

10. What Bijection’s own systems hold

Accounts, subscriptions, environment lifecycle and deployment evidence live in a provider-side control plane separate from every customer environment. It holds no workspace rows, no files, no ontology state, no product credentials and no agent objectives or results, and it has no direct authority over an environment’s database. Usage reporting crosses that boundary as a closed, content-free schema: counts and measurements against opaque environment-scoped references.

Your product configuration lives in a repository separate from the application implementation, with its own history, and you and your local Git client authenticate only to Bijection: the backing source service’s credentials, signing keys and hostnames never reach a browser, a command line, a local Git configuration or an API response.

11. What is certified, and what is not

Bijection holds SOC 2 Type 2, HIPAA and GDPR compliance. Beyond those, where a control is described above it is described because it is implemented, not because a third party has examined it — the two are different and we would rather you knew which is which. If your procurement process needs the report itself, a data processing agreement or a breach-notification commitment, ask us and we will tell you what exists today rather than what is planned.

This page changes as the platform does, and the date above identifies the version you are reading. Questions about how the platform handles data can be sent to hello@bijection.com; for anything else, contact our team.