Webhook API Protection for Private Infrastructure
Least-privilege isolation, outbound-only delivery with cryptographic evidence and control-plane isolation.
Transport and identity controls are mapped per hop — not a vague "zero-trust everywhere" claim. The data-plane path from zen-ingester ↔ zen-egress is protected with mTLS, SPIFFE/SPIRE workload identity, and HMAC and is non-negotiable.
Designed so the control plane does not need to see customer payloads. Tamper-evident delivery evidence. Reduces inbound exposure and avoids requiring public webhook receivers inside private networks.
What Zen Mesh Protects
Scoped to the webhook delivery path — validated in local/sandbox where evidence exists.
ValidateTargetURL + SSRFDialContext); scoped ServiceRef-only proxying for Private Edge Delivery relay mode; direct-mode egress target validation for Private Edge Delivery direct mode; redirect-chain restrictions on webhook dispatch path; DNS rebinding protection at dial time Partially validated. Proxy-mode ServiceRef path validated in local/mock (H569/H574). Central SSRF library tested (409-line negative test suite). BFF internal client and Private Edge Delivery relay transport hardened with SSRFDialContext. SaaS-wide API dispatch, provider dispatchers (Splunk/Grafana/PagerDuty/Teams/Git), and most shared client libraries are not yet validated. See non-claims. Security Matrix
Source of truth for TLS, mTLS, and HMAC by flow. Customer-managed final hops are secure-by-default and configurable — not the same as the Zen-managed ingester ↔ egress delivery path.
Security boundaries (read first)
| Boundary | Protection |
|---|---|
| Webhook Source → Ingester | HTTPS plus provider HMAC/signature verification where supported and configured (Stripe, GitHub, Twilio, Shopify, etc.). |
| Ingester ↔ Egress | mTLS + SPIFFE/SPIRE workload identity + HMAC/message authentication on the data-plane delivery path — mandatory and non-negotiable (not optional, not “where applicable”). |
| Agent / Lock / SaaS control paths | mTLS + HMAC as required by the matrix below (enrollment, config sync, control-plane APIs). |
| Egress → Customer target | Secure-by-default and customer-configurable. Do not assume customer-managed target mTLS/HMAC unless your deployment enables and evidences it. |
Narrative pages are not runtime proof. See claim maturity and non-claims on the docs host.
mTLS + HMAC: Defense in Depth (by boundary)
Controls apply per hop in the matrix — not as an undifferentiated “everywhere” stack.
mTLS (Mutual TLS)
Both client and server verify each other's certificates. Connection is only established if both parties present valid certificates signed by the trusted CA.
- Ingester ↔ Egress: Protected with mTLS/SPIFFE/HMAC and is non-negotiable on the data-plane delivery path (fail-closed; not optional).
- Agent ↔ SaaS: mTLS + HMAC required per matrix. SPIFFE/SPIRE where implemented on control paths; fuller workload-identity rollout is planned — not a production-live certification claim.
- BFF ↔ Backend: Certificate-based service authentication.
HMAC-SHA256
Message authentication codes verify the payload hasn't been tampered with and originates from a trusted source.
- Duplicate detection: Idempotency/nonce handling helps detect and limit duplicate delivery — not replay-proof delivery.
- Per-Cluster Keys: HKDF-derived keys stored securely per tenant.
- Header Verification: X-Zen-Signature header validation on all ingress.
Tenant Isolation
Multiple layers of isolation ensure your data stays isolated from other tenants.
Application-Layer Isolation
Primary isolation at the application level. All queries are scoped to the current tenant via context setting.
Application-Layer Isolation
Application-layer tenant isolation tests validate that tenant-scoped sessions and API keys cannot read or mutate another tenant's resources by manipulating IDs.
Encryption at Rest
All sensitive data encrypted at rest. Zen Mesh uses ZenLock for encrypted secret custody, distribution, and audit support. Credential rotation is owned by the relevant lifecycle — HMAC, TLS/certificates, JWKs, and future SVID flows — with ZenLock protecting and distributing the underlying secret material where applicable.
Negative-Test-Proven Security Controls
Each control below has passing negative tests proving the attack is prevented.
API-Key Enumeration Resistance
API-key validation uses normalized failures, protected storage, and throttling or audit controls to resist brute-force and enumeration attempts.
Draft/Apply Race Protection
Draft/apply concurrency tests validate that simultaneous apply attempts do not double-commit changes.
Tenant Isolation (Application-Layer)
Application-layer tenant isolation tests validate that tenant-scoped sessions and API keys cannot read or mutate another tenant's resources by manipulating IDs.
Four-Surface Permission Parity
Permission tests validate that disabled UI, API, CLI, and MCP surfaces cannot bypass shared authorization policy.
MCP Permission Boundary
MCP permission tests validate read-only, draft, apply, and tenant boundaries for tool-based actions. Proof level: handler-level negative tests.
ZenLock — Secrets Management
Zen Mesh's secret custody and controlled distribution solution. Centralized encrypted custody and controlled distribution for secret material used by Zen Mesh components, with rotation support integrated through the owning credential lifecycle.
Encrypted Storage
All secrets encrypted at rest using industry-standard encryption. Keys are never stored in plaintext.
Rotation Support
Rotation workflows can use ZenLock to protect and distribute new secret material. Rollout, canary, and rollback behavior belongs to the owning credential or deployment workflow.
Centralized Distribution
Secrets securely distributed to all components. One update propagates everywhere.
Audit Trail
Every secret access logged with audit metadata.
Certificate Lifecycle Management
Automated certificate rotation via cert-manager with canary deployment on supported workloads. HMAC, TLS/certificate, and JWK/JWKS rotation lifecycles are implemented. File-based X.509 SVID lifecycle is implemented; full SPIRE Workload API SVID rotation is post-V1.
Canary Deployment
New certificates deployed to a subset of nodes first.
Health Check
System validates new certificates with automated probes.
Full Rollout
If healthy, certificates propagate to all nodes.
Auto-Rollback
If issues detected, system auto-rollbacks and notifies.
Comprehensive Audit Logging
Immutable audit trail with tamper detection for compliance and forensics.
Hash-Chain Verification
Audit entries include timestamps and actor context for review.
Event Tracking
All authentication, authorization, and data access events logged with full context.
Correlation IDs
Full flow correlation from webhook source through to delivery for debugging.
Retention Policies
Configurable retention with support for long-term archival.
Meets webhooks.fyi Best Practices
Built on infrastructure security standards that exceed typical webhook providers.
HMAC-SHA256 Verification
Signature verification for supported provider templates. GitHub, Stripe, Twilio, Shopify, and more supported.
mTLS + SPIFFE/SPIRE
Mutual TLS and SPIFFE/SPIRE are part of the Zen Mesh internal security model and are being validated path-by-path before production-live claims. Stronger than typical HMAC-only.
Dead Letter Queue
Failed events stored for replay. Learn more about DLQ →
Webhook Replay
Replay events from the DLQ or delivery history. Learn more →
Idempotency Controls
At-least-once delivery with idempotency handling. Learn more →
Fan-Out Delivery
Deliver events to multiple destinations. Learn more →
IP Allowlisting
Restrict delivery sources by IP. Learn more →
Header Validation
Verify webhook signatures for Stripe, GitHub, Twilio, Shopify, and more. Learn more →
Cryptographic Enrollment
HMAC-based enrollment with X.509 SVID identity. Learn more →
Detailed documentation: Delivery Capabilities · Security Controls
S3 Log Export
Export delivery logs to your own S3 bucket. Customer-owned infrastructure, customer-managed retention.
Pro: S3 log export included
Export delivery log records to your customer-owned S3 bucket. Logs only — delivery metadata, status, timestamps, and error categories.
Customer-owned bucket and keys
You bring your own S3 bucket, credentials, and keys. Zen Mesh writes log objects to your configured bucket. You retain full ownership and control.
Customer-managed retention
You manage bucket lifecycle rules, retention, replication, access policies, and deletion in your own S3 account. Zen Mesh does not manage your bucket lifecycle.
Business+: payload export planned
Raw payload fan-out and S3 Object Lock are planned for Business+. Not included in Pro.
Pro S3 log export does not export raw webhook payloads. Customers manage bucket lifecycle rules, retention, replication, access policies, and deletion.
What Zen Mesh Does NOT Protect
Zen Mesh is designed for webhook delivery-path protection. The following are explicit non-claims — do not rely on Zen Mesh for these capabilities.
API Inventory / API Discovery
Not claimed. Zen Mesh does not catalogue or discover APIs within your infrastructure.
Anomaly Detection
Not claimed. Zen Mesh does not detect anomalous API behaviour or malicious payload patterns.
Bot Mitigation
Not claimed. Zen Mesh does not distinguish human from automated traffic.
Runtime Threat Detection
Not claimed. Zen Mesh does not inspect payload content for threats or scan for vulnerabilities.
Production Readiness
Not claimed. Current evidence is local/sandbox validation. Production readiness requires additional hardening and cloud deployment proof.
24-Hour Survival (SaaS Unavailable)
Not claimed. Post-V1 hardening target.
SPIRE SVID Rotation
Not claimed. V1 uses LocalCA projected identity (proven). Full SPIRE Workload API SVID rotation is POST-V1 / PRE-PROD-LIVE hardening.
Stripe Cloud E2E Proof
Historical proof exists on GKE cloud trial. Current revalidation AUTHORIZATION_BLOCKED — GKE trial expired, GCP/GKE auth required. NOT_CURRENTLY_VALIDATED.
Exactly-Once Delivery
Not claimed. At-least-once with idempotency is the delivery model.
General API Security Platform
Not claimed. Zen Mesh secures the webhook delivery path only — not the full API security lifecycle.
SSRF (SaaS-wide and direct-mode)
Not yet claimed. SSRF coverage is partially validated for scoped proxy mode (Private Edge Delivery relay) and Private Edge Delivery direct webhook dispatch path. SaaS-wide API dispatch, webhook target URL creation, provider dispatchers, and most shared client libraries are not yet validated. Central SSRF validation library exists; adoption across all surfaces is a V1-live prerequisite (GAP-SSRF-SAAS-DISPATCH).
Header / Forwarded-Identity Spoofing
Not claimed. Trust boundary for X-Forwarded-* / identity headers has not been validated. Externally supplied forwarded headers may be able to spoof tenant/user/actor identity.
Redirect-Chain Abuse
Partially validated. Webhook dispatch path uses NoRedirects() and SafeRedirects() with bounded chains and re-validation. Most other outbound HTTP clients follow redirects by default without validation.
Parser / Payload Bombs
Not claimed. No size/depth/time limits for payload parsing paths have been validated. Oversized, deeply nested, or compressed payloads may cause resource exhaustion.
Rate-Limit Bypass
Not claimed. Tenant/user/API-key rate-limit key binding has not been validated across alternate surfaces (API, UI, MCP, CLI).
Timing Side-Channels
Not claimed. Constant-time comparison for HMAC/signature checks has not been validated. Broad timing side-channel resistance is not asserted.
See the full non-claims registry and claim maturity for authoritative status. For the rationale behind publishing non-claims, see the blog on non-claims.
Questions about security?
Our team is here to help you understand our security architecture.
Evidence and verification: Security Controls · Trust Lifecycle Evidence · Runtime Evidence · IP Allowlisting · Header Validation · Cryptographic Enrollment · Validation Map · AI Evidence Manifest · Non-Claims · Security Validation Matrix · Agent→SaaS mTLS Details · ZenLock & Credential Lifecycle
Validation status and evidence links are tracked in the trust lifecycle evidence docs. Public launch commitments are validated through the prod-live gate before production access. See non-claims for statements the product does not make.
Email security team