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 is built to run where your data already lives. This page is written for a security reviewer: every area below states what actually exists today, what you control, and what we do not have yet. Where a control is not in place, we say so rather than imply it.
| Area | Status | In short |
|---|---|---|
| Architecture & data flow | In place | Local-first; PHI/PII boundary documented artifact-by-artifact. |
| Encryption & key boundaries | Partial | Optional AES-256-GCM at rest; TLS in transit; HMAC-bound ingest. |
| Data retention & deletion | Operator-controlled | Local retention is operator-owned; hosted has no fixed schedule yet. |
| Subprocessors | In place | Named and current. No default model provider. |
| Identity, access & tenancy | Partial | Org RBAC, row-level tenant isolation, and TOTP step-up protect platform administration; SSO / SAML / SCIM is not included. |
| Release integrity | Partial | 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 | Partial | Reporter-facing process defined; formal program is early. |
| DPA & BAA | Scoped per engagement | DPA (GDPR/CCPA/PIPEDA) available on request. In the self-hosted deployment PHI/PII stays in your environment, so a BAA is not the operative instrument for that shape; where procurement requires written terms we can sign a US HIPAA BAA, or for an Ontario clinic a PHIPA service-provider agreement, following review. |
| SOC 2 | Readiness program | Type II readiness program underway; controls mapped to AICPA Trust Services Criteria. No report yet. |
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
Retention is operator-owned; hosted has no fixed schedule yet
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 hosted service persists account and organization data, managed recordings, approved artifacts, bundles, reports, run and usage records, and billing references in its configured stores. Short-lived signed runner URLs limit object access but do not delete the stored objects.
No fixed schedule yet. The self-serve service currently publishes no fixed retention, backup-deletion, or recovery period. Do not send data that requires a specific schedule until that schedule and deletion process are documented in a qualified written deployment scope. Providers can retain billing, security, or service records under their own obligations.
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
Access control: honest current state
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 SBOMs — what actually ships
Build provenance & attestationsIn place
The PyPI engine publishes wheel and sdist with PEP 740 publish attestations. Native desktop installers ship a SHA256SUMS manifest with SLSA provenance-v1 build attestations you can verify with sha256sum -c and gh attestation verify. Provenance answers "was this built from our source by our CI"; it is not the same as code signing.
Code signingPartial
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)Roadmap
We do not currently publish a machine-readable SBOM as a release asset. Dependencies are visible in the open-source lockfiles, and dependency updates flow through Dependabot. A published SBOM is a roadmap item.
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: honest posture
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 formal, contractual incident-response program — customer breach notification timelines, on-call rotation, and post-incident reporting — is early and is scoped per engagement rather than offered as a standing SLA. For the open-source engine running inside your own boundary, incident response for the surrounding environment (firewall, KMS, storage, identity, backups) is your responsibility; the engine supplies audit primitives, egress checks, and run reports to support it.
Legal readiness
DPA and BAA
Data Processing Agreement (DPA)Available on request
A Data Processing Agreement covering GDPR, CCPA, and PIPEDA is available on request for hosted-service customers. Email hello@openadapt.ai and we will provide our DPA as part of your evaluation.
Business Associate Agreement (BAA)On-prem; signable on review
For healthcare workflows, the default deployment is self-hosted: OpenAdapt runs entirely inside your environment and PHI stays in your network. Because the software does not create, receive, maintain, or transmit PHI on your behalf in that shape, OpenAdapt is positioned as an on-premise software vendor rather than a business associate, and PHI does not enter our infrastructure. Your compliance officer or counsel makes the determination for your environment. Where your procurement requires written terms, we can sign a US HIPAA Business Associate Agreement, or for an Ontario clinic a PHIPA service-provider agreement, following review. Hosted processing of PHI inside our infrastructure is governed by a signed BAA and a deployment-specific HIPAA risk analysis before regulated data is admitted. This describes the deployment architecture and what we can sign, not legal advice.
Assurance & attestation
SOC 2 and independent attestation
SOC 2Readiness program underway
SOC 2 readiness program underway. Security controls are implemented and mapped to the AICPA Trust Services Criteria; a SOC 2 Type II attestation is being pursued. Status and timeline available on request.
OpenAdapt operates a formal information-security program built around the AICPA SOC 2 Trust Services Criteria (Security, Availability, and Confidentiality). We maintain a documented policy suite, a controls matrix mapped to the Common Criteria (CC1–CC9) plus Availability (A1) and Confidentiality (C1), and an evidence-based internal gap assessment. Core technical controls are already in production, including tenant isolation (row-level security), encryption of secrets at rest (AES-256-GCM) and data in transit (TLS), least-privilege access, a hardened CI/CD supply chain, and automated PII/PHI sanitization. We are pursuing a SOC 2 Type II attestation; our roadmap, current control status, and security documentation are available under NDA on request.
OpenAdapt does not yet hold a SOC 2 report. We do not claim certification. When an audit is genuinely underway, this page will name the report type, the auditor, and the period — and not before.
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.