New: Synadia Insights, NATS-native observability. Catch issues early, understand why, and fix faster.
WAF for NATS

Auth checks who. Synadia Protect checks what.

Synadia Protect inspects every NATS connection and message, blocks what your rules prohibit, and provides the evidence your security and compliance teams need.

Start free trialRead the docs

gw-prod-euwest1

fleet: prod · 2 instances

Enforcing

CONNECTIONS

1.4K

ALLOW/S

12.6K

DENY/S

38

SUSPEND/S

6

OverviewBundlesConnectionsAudit
ACTIVE BUNDLESsigned
baseline-deny@2.4.0
port: clientsrules: 12active
pii-payload@1.7.1
port: clientsrules: 8active
leafnode-cidr@1.0.3
port: leafnodesrules: 4active
office-hours@0.9.0
port: clientsrules: 2inactive
UNMATCHED TRAFFICdeny

Default-deny posture · all bundles signature-verified

14:22:01CONNECT · ip=10.4.18.22 · no rule matchedDENY

Built for enterprises and regulated industries that can't get NATS security wrong.

Security Engineers

Get visibility, enforcement, and an audit trail for every NATS connection or message, without being a NATS-protocol expert.

Platform and App Teams

No more exception tickets. No more grandfathered apps. Ship NATS with policy already in place.

Compliance & Risk

Continuous evidence that controls are enforced - straight to your SIEM.

Works with any OSS NATS deployment - no Synadia Platform required.
Drop-in proxy. No application changes.
Talk to the teamSee how it works

Everything you need to put policy in front of NATS

A transparent proxy that inspects every connection and message. Deploy it between your clients (or leaf nodes) and your NATS cluster - no application changes required.

In-line policy enforcement

Every CONNECT, PUB, and MSG is evaluated against your active rules. Each rule resolves to one of five actions: allow, deny, suspend, log, or error - based on subject, header, payload, source IP, time of day, JWT claims, and more.

policy evaluationdefault-deny
-idle
header
payload
subject
time

recent

13:50:05Pevents.user.updateALLOW
13:50:01Pmetrics.app.errorsDENY
13:49:57Pinventory.price.updateDENY
13:49:53Cip=203.0.113.42SUSPEND

Built-in library plus custom rules

Activate built-in rules for CIDR, headers, payload regex, JWT, and time windows with config alone. Write custom rules in the Expr language with full access to connection context and message contents.

rule.yaml
name: <string> # unique within the bundle
description: <string> # optional
 
facts: # connection-level filters
  - connection_kind: client # required: client or leaf
 
conditions: # per-message filters
  - rule_type: connect # required: connect or message
 
default: allow # action when no rule body matches
 
rules: # one or more rule bodies
  - expression: <expr>
    success: deny # action when expression returns true
    fail: allow # action when expression returns false
    message: "audit log text" # shown in audit logs on deny/suspend

Signed, versioned bundles

Package rules into signed bundles. Install, activate, upgrade, and roll back without restarting the gateway. Trust only bundles signed by identities you control.

baseline-denysigned
1.2.0inactive
1.3.0inactive
1.4.0active · clients
1.5.0-rc.1inactive

Activate, upgrade, or roll back without restarting the gateway.

View docs

SIEM-ready audit logging

Every non-allow decision, connection event, and management action emits an audit event. Stream as text, JSON, or CEF - to local files, stdout, or straight to NATS for your SIEM pipeline.

JSON→ file · stdout · NATS

{"action":"deny","port":"clients","cuuid":"7Yep…","reason":"payload regex"}

CEF→ file · stdout · NATS

CEF:0|Synadia|Protect|1|POLICY|Protect Policy Action|8|act=deny dst=…

TEXT→ file · stdout · NATS

time=2026-04-07 type=policy.action action=deny port=clients reason=…

See Protect in action

CIDR

Restrict by source IP

Allow or deny clients and leaf nodes by IP range - IPv4 and IPv6.

JWT

Trust external JWT signers

Accept connections whose JWT is signed by a key you trust - signature only, no full IdP integration needed.

Payload

Block sensitive content

Match payloads against regex by subject pattern - PII, secrets, tokens.

Header

Require tenant headers

Enforce that messages carry the headers your platform contract expects.

Time

Office-hours access

Cron-scheduled allow or deny - perfect for change-window enforcement.

Subject

Block wildcard subjects

Reject publishes with wildcard subjects - with carve-outs for JetStream consumer creates.

Built-in rule library

The most common policies, configured not coded

Activate built-in rules with a few lines of YAML - no expression writing required. Mix and match across CIDR filtering, header inspection, payload matching, time windows, and JWT verification.

Browse the rule library

Where teams use Protect

Common patterns, enforced from day one

Edge & leaf nodes

Protect leaf nodes outside your cloud perimeter

Deploy Protect in front of every leaf-node ingress. Inspect headers, CIDR-restrict by source, and enforce JWT signing - without trusting the network the leaf rides on.

Tenant isolation

Enforce platform contracts on every publish

Require X-Tenant headers, scope each tenant to their subject space, and reject any publish that violates platform conventions - even from a misbehaving service.

Data protection

Stop secrets and PII from leaving the building

Run payload-regex rules in the message path. Block anything matching secret, password, or PII patterns before it reaches a stream you can never fully purge.

Drops into your existing NATS

A transparent proxy that leaves NATS untouched

Protect speaks the NATS protocol. Point relevant clients (or leaf nodes) at the Protect port instead of your cluster, and Protect forwards allowed traffic to the backend — same protocol, same semantics, just policy in the middle.

  • Works with any OSS NATS deployment
  • Run clients and leaf nodes on separate ports, each with its own policy
  • Default-deny — unmatched traffic never reaches the backend
live trafficport: clients · leafnodes
sources
leaf.east
client.42
sdk.go
+12 more
synadia protect
rules12 active
bundlev1.4.0
evaluating12,692
backend
NATS cluster (5 nodes)

ALLOW

62/s

SUSPEND

0/s

DENY

1/s

recent (subset)

13:50:05Pevents.user.updateALLOW
13:50:02Pmetrics.app.errorsDENY
13:49:58Pinventory.price.updateDENY
13:49:54Cip=203.0.113.42SUSPEND
13:49:50Cleaf=untrusted-edgeDENY
13:49:46Mpayments.card.chargeLOG
Default-deny: unmatched traffic is rejected before reaching the backend.

A note from the team

Stop asking for security exceptions to ship NATS

In many large enterprises we've worked with, app teams who want to use NATS hit the same wall: there's no firewall for it, so security has to grant an exception. That slows everything down — and leaves real gaps once NATS is in production.

Protect is the missing piece. It puts security teams back in the loop, with policy enforcement and audit trails they can drive, independent of infra or app teams.

Same NATS your team already loves. Now with the controls your security team needs.

Synadia

The Synadia Team

Creators of NATS

Try Protect free for 14 days

14 day free trialTalk to the team

Drop-in proxy for any OSS NATS deployment. No application changes, no Synadia Platform required.

How to get started

Sign up for a trial

Submit the form to request your free 14-day trial.

Get your trial license

Receive an email with a download link and your trial license JWT.

Install and configure

Install the Protect binary and run `protect setup` to scaffold a config and keys.

Deploy in front of NATS

Start the gateway with your trial license JWT and route clients or leaf nodes through it.

Explore the docs

Review the rule library, bundles, and audit logging.

View docs

After the trial, Protect is available on an annual contract — $25K/yr for 2 instances.

Frequently asked questions

What is Synadia Protect?
Synadia Protect is a security gateway for NATS - effectively a WAF for NATS traffic. It sits in front of your NATS cluster, inspects every connection and message, and enforces policies that allow, deny, or suspend traffic. It's designed for security teams who need policy enforcement and an auditable trail on NATS traffic.
How is Protect different from NATS authentication and authorization?
NATS auth answers 'who can connect and what subjects can they touch'. Protect runs in the message path and answers richer questions: is this payload OK to forward, does this header match the platform contract, is the source IP in the allowed range, is this a maintenance window? Protect complements NATS auth - it doesn't replace it.
Does Protect require Synadia Platform?
No. Protect is a standalone product. It works in front of any OSS NATS deployment - your own self-managed clusters, Synadia Platform, or anything in between.
Who is Protect built for?
Larger enterprises and teams in regulated industries - anywhere security teams have historically had to grant exceptions because there was no firewall for NATS. It is also a strong fit for deployments with many clients or leaf nodes living outside your cloud security perimeter.
What can Protect do when a rule matches?
Each rule resolves to one of five actions: allow the traffic, deny it (and close the connection), error (same as deny, recorded with error metrics so you can alert on rule failures), suspend it (keep the client connected but drop the backend connection), or log the protocol for forensic capture. Suspending is especially useful for clients and leaf nodes that would otherwise reconnect immediately on disconnect.
Are there built-in rules, or do we have to write everything ourselves?
Both. Protect ships with a built-in rule library covering the most common policies (CIDR, header, payload regex, JWT signers, time windows, JetStream consumer filters, subject wildcards, and more) - those activate with a few lines of YAML. For anything custom, write rules in the Expr language with full access to connection context, headers, and payloads.
How do we deploy and roll back policy changes?
Rules are packaged into versioned bundles. You install a bundle, activate it on a port, and Protect starts evaluating new traffic against it - no restart required. Upgrades and rollbacks are also live. Bundles can be signed with NKeys, and the gateway will only accept bundles from identities you trust, so policy artifacts cannot be tampered with in transit.
How does Protect integrate with our SIEM?
Every non-allow decision, connection event, and management action emits an audit event. Multiple processors can run side by side, each with its own format (text, JSON, or CEF) and event filter. Events can be written to files, stdout, or published to NATS - the latter is the typical path into a SIEM collector.
Can we run multiple Protect instances? How do we manage them?
Yes. A single Protect instance runs as a standalone gateway. For larger deployments, run a configuration server that centralizes bundle and trace-profile management for many gateways. Managed gateways mirror configuration over NATS, forward audit events, and publish heartbeats - and continue enforcing their last-known policy if the config server is unreachable.
What's the performance overhead?
Protect sits in the data path, so it adds cost - but the cost is bounded and measurable. Rule evaluation is pre-filtered per connection so most rules never touch most messages; function-level caching avoids redundant work; the gateway uses the same protocol parsers as `nats-server`. Every rule evaluation emits a Prometheus latency metric, so you can measure the impact on your own workload. For high-throughput deployments, scale horizontally behind a load balancer - instances are independent, no consensus required.
Does Protect work with leaf nodes?
Yes - and it is one of the strongest fits for Protect. A Protect port can proxy NATS leaf-node connections, letting you enforce policy at the edge of your security perimeter even when the leaf rides on a network you do not fully control.
Where can I read the technical docs?
Full product documentation, including configuration reference, the rule language, bundle lifecycle, audit logging, and the configuration server, lives at docs.synadia.com/protect.

Configurable security policy. In front of your NATS traffic.

Start 14-day free trialWork with our experts

Standalone product - works with any OSS NATS deployment. No Synadia Platform required.

Synadia SOC2 Compliant
Products Synadia CloudSynadia PlatformSynadia Deploy for KubernetesSynadia InsightsSynadia Protect
Resources BlogDocsVideosSynadia EducationLiving on the EdgeNATS vs KafkaNATS vs Kinesis
Company AboutBrandCustomersContactCareersPress
Legal TermsPrivacyDPASubprocessorsSupport LifecycleTrust Center
Get the NATS Newsletter

News and content from across the community
© 2026 Synadia Communications, Inc.
Cancel