Security built around the action, not just the login.
Because SupraOS connects evidence and execution across customer systems, the security boundary covers more than account access: it covers sources, action scope, approvers, connector identities, verification, and proof.
Effective and last reviewed: 16 July 2026
Production architecture
| Layer | Production standard |
|---|---|
| Application hosting | SupraOS runs as a managed service on European infrastructure. Hosting, isolation and data boundaries are documented for every deployment. |
| Customer systems | Approved CRM, product, support, contract, finance, identity, work, and evidence systems remain the sources of truth. |
| SupraOS-held state | Approved workflow state, Charters, evidence references, selected artifacts, approvals, policy decisions, execution metadata, Receipts and Value Ledger records. |
| Connector access | Connector credentials use the narrowest available provider scope; the Charter and policy restrict authority to the approved action. Every deployment starts read-only. |
| AI processing | Customer-approved model providers are disclosed before use. AI data-use rules are published in AI governance. |
| Customer isolation | Every customer deployment has a documented isolation boundary reviewed during security diligence. |
Deployment and isolation
Europe-hosted managed service
SupraOS is delivered as a managed service hosted in Europe. Additional deployment options are agreed for the customer environment.
Customer systems remain authoritative
SupraOS coordinates work around customer systems rather than replacing them as systems of record.
Defined availability and recovery
Each production agreement defines backup, restore, uptime, RPO and RTO commitments.
Access and authority controls
Source scope
The approved source, object, and field scope is defined before access begins.
Read-only first
Discovery can begin without granting write authority.
Role and policy checks
The current action is checked against the Charter, role, source scope, policy, and risk class.
Named approvals
Consequential actions can require an eligible person to approve the exact reviewed action.
Destination verification
Each connector write is read back from the destination system before that connector action is verified.
Workflow proof
Receipts record the evidence, authority, action and verification state.
Encryption and secrets
Transport security
TLS protects public and application traffic in transit. Security review covers storage, backup encryption and the complete customer data path.
Connector credentials
Credentials stay server-side, scoped and revocable—and never enter public browser code.
Customer authority limits connector capability
Charter, policy and approval controls keep executable authority narrower than connector capability.
Deployment control review
Encryption, key management and isolation controls are documented for the customer environment during security review.
A connector write from start to finish
| Stage | Control |
|---|---|
| Prepare | Build the proposed write, target record, parameters, evidence, and expected resulting state. |
| Classify | Check source scope, Charter, policy, role, risk class, and approval requirement. |
| Approve | Where required, bind an eligible person’s approval to the exact reviewed action. |
| Execute | Release the action through the scoped connector identity. |
| Read back | Query the destination system and compare the observed state with the intended state. |
| Record | Create the action Receipt and update the workflow and Recovery Record. |
Security diligence
Architecture and data flows
Review the production architecture, customer data path, isolation boundary and connected-system controls.
Contractual controls
Review the DPA, security schedule, subprocessors, retention, recovery and deployment commitments.
Execution evidence
Review source controls, exact-action approval, connector execution, destination checks and Receipts.