Zekt Shield

Back to Zekt

Add-on — Zero-Knowledge Encryption for your workflow payloads

Add-On

Your payload is yours —
even Zekt can’t read it

Zero-Knowledge Encryption ensures that the event broker never has access to your message content. Compliant by design for regulated industries.

Starting at $4 / repo / month + usage

Requires Zekt Core

What Zekt Shield gives you

Click any card to explore each security capability

Zero-Knowledge Encryption
Zekt never sees your payload content
click to flip
Zero-Knowledge Encryption
Payloads are encrypted client-side before being sent to Zekt. The broker routes an opaque blob. Only the consumer — with the correct key — can decrypt.
  • Encryption happens in the provider's workflow, not in Zekt
  • Zekt stores only ciphertext, never plaintext
  • Key material never transits through Zekt infrastructure
click to flip back
Bring Your Own Key
You control key generation and rotation
click to flip
Bring Your Own Key (BYOK)
No key escrow. You generate, store, and rotate encryption keys. Zekt never holds them.
  • Store keys in your own HSM, Azure Key Vault, AWS KMS, or GitHub Secrets
  • Rotate keys on your schedule — no Zekt involvement required
  • Revoke access by retiring keys: Zekt-held ciphertext becomes permanently unreadable
click to flip back
Secure Transmission
End-to-end between provider and consumer
click to flip
Secure Transmission
ZKE is applied at the provider before dispatch and decrypted only at the consumer on receipt. TLS is an additional layer on top.
  • Transport TLS (HTTPS) for in-flight protection
  • ZKE for at-rest protection in Zekt storage
  • Two independent security layers — neither alone is sufficient
click to flip back
Compliance Ready
GDPR, HIPAA, SOC 2 Type II patterns
click to flip
Compliance Ready
ZKE satisfies requirements where the event broker must not have access to message content — a common mandate in regulated sectors.

Great when having to solve collaboration but staying compliant with GDPR, HIPAA, SOC 2 & DORA regulatory demands

click to flip back
Audit Trail Without Payload
Traceability without compromising confidentiality
click to flip
Audit Trail Without Payload
Delivery metadata remains fully auditable even with ZKE enabled. Only the payload body is opaque to Zekt.
  • Correlation ID, timestamp, consumer, delivery status — all visible
  • Payload hash stored for integrity verification without decryption
  • Audit records can be exported for compliance reporting
click to flip back
Redaction Guard
Sensitive fields never leave the source in plaintext
click to flip
Redaction Guard
Define which payload fields are sensitive at the provider. Redaction Guard ensures those fields are masked or omitted before the event ever reaches Zekt.
  • Field-level redaction rules configured in the provider workflow
  • Redacted fields are replaced with a placeholder — never stored by Zekt
  • Consumers receive only the fields they are authorised to see
click to flip back

When to use Zekt Shield

  • Workflows that carry PII, credentials, financial data, or IP-sensitive content in the payload.
  • Regulated industries (finance, healthcare, defense) where the event broker must not have access to payload content.
  • Any provider who needs provable, cryptographic non-access guarantees for their consumers.
  • Scenarios where key revocation must immediately and permanently block access to historical payloads.

Combinations

Works well with

  • Core + Shield — Minimum viable secure setup. Encrypted dispatch from day one.
  • Core + Shield + Chainlink — Encrypted multi-hop pipelines. Each hop routes ciphertext.
  • Core + Shield + Analytics — Full event visibility, but Time Travel is disabled for encrypted connections (see above).
  • Core + Shield + Zekt Action — Attach an encrypted structured message. Only the consumer with the key reads it.

Constraint to know

  • Shield + Analytics Time Travel — Time Travel is disabled for ZKE connections. This is a deliberate architectural constraint, not a bug.

Next up

Explore Zekt Chainlink

Build multi-hop event pipelines — one repo, both provider and consumer roles