7-layer defense. Zero tolerance. Privacy by construction.
Every layer below is live across the full relay fleet. Each one is designed so that we can't see what we shouldn't, and so that bad actors can't damage the IP reputation of the customers sitting next to them.
Nobody can profile your container's DNS lookups
Every DNS query from a customer container is sent through oblivious DNS forwarding. The query content is encrypted before it ever leaves the relay. The relay sees who is asking; the upstream resolver sees what is being asked. Neither party can link the two.
- ✓ Customer benefit: nobody — not even us — can profile your container's DNS lookups
- ✓ What the upstream resolver sees: query content, but not which customer asked
- ✓ What Sidecar sees: which customer asked, but not the query content
- ✓ What we DON'T see: the contents of any DNS query you make. Period.
Two relays, two independent keys, two jurisdictions
Add the label sidecar.relay-mode: onion to any container and your traffic is wrapped in two independent WireGuard tunnels and forwarded through two relays in different regions before reaching the public internet. Each hop uses an independently-derived post-quantum encryption key — neither relay alone holds enough key material to read your traffic.
- ✓ Customer benefit: split-key confidentiality and multi-jurisdiction routing
- ✓ Per-container opt-in via Docker label — pay only for what you use
- ✓ Both hops are protected by post-quantum encryption (classical + lattice)
- ✓ What we DON'T see: any single relay seeing the cleartext of a customer payload
Containers can't accidentally talk to fresh phishing infra
Newly-registered domains (≤ 7 days old) account for a disproportionate share of phishing, malware, and command-and-control activity. Sidecar maintains a 2.7M-domain rolling blocklist refreshed hourly. Egress DNS resolution for blocked domains fails at the ODoH layer — the container never gets an IP for the bad name, so the connection never even begins.
- ✓ Customer benefit: a compromised dependency can't reach its fresh C2
- ✓ Default-ON for Free, Spark, and Launch tiers
- ✓ Toggleable per-peer for Pulse and above (some use cases legitimately need newly-registered domains)
- ✓ What we DON'T see: the contents of any allowed query — only an aggregate pass/block counter
Verified bad actors evicted before they can damage your reputation
Known-bad URLs and IPs from the automated CSAM hash-list feed are continuously pushed into per-relay automated egress firewall blocked sets. When a signed report identifies an offending peer, the relay revokes the token, removes the peer from the in-kernel safety telemetry allowed-peers map, and drops it from the routing fabric — all in under 60 seconds. Production measurement: 481 ms median.
- ✓ Customer benefit: bad actors on the network can't damage your IP reputation
- ✓ < 60 s SLA from verified report → peer disabled (measured at 481 ms in production)
- ✓ Auto-drafted CyberTipline report on every takedown (18 U.S.C. § 2258A)
- ✓ What we DON'T see: the contents of any tunnelled traffic — we only act on signed external reports
Zero CSAM tolerance, enforced where we have visibility
For any images or videos that arrive at Sidecar infrastructure in cleartext (avatar uploads on the marketing site, support attachments, abuse-report attachments) we apply AI-assisted image safety review and match against the automated CSAM hash-list feed. This is never applied to tunnel traffic.
- ✓ Customer benefit: zero CSAM tolerance enforced where we have visibility
- ✓ Runs in a sandboxed sidecar daemon — isolated from the relay control plane
- ✓ Integrated with the automated CSAM hash-list feed
- ✓ What we DON'T see: anything inside an encrypted WireGuard tunnel — review runs only on content we directly hold
Noisy abusers caught by behaviour, not signatures
Behavioral safety detection runs hourly over per-peer in-kernel safety telemetry: packet-size histograms, connection-rate envelopes, destination-fanout entropy. Catches cryptojacking, low-and-slow C2 beaconing, novel botnet patterns — the things signature detection misses. A two-tick debounce keeps the false-positive rate at approximately 0.1%, so legitimate workloads aren't flagged.
- ✓ Customer benefit: noisy abusers get caught before they affect your latency
- ✓ Streaming model — adapts to normal traffic, flags drift
- ✓ ~0.1% false-positive rate after two-tick debounce
- ✓ What we DON'T see: payload bytes — features are computed from packet metadata only
Faster legitimate appeals. Humans still make every decision.
A centralised open-weights LLM hosted on Sidecar infrastructure (no external API calls, ever) extracts the peer IP, the violation category, and a severity score from incoming abuse emails. Each relay's abuse handler forwards reports to this endpoint over HTTPS. It pre-stages a revoke action for a human operator to confirm or reject. The separation between the model that reads untrusted input and the process that can take action provides prompt-injection defense.
- ✓ Customer benefit: faster legitimate appeals, fewer human latency-spikes
- ✓ No autonomous AI revocations — humans confirm every enforcement action
- ✓ Self-hosted — no third-party API calls, no model-provider sees your data
- ✓ What we DON'T see: the model never reads tunnel traffic — only inbound abuse emails
Found a vulnerability? Report it — we take it seriously.
Sidecar operates a responsible disclosure program. The scope covers the deployed service (all relay endpoints, the control-plane API, the web application) and the published agent binary (ghcr.io/sidecar-network/agent). Source code is not in scope — researchers analyse the binary we ship and the service we run.
What we want to hear about
- ✓ Authentication or session vulnerabilities on the control-plane API (`:8443`)
- ✓ Peer isolation bypass — traffic leaking between tenants inside the relay data plane
- ✓ WireGuard peer impersonation or key-material exposure
- ✓ Agent binary integrity bypass or privilege escalation from container context
- ✓ Billing or subscription manipulation that affects charges to other accounts
- ✓ SSRF, injection, or XSS on any
*.sidecar.networkproperty
- — Findings that require physical access to the relay infrastructure
- — Attacks against shared hosting or cloud providers used by Sidecar
- — Social engineering of Sidecar personnel
- — Denial-of-service without demonstrated peer-isolation or data-exposure impact
How disclosure works
Email [email protected] with a clear description, steps to reproduce, and your assessment of impact. We will acknowledge within 48 hours. For critical findings we request a 90-day embargo to allow remediation before public disclosure. We will credit researchers in the changelog unless you prefer to remain anonymous. We do not currently offer monetary bounties, but we do provide public acknowledgement and commit to good-faith handling of every report.
- ✓ Acknowledgement within 48 hours
- ✓ 90-day coordinated disclosure window for critical findings
- ✓ Researcher credited in the changelog (opt-out available)
- ✓ No legal action against good-faith researchers following this policy
A warrant, a subpoena, or a compromised relay yields nothing useful.
The control-plane database is held in memory. Tunnel payloads are WireGuard-encrypted end-to-end — we are technically incapable of inspecting them. DNS queries are encrypted before they leave the relay. The onion-mode path requires the cooperation of two relays in two jurisdictions. There is, by design, very little for us to hand over.