Security
One environment per customer. Every change through one doorway.
Bijection runs as a single-tenant deployment inside its own cloud boundary. Reads are filtered by capability, changes cross a governed action with an explicit review rule, and what happened is recorded where the running system cannot rewrite it.
Isolation is the deployment. Not a column in a table.
Installations are separated by infrastructure rather than by a key carried through every query. The isolation holds whether or not the application code is correct.
Its own infrastructure
Each environment is provisioned from its own Terraform state into its own Kubernetes namespace, with its own PostgreSQL database and its own private object-storage roots.
Its own data plane
The source log and the query cluster that hold your records belong to that environment alone. No storage path, connection or queue is selected by a tenant key at request time.
Its own directory
An environment accepts exactly one identity-provider organization and serves exactly one workspace. A second customer is a second environment, not a second row.
Production runs on Kubernetes with a managed PostgreSQL database and native object storage; the same component graph runs locally for development. Cloud administration stays with the deployment, not with the serving application.
Every change is an action. Whoever asked for it.
People, agents, automations and scheduled work all reach the world the same way: there is one mutation path, and it applies the action's own review rule to whoever arrives at it.
Plan, then execute
A plan is stateless and shows exactly what would change. Only execution changes anything, and only execution writes a record of it.
One review rule
Each action declares when a change parks for approval. That rule is evaluated identically for a person, an agent and an automation, and there is no second path that skips it.
Approval is a fresh decision
Approving a parked plan revalidates its effects under the approver's current authority, and the approver must be someone other than whoever initiated it.
Outbound calls to your other systems are declared operations with a fixed method and shape. Credentials are injected after the intent is durably recorded, and provider response bodies are not retained.
An operational record. Kept beyond the database.
Every executed action, review decision, automation activation and agent run leaves a fact carrying who asked, under what authority, and what changed.
Append-only by privilege
The serving identity holds no update, delete or truncate power over operational facts, and no trigger power either. Append-only is a database grant here, not a coding convention.
Exported out of reach
Content-minimized audit records and chained checkpoints are written to independently administered, versioned object storage under write-once retention, carrying identifiers and outcomes rather than your rows.
Verified by reading it back
Verification re-reads the retained objects, recomputes their bytes, walks the whole chain and checks continuity against the head the database acknowledged. A chain that only lives in one database proves nothing.
The honest limit: an adversary controlling both the database administrator and the independent archive administrator could still destroy or rewrite evidence undetected. Closing that would require a third-party notary, and we do not claim to have one.
AI reasons over the world. It does not own it.
Model inference is a bounded step with a typed contract, not a process with credentials and a browser. What it produces is a proposal until a governed action accepts it.
A closed terminal, not an open agent
External model calls are one typed step inside a governed function: one request, one response, no tools, no browsing, no callback into your systems. Structured output is validated before anything downstream sees it.
We train and fit no models
Bijection trains no models anywhere in the platform. Calls go out with provider-side storage disabled, and carry no platform or identity-provider credential and no path back into your database or connectors.
Proposals are not changes
Chat and agents can read, reason and prepare a plan. Applying it means the same action doorway, the same review rule and the same audit record as any other change.
Chat transcripts belong to the person who created them and are deleted with the thread. Tool arguments and results stay with the request and are never written into transcripts, records or logs.
What reaches production. And what it has to prove.
Promotion is a gate over deterministic evidence: identity, policy and configuration. A wall-clock timing may be recorded and alerted on, but it never qualifies or disqualifies a release.
- 01
A signed commit and a pinned image
Traffic moves only for an exact signed executable commit running a digest-pinned image. Nothing is promoted by tag.
- 02
An exact product and secret lock
The product revision and every secret reference are immutable versions named in the deployment, so what ran in qualification is what serves.
- 03
Verified grants and re-hashed evidence
Database grants are checked against what the application role may hold, and every retained piece of evidence is hashed again immediately before traffic moves.
- 04
Readiness, monitoring and a backup plan
Readiness, monitoring and backup-plan identity are conditions of the gate. A candidate that cannot show them does not take public traffic.
Secrets are references, never bytes
The product repository holds pointers to immutable secret-manager versions. Secret values are not in Git, not in deployment files and not in logs or API responses.
Credentials are minted, not held
Repository access is a short-lived credential scoped to one exact repository, minted per request and injected into a single process. It is never returned to a user, written to a local Git config or stored in a vault.
Compliance. Stated plainly.
Bijection holds SOC 2 Type 2, HIPAA and GDPR compliance. Everything else on this page describes what the system enforces, which is a different thing from what has been audited — we would rather you knew which is which.
What we can share today is the design above and the code that implements it. If your review needs specifics — deployment topology, the capability model, the audit export, what a model provider receives — we will walk through them with your security team and answer a questionnaire against what the system actually does.
Common questions.
Is Bijection multi-tenant?
No. A customer installation is a separate deployment: its own Terraform state, Kubernetes namespace, database, object-storage root, source-log and query cluster, and its own identity-provider organization.
There is no shared data plane and no tenant selector at request time, because there is nothing to select between.
Can an AI agent change our systems on its own?
It can read what its authority allows and it can prepare a plan. To change anything it has to call the same declared action a person would call, under the same review rule, with the same record written afterwards.
Agents run beneath the authority of the human or automation that delegated to them, and never above it.
What does a model provider receive?
The serialized request for that one call, sent with provider-side storage disabled and no tools attached. There is no platform or identity-provider credential in it, and no route from it back into your database or connectors. A file a model needs is reached through a short-lived link into a separate, private egress store rather than from the platform's own byte storage.
Bijection trains and fits no models, and zero data retention is available on the provider accounts we use. What a provider retains is governed by that account, not by an assertion here; we describe it as their policy rather than promising zero retention on their behalf.
Who can delete an operational record?
Ordinarily nobody: the serving identity has no delete power over operational facts. Governed erasure exists for the cases that require it, as a single break-glass capability that belongs to no standing role — activating it is itself the grant, and it appends a redaction fact rather than quietly removing history.
Activation needs a second, independent administrator who has authenticated freshly, and the authority is rechecked when the erasure is planned, when a reviewer decides it, and again when it executes. An agent credential that asks for it is refused outright.
How do people sign in?
WorkOS is the identity provider: it owns credential proof, sessions, directory membership, single sign-on and multi-factor enrollment for your organization. Bijection renders the sign-in, SSO and MFA flows itself over the WorkOS APIs rather than a hosted page, and holds the continuations in bounded, encrypted, HTTP-only cookies bound to the person who started them.
Membership and attributes are read live rather than mirrored into a local copy of your directory. Command-line access exchanges a recent browser session for a short-lived token held in the operating system credential store.
Do you have a SOC 2 report or other certification?
Yes — SOC 2 Type 2, plus HIPAA and GDPR compliance. That is separate from the rest of this page, which describes what the system enforces rather than what an auditor has examined. Ask us for the report itself and for anything else your review needs.
Bring us your security review.
We'll walk you through the system.
Deployment topology, the authority model, the audit export, and exactly what a model provider sees. We would rather show you than assert it.