Security & Transparency Statement
Architecture Overview
Zen Mesh is webhook delivery infrastructure built on a zero-trust, outbound-only architecture. The platform is divided into three planes:
- Control plane (SaaS): Configuration, policy, and observability — never in the delivery path
- Data plane (edge): Event delivery and transformation — operates in customer regions
- Identity plane: mTLS, SPIFFE/SPIRE workload identity — secures all internal communication
Event delivery does not depend on SaaS availability. If the SaaS control plane is unavailable, existing configured flows continue delivering.
Cryptographic Controls
| Control | Scope | Status |
|---|---|---|
| TLS 1.2+ | All external-facing endpoints | ✅ Enforced — validated in local/sandbox |
| mTLS | Internal service-to-service | ✅ Enforced, fail-closed — validated in local/sandbox |
| SPIFFE/SPIRE | Workload identity for Zen-managed internal paths (control-plane and data-plane delivery) | ✅ Implemented — validated in local/sandbox |
| HMAC-SHA256 | Webhook payload verification with nonce | ✅ Implemented — validated in local/sandbox |
| Encryption at rest | Data stored in GCP Cloud Storage / GKE | ✅ Platform-managed keys |
Data Protection
- In transit: All external connections use TLS 1.2+. Internal connections within the Zen-managed boundary use mTLS with SPIFFE identity and fail closed. Customer delivery hop (egress→target) uses TLS by default with optional mTLS — see the security matrix for per-hop controls.
- At rest: All customer data stored in GCP is encrypted at rest using platform-managed encryption keys.
- Payload isolation: Customer webhook payloads are not sent to subprocessors.
- Retention: Webhook payloads retained up to 30 days for redelivery. Operational logs retained up to 90 days.
Access Control
- GCP IAM with least-privilege principles. No standing admin access to production.
- GitHub with branch protection, required reviews, and signed commits.
- Secrets encrypted at rest with age encryption. HMAC keys rotated via zen-lock.
- Application-layer tenant isolation scopes all queries to the current tenant.
Vulnerability Management
- Dependency scanning for known CVEs.
- Pre-commit secret scanning.
- All changes require pull request review.
- Penetration testing: not yet conducted.
Transparency Commitments
- All security claims are backed by evidence artifacts in the source repository.
- Non-claims are published alongside claims — see below.
- All policy documents are versioned and linked from the Version Index.
- The source repository is the source of truth for all claims.
- Security posture documents are available via llms.txt.
Non-Claims
- No SOC 2, ISO 27001, PCI DSS, HIPAA, or FedRAMP certification is claimed
- No independent penetration test has been completed
- No bug bounty program is in place
- No SLA or on-call commitment is made for V1 Free/Pro trial
- No data protection authority approval has been obtained
- Self-service data deletion/export is not yet available (manual support path exists)
- Zen Mesh is not an anomaly detection, API catalog, or general runtime API security platform
- No global SSRF safety is claimed — SSRF coverage is validated for scoped proxy mode (PROVEN_SANDBOX); SaaS-wide and direct-mode hardening are V1-live prerequisites
- No compliance certification (SOC 2 / ISO 27001 / HIPAA / PCI / FedRAMP) is claimed
- No SSRF elimination — validated attack coverage is limited to documented attack classes and scopes
- No public launch-ready status — remaining cloud-gated checks and provider E2E validation not yet complete
- Certificate pinning / compromised-CA MITM is not claimed — standard TLS only for V1; cert pinning is a V1.1 candidate
- Subdomain takeover protection is not validated — requires public DNS lifecycle (CLOUD_GATED)
- Twilio is not V1-complete — downstream form-urlencoded routing is PARTIAL
- MCP V1 RW parity across MCP/CLI/API/UI is not complete — a V1 prerequisite, not yet proven. CLI parity (`zen mcp status` / `zen mcp enable` / `zen mcp disable`) is MISSING — V1-blocking