The reason teams build internal versions of products like this is that they don't trust the security posture of the available ones. We took that seriously. This page describes the primitives in enough detail that your security engineer can decide whether to trust the design — not just the marketing.
| X25519 | ECDH between desktop and agent at enrollment; between operator hardware keys and the relay at admin login. Derives the long-term shared secret. |
| HKDF-SHA-256 | Expands ECDH outputs into AEAD session keys, with a deterministic salt over the install-id pair. |
| ChaCha20-Poly1305 | AEAD on every envelope between desktop and agent. The relay never holds the key; payloads are opaque to it. |
| Ed25519 | Signatures: install identity, audit chain anchors, release manifests, support-mode consent tokens. |
| Argon2id | Tenant passphrase → SQLCipher key. Configured for ~1 second on a modern laptop, 64 MiB memory cost. |
| SQLCipher (AES-GCM 256) | Per-tenant database at rest. Cross-tenant reads are not just disallowed; the bytes on disk are mutually unintelligible. |
No custom cryptography. Every primitive is a thin wrapper over ring, libsodium, or PyNaCl.
An attacker who fully owns the relay sees metadata only: which install talks to which agent, timing, size. Payload contents are E2EE between desktop and agent. The audit chain is signed externally; tampering breaks the chain visibly.
Tenant data is sealed under Argon2id. OS disk encryption is assumed. The install identity key sits in the OS keychain protected by OS login. Revocation list is pushed from the relay within 60 seconds of next connection.
Useless without the laptop session. Loss procedure: cold-key signed revocation of the lost key fingerprint, with a second enrolled key as the backup path. We require two enrolled keys per operator before granting admin access.
The agent's surface is narrow: it executes signed commands and refuses everything else. Replacement of the agent binary triggers quarantine on the next reconnect. Destructive operations require explicit approval gates regardless of who signed.
Per-tenant SQLCipher with separate passphrase means an operator who has access to tenant A cannot read tenant B. Process-level isolation between tenant engines is on the roadmap; in-process isolation is the v1 posture.
All server output is wrapped in <server-output> blocks before being passed to Claude. The system prompt treats those blocks as data, never instructions. Destructive commands always require a human approval gate that Claude cannot bypass.
Release manifests are dual-signed (cold key + online build key). Desktop and agent verify both signatures and refuse to start with one. The cold key lives offline.
Every envelope carries a strictly-monotonic counter scoped to the install pair, plus a 60-second timestamp window enforced at both ends. Replays are rejected silently.
Enterprise Orchestra is not currently certified to any specific scheme; we're a small team and certification is expensive theatre relative to actually-designed-correctly. What we have instead:
All processing is done either on your operator laptop or on agents under your control. We process metadata only on the relay. Per-tenant data export and deletion are first-class operations.
Every state transition exportable as signed JSON. Hash-chained so partial tampering is visible. Pairs with your existing SIEM pipeline.
Standard EU data processing addendum, signed on request. EU-only data residency on the Firm tier.
Not certified ourselves; the underlying primitives (relay infrastructure, object storage for backups) sit on providers that are. On the Firm tier we can deploy GTM Command to your environment, removing us from the data path entirely.
We'll do a paired call with your team. You bring the threat model you'd run an internal build against. We'll walk through where we've made each defense.
Schedule a security review