1
Inventory
Enumerate every file and channel. Symlinks, archives, databases, media, metadata, and unknown types require an explicit handler or the operation stops.
Trust center
Security, data boundaries, and assurance
OpenAdapt runs consequential workflows inside a declared execution boundary, admits hosted artifacts by exact evidence, and reserves VERIFIED for runs whose full contract passed. This page maps the enforced controls, customer responsibilities, and external assurance milestones a security review should evaluate.
| Area | Status | In short |
|---|---|---|
| Architecture & data flow | In place | Local-first; PHI/PII boundary documented artifact-by-artifact. |
| Encryption & key boundaries | Boundary-defined | AES-256-GCM protects hosted secrets; TLS protects transit; local artifact encryption follows the selected deployment boundary. |
| Data retention & deletion | Governed | Local retention is operator-owned; hosted retention, legal holds, tenant erasure, and deletion receipts are policy-governed. |
| Subprocessors | In place | Named and current. No default model provider. |
| Identity, access & tenancy | Core controls in place | Org RBAC, row-level tenant isolation, and TOTP step-up protect platform administration; SSO / SAML / SCIM is not included. |
| Release integrity | Provenance in place | Build provenance today; code signing not yet — desktop is unsigned/ad-hoc. |
| Secure development | In place | Open source, SHA-pinned CI, Dependabot, private advisories. |
| Vulnerability disclosure | In place | Private advisory channel; 5-business-day acknowledgment target. |
| Incident response | Operational draft | Private runbook and evidence templates are prepared; policy adoption and the first tabletop are next. |
| DPA & regulated terms | Engagement-specific | The applicable DPA, HIPAA BAA, or PHIPA terms are counsel-reviewed against the qualified deployment before regulated data is admitted. |
| SOC 2 | Not held | Internal controls and evidence are mapped; no auditor-defined observation period or SOC 2 report is held. |
Architecture & data flow
Where data lives, and what can leave the boundary
OpenAdapt is local-first. Recording, compilation, and healthy replay run entirely on the operator machine. Data only leaves that boundary through the explicit, configured paths shown below. This map mirrors the engine's own artifact-by-artifact PHI/PII documentation.
Operator boundary (local, default)
Everything below stays on the operator machine unless an explicit, configured action moves a derivative out.
- Raw recording
- Full screenshots, literal typed values, and structured identity DOM text. Not scrubbed — it is the compile input. Control: filesystem permissions + your retention policy.
- Compiled bundle
- Anchor OCR/context text, identity band (name/DOB/MRN), templates, and identifier crops. Not scrubbed — the identity evidence is what powers the wrong-patient check. Control: filesystem + retention.
- Run report (report.json)
- Parameters, per-step intent, and recorded-vs-live identity text. The audit trail. Not scrubbed by design. The shareable REPORT.md derivative is scrubbed.
- Persisted step / heal frames
- Redacted through Presidio image scrubbing when image scrubbing is enabled, and implied whenever scrubbing is pinned on.
Optional on-prem model appliance
Only when an operator explicitly enables model-assisted repair. The appliance binds to loopback by default and warns loudly if exposed without a token or TLS.
- Identity crops & screenshots
- Sent to the appliance to answer "same record or different?" These are PHI/PII in flight and are deliberately NOT scrubbed — the crop is the identifier. Control is a data-flow boundary: on-prem-only destination + no retention (no disk or log writes), not scrubbing.
OpenAdapt hosted control plane (optional)
Used only for the hosted service. PHI/PII-bearing runtime frames do not cross this boundary; only the artifacts below do.
- Sanitized artifact ingest
- Accepts the reviewed, scrubbed derivative frozen to its exact approved archive hash — never the raw local source. Unsupported types refuse the whole derivative.
- Break report
- A schema-minimal, PHI/PII-scrubbed halt descriptor. No intents, reasons, errors, screenshots, DOM, or field values. Fails closed to local-only if the PHI/PII boundary rejects it.
- Account & run metadata
- Account, organization, subscription, run status, usage, and audit records needed to operate the service.
Full detail: the PHI/PII threat model and the limits and guarantees doc.
Control posture
Controls that ship in the product today
Local browser execution is availableIn place
Recordings, compiled bundles, and replays remain local by default. Treat every compiled bundle as sensitive: it can contain screenshots, typed values, and literal identity evidence. Remote upload accepts only the manifest-bound sanitized derivative admitted by destination policy.
No AI calls on a normal runIn place
Healthy replay makes zero model calls. Deterministic structure, template, OCR, and geometry evidence runs before any optional model. If a remote model endpoint is configured, relevant screenshots or crops can cross that endpoint boundary; running the model on-premises is possible but must be deployed and verified by the operator.
Audit trail on every runIn place
Every replay writes a step-by-step report. The machine-readable report can contain sensitive parameters and identity evidence, and reports are not cryptographically signed or append-only by default. Treat them as sensitive operational artifacts, not an immutable audit ledger.
Sanitized derivatives for artifact uploadIn place
A local sanitizer inventories and transforms a copy, rescans it, records coverage and unresolved findings, and hashes the result. Policy can require a person to review the derivative locally and approve that exact hash. Unknown or unresolved content is refused. The raw original remains sensitive and local.
Challenge-bound hosted bundle admissionIn place
A runnable hosted bundle also needs an operator attestation over its exact approved recording and bundle hashes, compiler provenance, strict lint, policy certification, derived risk class, and successful matching replay report. Cloud verifies deployment allowlists and consumes a one-time challenge when the exact bundle is accepted.
Open source and auditableIn place
The engine is MIT-licensed. You can read the code, run it yourself, and verify these claims rather than take them on trust.
Data boundary
Questions a security review should answer first
- Which components see screenshots?
- The recorder captures frames; compilation extracts visual evidence; replay captures live frames for resolution and postconditions; run artifacts may preserve evidence. These paths execute locally on the shipped browser backend.
- What can transmit them?
- Local healthy replay does not transmit screenshots. An explicitly configured remote model can receive relevant screenshots or crops. Hosted upload accepts the sanitized derivative bound to its reviewed manifest hash, not the local original. Runtime screenshots can reintroduce sensitive data and follow the destination policy of the declared trusted execution boundary.
- Where are secrets and PHI/PII?
- Password and declared secret fields are injected at replay rather than written to the recording. Other screenshots, typed values, identity strings, compiled bundles, and machine-readable reports may contain PHI or PII and require customer-controlled storage and retention. Do not infer that compilation de-identifies a workflow.
- What does break reporting send?
- report-break parses the local run report, scrubs it fail-closed, and sends a PHI/PII-minimized break descriptor. It does not upload the recording or compiled bundle. If the control plane rejects the descriptor at the PHI/PII boundary, the client retries with harder scrubbing and then falls back to local-only.
- What cryptographic guarantees exist?
- Bundles and durable checkpoints support optional AES-256-GCM encryption at rest. Hosted validation uses an ingest-token HMAC to detect mutation and bind evidence hashes to a one-time organization/token challenge and exact bundle upload. Individual run reports are not a signed, append-only audit ledger by default; no claim of tamper-proof audit history is made.
- Is hosted validation an independent certification?
- No. validate-hosted is operator self-attestation: the ingest-token holder signs hashes over local lint, policy, provenance, and replay evidence. Cloud checks exact bindings, freshness, its policy and risk-class allowlists, the deployed compiler-version allowlist, and one-time challenge consumption, but it did not witness the local replay. Independent certification requires a separately controlled evaluator, evidence custody, and signing identity.
- Does Cloud independently witness local sanitation review?
- No. Cloud accounts for every accepted archive byte and verifies the manifest, exact artifact hash, and submitting ingest token. It does not observe the loopback viewer or rerun OCR/NER. The recorded approval is operator attestation; reviewer identity, separation of duties, and evidence custody remain deployment controls.
- Can managed execution reach private-network targets?
- No. Managed browser admission requires public DNS names. Literal IPs, special-use names, and wildcards are refused; the runner resolves each admitted name again and refuses private, loopback, link-local, reserved, or otherwise non-global answers before constructing the sandbox egress allowlist.
- What is the regulated deployment product?
- Regulated workflows run in a declared customer-controlled boundary when their live screens necessarily expose PHI/PII. Sanitized authoring derivatives and minimized control-plane metadata may cross an approved boundary; PHI/PII-bearing runtime frames do not. Deployment scope records the substrate, operators, effect oracle, storage, update, retention, support, and legal controls.
The engine documents its artifact-by-artifact boundary in the public privacy threat model.
Encryption & keys
Encryption boundaries, stated plainly
We describe encryption by what is actually enforced, not by a blanket “encrypted everywhere” claim. Some of it is opt-in, and some sensitive artifacts are not encrypted for you by default.
Bundle & checkpoint at rest
Compiled bundles and durable checkpoints support optional AES-256-GCM authenticated encryption at rest. It is opt-in, not automatic: unencrypted artifacts on disk are protected by filesystem permissions and your retention policy until you enable it. Raw recordings and run reports are PHI/PII-at-rest and are not encrypted for you.
Secret fields (local)
Browser password and declared secret fields are injected at replay time and are not written into recording events or the compiled bundle. Other typed values are recorded literally. On the desktop, the hosted auth token lives in the OS keychain (macOS Keychain, Windows Credential Manager, Linux Secret Service), not in a plaintext config file.
Hosted secrets vault
The hosted service stores workflow secrets per organization, encrypted app-side with AES-256-GCM before they reach the database, so the store only ever holds ciphertext. Values are write-only (never returned to a browser) and are released to a runner once, through a single-use, short-lived token exchange at run time. The encryption key lives only in the control plane and supports zero-downtime rotation.
Bundle integrity
A compiled bundle carries a schema-versioned manifest: a whole-bundle SHA-256 content digest, per-asset hashes, and provenance (source-recording and compiler-config hashes, compiler version, certification). It is sealed on save and re-verified on load. A content digest proves byte identity, not publisher identity, and is not a tamper-proof audit ledger.
In transit
Hosted and provider traffic uses TLS. The Windows desktop control channel adds per-run self-signed certificates with SHA-256 fingerprint pinning and refuses a plaintext downgrade to a non-loopback host. The optional on-prem model appliance expects TLS terminated at a reverse proxy and a service token; it warns loudly at startup if bound off-loopback without one.
Hosted ingest integrity
Artifact ingest is bound by an attestation the operator HMAC-signs with their ingest token, over exact evidence hashes and a single-use, time-bound, organization-scoped challenge, so a mutated or replayed upload is refused. This detects tampering; it is not a third-party certification of the workflow.
PHI/PII sanitation
Scrubbing creates a reviewable derivative
Scrubbing is not a boolean claim attached to a bundle. It is a local transformation and approval protocol. The raw source never becomes safe merely because a derivative exists, and a sanitized recording does not prevent live PHI/PII from appearing during execution.
Sanitation and runnability are separate gates. Register the approved recording derivative, compile it locally, pass strict lint and policy certification, and produce a successful matching replay report. Then sanitize, review, and approve a bundle whose execution-bearing content is unchanged. If recording sanitation changed execution content, hosted ingest marks it needs_parameterization; parameterize before compilation.
2
Transform a copy
Keep the sensitive original local. Redact or parameterize supported text, structured records, screenshots, and metadata in a separate derivative.
3
Rescan and manifest
Scan the derivative again, record tool and policy versions, list unresolved findings, and compute a cryptographic hash over the exact result.
4
Review and approve
When policy requires it, inspect the derivative locally, correct missed or excessive redactions, then approve its hash. Any later modification invalidates approval.
| Review policy | Best fit | Tradeoff |
|---|---|---|
| Automatic | Lowest friction for schema-minimized diagnostics with complete handler coverage. | A detector false negative can cross the boundary. |
| Human required | Adds contextual review for screenshots, free text, and consequential artifacts. | Costs operator time and human approval is not proof of de-identification. |
| Risk-based hybrid | Automatic for narrow diagnostics; review required for recordings and bundles unless an administrator approves a measured policy. | Requires explicit artifact classes, thresholds, and audit configuration. |
The launch default is the risk-based hybrid: minimized diagnostics can be automatic; recordings and bundles require review unless an administrator explicitly adopts an automatic policy with complete type coverage.
Hosted runtime gate
Approval, validation, and certification are different
The cross-engine sequence is recording sanitize → review → approve → push; local compile → strict lint → certify → successful replay; bundle sanitize → review → approve; then validate-hosted → attested bundle push → configure → run. The validation envelope binds exact artifact hashes, compiler and parameter-schema provenance, the exact non-PHI HTTPS entry URL, target boundary, and actual replay origin, lint/certification and report hashes, the derived low or consequential risk class, and a fresh one-time challenge. Cloud additionally requires exact policy, risk-class, and deployed compiler-version allowlist membership.
This is operator self-attestation, not third-party certification. It proves that the token holder signed a non-mutated evidence envelope; it does not prove an independent party witnessed the replay or that the workflow is universally safe.
Run the exact hosted validation sequence →Retention & deletion
Local custody, governed hosted retention
Local artifacts. The engine does not automatically delete raw recordings, bundles, machine reports, or checkpoints. Retention and deletion of local data are controlled by the operator through filesystem and backup policy.
Hosted service. The live service applies a versioned policy to recordings, reports, run metadata, and its declared backup-recovery window. Legal holds pause eligible deletion without storing case details in the hold record. Short-lived signed runner URLs limit object access; retention jobs govern stored-object deletion separately.
Tenant erasure and evidence. Deletion is scoped to the exact organization and produces an append-only receipt containing resource identifiers, counts, and digests rather than deleted payloads. A destructive retention job refuses to run without a recent restore-drill receipt. The current database restore receipt does not by itself prove object-storage recovery or a provider backup SLA; those remain deployment evidence rather than an inferred claim.
Shared billing, security, and service records are excluded from tenant erasure when they must remain for platform integrity or legal obligations. Their handling is governed by the applicable service and deployment terms, not silently treated as customer workflow data.
Inspect the live retention readiness signal →Deletion requests for personal information can be sent to hello@openadapt.ai; see the Privacy Notice.
Subprocessors
The third parties in our current product paths
These providers can receive the network and service data needed for the selected interaction and process it under their own terms. A customer-controlled deployment can use a different approved provider set documented in its scope.
| Provider | Purpose | Where used |
|---|---|---|
| Netlify | Website hosting and form submissions | Marketing site, contact/update forms |
| Supabase | Hosted authentication, database, and private object storage | Hosted service accounts and artifacts |
| Modal | Managed browser recording and run compute; optional hosted compilation only when explicitly enabled | Hosted service runtime |
| Stripe | Checkout, billing, and subscription state | Hosted service billing |
| PostHog | Launch-funnel analytics when a key is configured (autocapture, persistence, and session recording disabled) | Marketing site only |
| Cal.com | Meeting booking | Marketing site booking flow |
| GitHub | Source links, repository widgets, and public repository data | Marketing site + open source |
No default model provider. Healthy replay makes no model calls, so no AI provider is a standing subprocessor. If an operator explicitly enables model-assisted repair, they choose the endpoint (a local or on-prem model, or a remote provider under that provider's own terms).
Identity, access & tenancy
Tenant isolation and administrator MFA
The hosted service authenticates users through Supabase Auth and enforces per-organization role-based access control with owner, admin, and member roles. Every tenant table is protected by Postgres row-level security scoped to organization membership, so data is isolated per organization rather than shared across tenants.
Authenticator-app two-factor authentication is available to every account and enforced for platform administration. The platform-admin console always requires both the server-side administrator allowlist and a current two-factor session. When a signed-in session needs this additional assurance, Cloud asks for one current 6-digit code and returns the user to the protected page after it is accepted.
Enrollment also produces one-time recovery codes. If an authenticator is lost, a recovery code removes the inaccessible factors. Factor removal invalidates active sessions, so Cloud explicitly returns through sign-in and then to Security & 2FA to enroll a replacement. Recovery never grants the protected session by itself.
The signed-in account menu keeps identity and organization context visible. It provides Security & 2FA, organization switching when an account belongs to more than one workspace, and an explicit sign-out action. The account-security guide covers enrollment, step-up, recovery, and account or workspace switching.
What is not yet available: enterprise SSO / SAML and SCIM provisioning. Login is handled by Supabase Auth (email and OAuth providers), not by an external enterprise identity provider. We would rather say that than imply an enterprise SSO program we have not shipped.
If you need enterprise identity integration now, a customer-controlled deployment lets you own the identity provider, access model, and audit inside your boundary. The open-source engine itself has no account system: installing it does not create an account or send anything to the hosted service.
Release integrity
Signing, provenance, and software inventory
Build provenance & attestationsIn place
The PyPI engine publishes wheel and sdist with PEP 740 publish attestations. Desktop Beta 0.13.1 publishes a SHA256SUMS manifest and GitHub build-provenance attestations for every installer, metadata file, and SBOM. Provenance answers "was this built from our source by our CI"; it is not the same as code signing. Inspect the public checksums and attestations →
Code signingExternal identities required
Desktop installers are currently UNSIGNED (Windows, Linux) or ad-hoc signed (macOS), and their filenames say so. Apple Developer ID + notarization and Windows Authenticode are not yet configured; the signing workflow fails closed on partial credentials. Until signing lands, verify downloads with the published checksums and attestations.
Software bill of materials (SBOM)In place
Desktop Beta 0.13.1 publishes a CycloneDX JSON SBOM generated from the exact smoke-tested installer set. The release workflow rejects an empty or malformed SBOM before publication, includes its hash in SHA256SUMS, and attests the SBOM alongside the installers. Download the public CycloneDX SBOM →
Execution control overlayIn place
Desktop Beta 0.13.1 provides a separate native status surface outside the target application. During active observation and execution it is click-through, non-focusable, and excluded from capture before it becomes visible; controls appear only at a safe paused or terminal boundary. Overlay presentation state is never used as target-resolution or verification evidence. Inspect the released overlay contract →
The two-lane release policy and its planned convergence after signing lands is documented in the desktop release policy.
Secure development
How the software is built
Open source, reviewable
The compiler and runtime are MIT-licensed and public. Anyone can read the code, reproduce the behavior, and file findings.
Pinned, monitored supply chain
GitHub Actions are pinned by commit SHA and dependency updates flow through Dependabot. A pinning gap is explicitly in scope for a security report.
Change control
Changes land through pull requests with automated checks (build, contract, and truth tests on this site; engine test suites upstream) before release.
Privacy as a choke point
PHI/PII scrubbing is wired through a single documented choke point with fail-closed and fail-loud modes, so a missing scrubber cannot silently leak.
Vulnerability disclosure
Report a vulnerability
If you have found a security issue, please report it privately so we can fix it before it is disclosed. The fastest path is GitHub's private vulnerability reporting on the repository. You can also email us with “Security” in the subject line. Please do not open a public issue for a suspected vulnerability. We aim to acknowledge a report within five business days, confirm affected versions, prepare a fix, and credit reporters who wish to be credited.
Incident response
Incident response with an explicit operating gate
We have a defined intake and handling path for reported vulnerabilities (above): private triage, affected-version analysis, a forward-shipped fix, and reporter credit. That is the part of incident response that is real and operating today.
A private incident runbook, incident-record template, and tabletop template are prepared. Policy adoption, named response delegates, and the first recorded tabletop are the remaining gate before we describe this as an operating program. Contractual notice and response commitments are defined in the qualified deployment rather than implied as a standing SLA. For the open-source engine running inside your own boundary, you remain responsible for the surrounding firewall, KMS, storage, identity, and backup controls.
Legal readiness
Data-protection terms follow the qualified boundary
Data Processing Agreement (DPA)Counsel review
During qualification we document the parties, processing purpose, data classes, locations, subprocessors, retention, deletion, and security responsibilities. Counsel then reviews the applicable data-processing terms for the exact service and jurisdiction. Email hello@openadapt.ai to include that review in your evaluation.
Business Associate Agreement (BAA)Qualified deployment
Healthcare deployments keep raw observations in the customer-controlled boundary by default. The actual legal role still depends on the service and data flow. Before regulated data is admitted, counsel must approve any required US HIPAA BAA or Ontario PHIPA service-provider terms together with the exact deployment, subprocessor, security, retention, and incident schedules. Hosted Cloud is not presented as PHI-ready by default.
Assurance & attestation
SOC 2 and independent attestation
SOC 2No report held
OpenAdapt maintains a private controls matrix, gap assessment, and evidence plan mapped to Security, Availability, and Confidentiality criteria. Those working materials help prioritize real controls; they are not an audit opinion or an attestation.
Current technical controls include tenant row-level isolation, server-verified administrator MFA, encryption of hosted secrets, hash-bound artifact admission, production non-simulation, constrained managed-runner egress, release provenance, and private vulnerability reporting. Operating evidence, legal review, provider configuration, and independent examination are tracked separately from code presence.
OpenAdapt does not hold a SOC 2 report, has not opened an auditor-defined observation period, and does not claim certification. If an examination begins, this page will name the exact report type, scope, auditor, and period.
Open source lets you verify these controls yourself rather than take them on trust — but self-verification and an independent attestation are different things, and we keep them clearly separate here.
Reviewing OpenAdapt for a regulated deployment?
We are glad to walk your security team through the architecture and answer the hard questions. Bring your requirements and we will tell you what we can and can't meet today.