# Orch8 vendor security questionnaire (pre-filled)

Prepared by Orch8.io from the public engine repository and orch8.io policies.
Last reviewed: 2026-09-28. Answers describe the engine source and the hosted
service as published; verify them against the version you deploy.

Where we cannot answer from published material, the answer is
**Available on request**. Email security@orch8.io and we will answer in
writing. Nothing in this document is a certification or an audit report.

Legend for deployment models:

- **Self-hosted**: you run the engine and database. Orch8.io receives nothing.
- **Observability**: you run the engine; it sends run metadata to Orch8 Cloud.
- **Cloud (Starter, Pro)**: Orch8.io runs the engine and database for you.
- **Hybrid**: Orch8 Cloud runs the engine and its database; executors you run in your VPC dial out and run the steps placed on them.
- **Embedded**: you run the engine inside your product under a commercial licence.

---

## 1. Company and compliance

| Question | Answer |
|---|---|
| Legal entity | Oleksii Vasylenko Tecnologia LTDA (Brazil), licensor of the Orch8 engine. |
| Security contact | security@orch8.io |
| Third-party certifications (SOC 2, ISO 27001, PCI DSS, HIPAA) | None published. Ask for the current status: available on request. |
| External penetration test report | None published. Available on request. |
| Internal security review | A historical internal audit record is published in the engine repository (docs/SECURITY_AUDIT.md), including open design items. It is not an external audit. |
| Cyber insurance | Available on request. |
| Privacy policy | https://orch8.io/privacy |

## 2. Data handled

| Question | Answer |
|---|---|
| What customer data does the engine process? | Workflow definitions, instance context, step inputs and outputs, signals, credentials referenced by credentials:// identifiers, logs, and audit records. Content is whatever your workflows put there. |
| Self-hosted: data sent to Orch8.io | None. |
| Observability: data sent to Orch8 Cloud | Run metadata only: instance id, sequence name and version, state, timestamp, step id, duration, error kind, and sub-tenant id. No context, inputs, outputs, or credentials. |
| Hybrid: data processed by Orch8 Cloud | Orch8 Cloud runs the engine, so it stores sequence definitions and run state and processes the rendered params and context of every step; those are never sealed. Step outputs and error messages are reported to Cloud. Output fields an executor seals with BYOK (your bucket, data keys wrapped by your KMS key) are held in Cloud only as references and wrapped keys; error messages are never sealed. A step not placed on an executor that templates a BYOK-sealed field receives the reference, not the data. Credential values referenced by steps that are not placed live in Cloud's credential store. Executors also send identity, labels, region, the ids (not values) of their local credentials, and lease heartbeats. |
| Hybrid: data that stays in your VPC | Credential values for placed steps (read on the executor from `ORCH8_CREDENTIAL_<id>` or `ORCH8_CREDENTIALS_DIR`; Cloud stores only the `credentials://<id>` reference), network access to your internal systems, the side effects of placed steps, and the plaintext of output fields sealed by BYOK on the executor. Anything you put into workflow context, step params, or the Cloud engine's credential store is processed by Cloud. |
| Cloud (Starter, Pro): data stored by Orch8.io | Everything the hosted engine stores for your workflows, plus account and billing data. |
| Embedded: data sent to Orch8.io | None by default. The licence key is verified offline by the engine. |
| Data retention in Orch8 Cloud | Per plan: Dev 7 days, Starter 30 days, Pro 90 days, Observability 30 days, Hybrid 90 days, Enterprise 365 days by default. |
| Data location / region for Orch8 Cloud | Available on request. |
| Sub-processors for the hosted service | Supabase (account and application data), Vercel (website), Fly.io (managed compute), Stripe (billing), Google Analytics (website traffic). See the privacy policy; the list may change. |
| Data export on exit | Workflow definitions and data can be exported for self-hosting. |
| Data deletion | Deleting an instance removes its externalized payloads from the database through a foreign-key cascade. Objects in a BYOK bucket are not deleted by the engine; expire them with a bucket lifecycle rule. Account deletion procedure for Cloud: available on request. |

## 3. Encryption

| Question | Answer |
|---|---|
| Encryption at rest | With a 256-bit key configured, the engine encrypts credentials, workflow context, block outputs, worker parameters, signals, checkpoints, step logs, externalized state, and instance KV state with AES-256-GCM, bound to tenant and field. The server refuses to start without a key unless an explicit insecure-storage flag is passed. |
| Who holds the key | Self-hosted, Embedded: you. Cloud and Hybrid: Orch8.io holds the engine encryption key. With BYOK, externalized payloads are encrypted under data keys wrapped by your AWS KMS key, which you control. Key management details for Cloud: available on request. |
| Key rotation | Supported: new writes use the current key; a previous key is kept as a decryption fallback. |
| Encryption in transit | Managed-control and observability endpoints require HTTPS. The gRPC listener supports TLS with required client certificates (mTLS) and certificate-to-tenant identity mapping. HTTP TLS for self-hosted engines is terminated by your proxy or load balancer. |
| Customer-managed keys (KMS/HSM integration) | BYOK externalization (beta): payloads are written to your S3-compatible bucket with AES-256-GCM, and each data key is wrapped by your AWS KMS key. Revoking the key makes those payloads unreadable, including to Orch8. The engine encryption key itself is supplied through configuration or environment. |

## 4. Access control

| Question | Answer |
|---|---|
| API authentication | Capability-scoped API keys. |
| Tenant isolation | Tenant-scoped access; storage lookups carry tenant identity in their signatures. Sub-tenants are scoped inside a tenant. Scheduler ticks are not yet scoped by tenant (open item in the audit notes). |
| End-user SSO | The standalone engine has no browser login. Orch8 Cloud provides OIDC in front of the engine and records the user principal in audit metadata. |
| Browser and embedded access | Short-lived signed tokens (maximum one hour) scoped to one sub-tenant and a set of scopes; embed routes are disabled unless a secret is configured and are restricted to allowed origins. Browser runtimes never receive credentials. |
| Hybrid inbound access | None required. Executors connect outbound to claim placed steps and return results; Orch8 Cloud has no route into your network. |
| Orch8.io staff access to Cloud data | Available on request. |

## 5. Logging and monitoring

| Question | Answer |
|---|---|
| Audit trail | The engine keeps an append-only state-transition journal (audit_log) and records the provenance of remote worker outputs. |
| Metrics | Prometheus metrics, including queue depth by capability, region, and priority lane. |
| Fleet evidence | Draining a node records drain start, capability withdrawal, stop time, and handoff evidence; crashed nodes are recorded differently. |
| Log retention in Cloud | Follows plan retention above. |

## 6. Secure development

| Question | Answer |
|---|---|
| Source availability | The engine source is public under BUSL-1.1: https://github.com/orch8-io/engine |
| Dependency policy | cargo-deny runs in CI with advisory, licence, and source checks; dependencies are locked. |
| Security testing | A security test suite lives in the engine repository (tests/e2e/security); fuzz targets are included. |
| Release integrity | Release archives ship SHA-256 checksums; container images are built with provenance attestations. |
| Vulnerability disclosure | Report privately to security@orch8.io. We aim to acknowledge within 48 hours and give an initial assessment within seven days. |
| Known open issues | Published in docs/SECURITY_AUDIT.md: scheduler tenant scoping, a synchronous gRPC authentication path, DNS-rebinding window in outbound URL validation, expression/template depth limits, CDN endpoint HTTPS enforcement review. |

## 7. Availability and recovery

| Question | Answer |
|---|---|
| Self-hosted backups | Your responsibility. Deployment docs recommend automated PostgreSQL backups with tested restores, or SQLite with Litestream for single-node setups. |
| Cloud backups, RPO, RTO | Available on request. |
| Uptime SLA | Only under a written Enterprise agreement. |
| Crash behaviour | Workflow state is persisted before the next step is scheduled; instances held by a dead node are reclaimed. Activity execution is at-least-once; effect receipts and idempotency keys let you reconcile uncertain side effects. |
| Incident response and customer notification | Available on request. |

## 8. Licensing

| Question | Answer |
|---|---|
| Licence | BUSL-1.1 with an Additional Use Grant; each version converts to Apache 2.0 four years after release. |
| Embedding or hosting for third parties | Competing hosted or embedded offerings need a commercial licence (Embedded plan, OEM licence, or Enterprise). See https://orch8.io/license |