Architecture

This page describes the Envelope service architecture at the level of detail enterprise security and compliance reviewers need. For the verbatim cryptographic primitives, see the OpenAPI spec and the open-source SDK.

1. Request shape

Every envelope request is a single POST /v1/envelope with a body of { agent_id, decision } and an x-api-key header. The service returns an envelope object containing a SHA-256 hash of the canonical decision, hybrid signatures, and a chain anchor.

2. Cryptographic stack

• Classical signature: Ed25519 (RFC 8032), security level ~128 bits.
• Post-quantum signature: ML-DSA-65 (NIST FIPS 204, security level 3).
• Decision hash: SHA-256 over the canonical JSON encoding of { agent_id, decision }, prefixed sha256:.
• Hybrid verification: both signatures must verify for the envelope to be valid. Either alone is insufficient.

3. Per-tenant chain isolation (Pro and Enterprise)

Pro and Enterprise tenants get a tenant-scoped chain root. Every envelope chains to the previous envelope on that tenant's chain, not the global chain. Tampering with any past envelope breaks every subsequent link on the same tenant's chain — detectable by the public verifier. The global RAS root 40668c787c463ca5 anchors all tenant roots into a single audit substrate.

• Personal: shared chain, suitable for hobbyist and development workloads.
• Pro: per-tenant chain root, isolated WORM append-log.
• Enterprise: per-tenant chain root + dedicated verifier subdomain available on request + on-prem verifier appliance available under SOW.

4. Key custody

Signing keys are operated under FIPS-aligned procedures. Tenant-scoped API keys (ec_live_*) are generated server-side and never logged. Tenant keys can be rotated on demand via the entitlement worker; rotation does not invalidate previously issued envelopes (their signatures remain verifiable against the public key registry).

5. Public verifier

The verifier endpoint at https://chain.epochcoreqcs.com/v1/verify is open to any third party, requires no SDK, accepts a hash with or without the sha256: prefix, and returns the full chain walk including timestamps and signature material. The verifier is read-only; it cannot mutate envelope state.

6. Data handling

By default, only the SHA-256 of your decision payload is retained — not the plaintext. Envelope artifacts (hashes, signatures, chain anchors) are publicly verifiable by design. Optional payload retention is available under an Enterprise SOW.

7. Where it runs

The envelope worker, verifier worker, and entitlement worker run on Cloudflare Workers (global anycast). KV and D1 are managed by Cloudflare. We do not operate our own datacenters. See the DPA for full sub-processor disclosure.

8. Threat model

• Tamper of past envelope: chain break detectable in O(1) by verifier.
• Forge of envelope on an unrelated tenant chain: requires private key compromise; resistant to quantum adversaries via ML-DSA-65.
• Cross-tenant replay: prevented by per-tenant chain root binding the envelope to a specific tenant's anchor.
• Decision-substitution attack: prevented by the SHA-256 hash binding the envelope to the canonical decision payload.

9. Limits and quotas

Per-tier monthly seal quotas are enforced at the entitlement worker. API key rate-limits are configured per tenant; default 100 requests per second for Pro, 1000 rps for Enterprise. Overage above the monthly cap bills at a per-seal rate; the live rate is shown in your billing page at time of overage.