Trust & Security

Orchestate is a hosted finite-state-machine service operated by Wentzel Investments LLC (trading as Wentzel.ai). Protecting the confidentiality, integrity, and availability of machine definitions, instance state, and account data is a core obligation — not a marketing feature.

This page describes Orchestate’s current security posture, SOC 2 status, infrastructure isolation, sub-processors, access review cadence, and how to report a vulnerability.

Wentzel Investments LLC is SOC 2 Aligned: our controls are mapped to the AICPA Trust Services Criteria through self-assessment. Auditor engagement is pending, and no SOC 2 report has been issued.

We do not hold a SOC 2 report of any type and we are not certified — SOC 2 issues a report, not a certificate. We do not publish a target date. We will link the report (or an NDA summary for prospects) on this page only once an auditor has issued one.

Evidence scaffolding for Orchestate (access reviews, vendor inventory, product isolation checks) lives under apps/orchestate/docs/compliance/ and is collected into the continuous-monitoring evidence path as the programme matures.

Orchestate production workloads run on Cloudflare Workers, with Cloudflare D1 (SQLite) for structured data, Durable Objects for instance state, and Cloudflare R2 for object storage. The state-machine engine is Orchestate’s own pure-TypeScript implementation (workers/runtime/src/fsm.ts) — not a third-party FSM vendor or source-available gateway.

All data in transit is encrypted with TLS 1.2 or higher. Data at rest is encrypted by the storage platform (AES-256). Production systems follow least-privilege access; employee access is reviewed quarterly. Orchestate uses dedicated product-scoped D1 databases, R2 buckets, Workers, and Analytics Engine datasets so other Wentzel products cannot reach Orchestate data through shared bindings.

Orchestate is isolated from sibling Wentzel products at the infrastructure binding layer. The product slug is `orchestate`. Production D1 is `orchestate-prod`, R2 is `orchestate-assets`, the runtime Worker is `orchestate-runtime`, and `NEXUS_PRODUCT_SLUG` is set to `orchestate` in every environment.

Automated checks under `src/lib/trust/isolation.ts` assert that wrangler resource names stay product-scoped so a mis-bound shared database cannot silently land in a PR.

Employee and contractor access to Orchestate production systems is reviewed at least quarterly. Reviews cover Cloudflare account membership, Worker secret access, D1/R2 admin roles, and the private-beta allowlist (`ORCHESTATE_ALLOWED_EMAILS` / domain gate).

The procedure, evidence checklist, and last-review stamp live in docs/compliance/access-review.md. Exceptions require owner approval and are recorded in the evidence ledger.

We process personal data only to deliver Orchestate, keep it secure, and meet legal obligations. We do not sell personal data, and we do not use customer machine definitions or instance context to train shared or third-party models.

Data is retained while the account is active or as needed for legal and audit-evidence obligations. After account termination we make customer data available for export for 30 days, then delete it unless law requires retention.

Orchestate engages the following sub-processors. Cloudflare is the sole runtime and infrastructure sub-processor. Additional processors are disclosed only for the specific services they provide. The FSM engine is first-party pure TypeScript and is not a third-party sub-processor.

The same runtime artifact runs three ways: fully managed on Cloudflare, in your own Cloudflare account, or air-gapped on open-source workerd (Apache-2.0). workerd runs the same code as the hosted platform, so there is no platform lock-in and no third-party FSM gateway in the path.

See /docs/self-hosting for deploy steps. The self-host and air-gap path leads with the Apache-2.0 workerd engine — not a source-available competitor gateway.

If you believe you have found a security vulnerability in Orchestate, please report it responsibly. We will acknowledge your report within two business days and aim to resolve confirmed issues within 30 days, depending on severity.

Please do not publicly disclose a vulnerability before we have had the opportunity to investigate and remediate. We do not currently operate a formal bug-bounty programme, but we will acknowledge researchers who responsibly disclose valid findings.