Trust, security and data governance
Trust at Bijection
A business runs on records that many people, systems and now agents read and change. Every one of them is a way for the wrong person to see too much, or for a change to land without anyone being able to say who made it and why. Small gaps in either compound into real risk.
Bijection closes them in one place. A single engine owns every read, every change and every record of what happened, and each component you add extends what the platform does without a way around those rules.
Data ownership
Full ownership and precise control of your data
Stay in control of your data
- Ownership: Your objects, functions and operations are code in your own repository, versioned and reviewed like the rest of your software.
- Interoperable: Records are read and written through a typed SDK and HTTP API, and leave the platform as ordinary typed values.
- Retention and deletion: Sealed data is encrypted under a per-subject key kept out of the database rows. Erasing the key makes it unreadable, restored backups included.
Access rules enforced by the engine
- Read rules: Access is declared beside each object, per row, per property and per searched domain. The engine applies it to every read, whether from a person, an agent or a component, and rechecks it before serving a cached result.
Trust is in the details
Walk through your security review with the people who built it.
Transparency
See how your data connects and who uses it
One semantic layer for end-to-end visibility
- Semantic structure: Objects, links and actions are declared once as typed code. Every application, agent and component reads the same definitions, so a term means one thing everywhere.
- Dependencies: The engine records the rows, ranges and absences each function read. A result updates when one of them changes, and a conflicting write is detected.
- Provenance: A proposal from a model or a computation keeps its inputs, the processor that produced it and its outcome, whether it was accepted or not.
A record of every operation
- Operation records: Each operation keeps its identity, the definition it ran under, its accepted arguments, its result, its references to external calls and the revision it committed. What changed can always be traced to the operation and the definition that changed it.
- Audited reads: A read rule declared with audit writes one record for each access decision it makes, so sensitive reads leave a trail without logging every query.
Monitoring for suspicious and sensitive activity
- Platform monitoring: Draft — What we watch across the platform, and who is alerted.
- Anomaly detection: Draft — How unusual access is detected and surfaced.
Governance and security
Governance and security in the engine, so every component inherits them
Central identity and secure access
- Identity provider: Sign-in and single sign-on run through WorkOS against your organization's directory, which stays the source of truth for who someone is.
- Multi-factor authentication: Multi-factor enrollment and verification are handled by the identity provider for every member of your organization.
- Network-level security: Draft — Network controls available to a deployment.
Verified controls for regulated environments
- Regulatory alignment: Bijection is HIPAA and GDPR compliant. Ask us for the documentation your review needs.
- One path for every change: A person, an automation, an agent and a component all commit through the engine's single transaction path. No component carries a second way to write, so no component can skip a rule.
- Independently audited: Bijection holds a SOC 2 Type 2 report. It covers what an auditor has examined, which we keep separate from what the engine enforces. Ask us for the report.
- Components by contract: A component exposes only its declared functions. Its callbacks reach itself or components beneath it, and the identity it runs under is computed by the engine, never read from the request.
- Credentials by reference: Integrations hold references to private credentials under scoped credential roles. A product definition names the role, never the secret, and a call to an outside system is recorded before it is sent.
Clear ownership and jurisdiction
- Sovereignty: Draft — Where a deployment runs and who operates it.
Responsible AI
AI that stays governed, traceable and accountable
Responsible AI across the lifecycle
- Data privacy: Zero data retention is available on the model providers we use. A model sees only what the operation calling it is allowed to read.
- Closed agent design: An assistant can call only the tools its contract declares. A request outside that contract is refused, and its output is checked against the type the operation declares before anything uses it.
- Evaluation: Draft — How model behaviour is evaluated before and after release.
Controlled, explainable and sourced
- Controlled access: An agent reads only what its authority allows. A delegated credential lasts one to sixty minutes and carries at most the authority of whoever issued it.
- Typed outputs: Model output is a typed value checked against its declared contract, so what an agent returns can be read, compared and rejected like any other result.
- End-to-end provenance: Every proposal keeps the inputs it was built from, the processor that produced it and what became of it.
AI that supports human judgment
- Decisions, not side effects: An agent prepares a proposal. Applying it takes a decision and goes through the same commit path, checks and record as a change made by a person.
- Context-aware presentation: Draft — How AI output is presented alongside its sources.
- Deterministic guardrails: The conditions an operation declares are checked by the engine on every attempt, whoever or whatever makes it. A model cannot talk its way past them.
Build your bijection.
Bring us a business process, the systems it touches, and the rules it needs to follow. We'll help you work through the first implementation.