Skip to main content

Your Agent's Firewall Can't Read SQL. Deno's Claw Patrol Can.

11 min readDora NodaDora Noda
Share
On this page

When a PagerDuty alert fires at Deno, an AI agent starts investigating production: querying the Postgres database, running kubectl, checking dashboards. That agent holds the same tools an engineer has — psql, kubectl, gh, curl — which means DROP TABLE users is one hallucinated tool call away. Deno's answer, open-sourced in May 2026 and Show HN'd that June, is Claw Patrol: a security firewall that terminates the agent's TCP connections over a WireGuard or Tailscale tunnel, parses the actual application protocol inside — HTTP, Postgres, SSH, Kubernetes, ClickHouse — and allows, denies, or escalates each request to an LLM judge or a human approver. The policy sees the query, not just the connection.

That last distinction is the whole idea. An IP allowlist knows your agent reached the database. A protocol-aware firewall knows it sent SELECT and not DROP. For anyone running agents that deploy and operate real apps — on a self-hosted platform especially — this is the enforcement layer the stack has been missing. Here's how it works, what it costs, and where it belongs.

The gap: every existing gate stops at HTTP

Deno's launch post surveys the incumbent layers honestly, and the survey doubles as a map of the gap. Each tool class covers part of the problem:

LayerExamplesWhat it seesWhat bypasses it
LLM gatewaysHelicone, Portkey, OpenRouter, LiteLLMThe model callEvery non-model call the agent makes
Content guardrailsNeMo Guardrails, LakeraPrompt/response textTool calls to real systems
HTTP tool-proxieshttpjail, CrabTrapOutbound HTTP method + URLPostgres, SSH, ClickHouse, raw TCP
Process sandboxesNVIDIA OpenShell, agentshLocal filesystem/process accessNothing remote — the network is out of scope
Credential-injecting proxiesAgent Vault, ClawvisorHTTP method + URL, injects secretsNon-HTTP protocols; no approval chains

The pattern is stark: nothing speaks past HTTP, and no combination of them reaches Deno's concrete case — a production Aurora database inside a VPC, reachable only through an EKS apiserver, gated by a rule that has to understand SQL. As the Show HN thread put it, related projects sit as proxies doing secret injection or guardrails, but none handle low-level protocols or messy real-world paths like Postgres tunneled through Kubernetes.

This gap is not theoretical anymore. The OpenClaw ecosystem Deno's agents come from spent early 2026 collecting incident reports: the ClawJacked WebSocket hijack chain, Snyk's finding of 283 ClawHub skills leaking API keys, Cisco's researchers calling the top-ranked community skill functionally malware, and a misconfigured database behind an agent social app exposing 1.5 million API tokens. The agents got production-shaped authority before anyone built production-shaped enforcement.

How Claw Patrol works on the wire

The deployment has five actors: the agent (Claude Code, Codex, OpenClaw — plus the CLIs it shells out to), the device it runs on, a WireGuard or Tailscale transport, a single Go binary called the gateway, and the upstream being called. The agent dials upstream hostnames directly with no awareness anything is in the path — no HTTPS_PROXY variable, no per-tool CA bundle, no proxy URL. A small client on the device captures outbound flows at the routing layer and feeds every byte into the tunnel.

Once a flow reaches the gateway, a dispatcher picks one branch per flow by destination port and IP:

DestinationHandler
TCP :443Peek TLS ClientHello SNI, terminate TLS, parse HTTP/Kubernetes request
TCP :5432Postgres wire-protocol gateway (auth offload + SQL rule matching)
UDP/TCP :53DNS responder: VIP-bound hosts get virtual IPs, rest forwarded untouched
VIP addressSSH or ClickHouse-native runtime (protocols with no SNI to peek)
Anything elseTransparent byte-for-byte relay

Three mechanisms here deserve a closer look, because they're where "protocol-aware" stops being a slogan:

TLS interception with minted leaf certificates. For HTTPS and Kubernetes endpoints, the gateway terminates TLS using a leaf certificate minted on the fly (P-256, 30-day validity, in-memory cache, signed by the gateway's CA, which is provisioned on the device at onboarding). It then sees parsed http.Request objects — method, path, headers, body — runs policy, injects the real credential, and round-trips upstream. The agent never sees the upstream's real certificate.

Postgres claiming by destination IP. Postgres has no SNI, so the gateway resolves each configured Postgres hostname at policy load and builds an index mapping destination IPs to endpoints. When several endpoints share one IP (a writer and a read-only role aimed at the same RDS instance), the device's profile picks the winner. The gateway then performs auth offload and evaluates Query/Parse wire messages against SQL-family rules.

DNS virtual IPs for SSH and ClickHouse. Protocols with neither SNI nor Host header get stable virtual IPs assigned at policy build (persisted across restarts). The gateway's in-process DNS responder answers VIP-bound hostnames with the virtual IP and forwards everything else to the real resolver, so unrelated traffic flows unchanged. When the agent dials the VIP, the SSH runtime takes over and sees channels and global requests.

Past the dispatcher, three plugin families do the work: endpoint plugins own per-protocol decode, credential plugins own exactly one secret shape each (Bearer [REDACTED] Postgres user/password, SSH key, mTLS bundle), and approver plugins arbitrate human- and LLM-in-the-loop verdicts. The agent holds only placeholders like {{github_pat}}; the gateway swaps in the real token on the wire. A compromised agent process cannot leak keys it never held.

What a protocol-aware rule looks like

Policy is written in HCL, with conditions as CEL expressions over the parsed wire facts each protocol family exposes: http.* (method, path, headers, body), sql.* (verb, tables, functions), k8s.* (verb, resource, namespace), and an SSH facet for channels and requests. Here's a real rule from Deno's own config, denying Kubernetes secret reads across their deploy clusters:

hcl
rule "k8s-no-secrets" {
  endpoints = [kubernetes.deploy-dev, kubernetes.deploy-prod]
  condition = "k8s.resource == 'secrets'"
  verdict   = "deny"
  reason    = "Secret values must not leave the cluster via the agent"
}

A Postgres rule follows the same shape — match on the SQL verb and tables, so a read-only analytics agent gets SELECT and never DROP, DELETE, or TRUNCATE, enforced below every layer the agent can talk around. Verdicts aren't just allow or deny: a rule can chain approvers, and Deno runs exactly that in production — an LLM proctor checks a customer-support draft for tone and markdown, then a human in Slack approves or edits it, with the original request held open while the dashboard pushes a live pending entry to the operator.

Onboarding is one command, clawpatrol join <gateway>, with two scopes: clawpatrol run -- <cmd> wraps a single agent process (Linux network namespace, macOS NetworkExtension with PPID filtering), hiding even the tailnet auth key from the wrapped process via an empty tmpfs overlay; clawpatrol join --whole-machine flips the host's default route through the gateway as an exit node. The getting-started guide promises zero to working gateway in five minutes.

What it costs: latency, trust, and parser maintenance

Claw Patrol is alpha software, and Deno says so plainly: protocol support is exactly as broad as Deno needs, with docs for adding more. Anyone adopting it — or building this layer into their own platform — should price four costs honestly:

Latency. Every intercepted flow pays for an extra network hop plus TLS terminate-and-reoriginate plus rule evaluation. Rule matching itself is cheap CEL over parsed facts, but approval chains are slow by design: an LLM proctor adds seconds, a human in Slack adds minutes. That latency is fine for the workloads it gates (a human was going to review the destructive action anyway) and disqualifying for anything synchronous and hot — this layer belongs in front of admin-shaped traffic, not the data plane.

Trust concentration. The gateway holds every real secret and terminates every TLS session; the agent never sees upstream certificates or keys. That makes the gateway the crown jewel of the deployment: whoever owns it owns everything downstream. Hardening, patching, and access control for that one Go binary matter more than any single rule inside it.

Parser maintenance. Every protocol parser is attack surface that a compromised agent speaks to first. Postgres extended-protocol handling, SSH channel multiplexing, SNI peeking — each is code that must correctly decode adversarial-adjacent input forever, across server version upgrades that shift wire behavior. Deno ships the half-dozen protocol plugins it needs; anything else is your PR to write and your parser to maintain. This is the real long-term price of seeing the query instead of the connection.

The fail-open default. Today, destinations no endpoint claims fall through to a transparent relay, and unmatched HTTPS hosts pass through by default (unknown_host = passthrough). For a firewall, that's the wrong default to ship to production — the first hardening step of any real deployment is flipping unknown traffic to deny and enumerating every upstream the agent legitimately needs. Expect that inventory to be the actual work of week one.

None of this is disqualifying; it's the normal shape of a chokepoint. But it explains why the HTTP-only tools keep existing: they pay almost none of these costs, because they enforce almost none of this policy.

Where this layer lives on a self-hosted platform

The placement question for a platform team is: per-sandbox sidecar, node-level proxy, or CNI plugin? Claw Patrol's own architecture answers it by splitting the problem in two — thin capture where the workload runs, policy decisions on a hardened gateway — and that split is the pattern worth copying:

PlacementAttributionPolicy strengthVerdict
Per-sandbox sidecarPerfect (one identity per sandbox)Weak if secrets live in every sidecarCapture here, don't decide here
Node-level proxyBlurred across tenants without extra identity plumbingStrong, but a noisy-neighbor and blast-radius riskWorkable, worse isolation
CNI pluginGood (pod identity)Too low in the stack — L3/L4 can't parse SQL without re-implementing the gatewayWrong layer for content policy
Capture at sandbox + shared gatewayPerfect at capture, centralized at decisionStrongest: one policy surface, one secret storeThe Claw Patrol shape — copy it

Concretely: scope capture to the sandbox (a network namespace, a sidecar, a per-tenant WireGuard peer — the equivalent of clawpatrol run), so every flow arrives at the gateway already attributed to exactly one tenant. Keep credentials, parsers, and approval chains on a dedicated gateway the tenant's code can never execute on. Sandbox isolation and protocol-aware egress are complements, not substitutes: the sandbox decides what the agent may touch locally, the gateway decides what its bytes may say remotely. An agent that can reach the database but only SELECT, reach the API but never DELETE, is the product of both layers agreeing.

The agent era needs a new chokepoint

The Show HN thread — 112 points, 31 comments, with the Deno team answering questions in the comments — landed because it named something operators already felt: agents graduated to production authority while enforcement was still arguing about prompt text. LLM gateways watch the model call; the damage happens three tool calls later, over Postgres. Claw Patrol's bet is that the durable chokepoint is the wire itself — terminate the connection, parse the protocol, hold the secrets, and make the destructive action ask permission from something that isn't the agent.

It's early: alpha, a half-dozen protocol plugins, a fail-open default to flip, and parsers you'll extend yourself. But the direction is right, and it's open (MIT, Go, HCL) at exactly the moment the OpenClaw incident log makes the alternative — unrestricted agents with production credentials — look untenable. If you run agents against anything you care about, the question for your next quarter is not whether to add an egress enforcement layer, but which protocols yours needs to speak on day one.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Agent-operators are first-class citizens here: machine-readable infrastructure state, MCP-native control, and sandboxes built for workloads like the ones above. Star the repo on GitHub or deploy your first app today.

Related articles

Give your agents a chain backend

Autonomous agents hit RPC endpoints very differently than people do. See what bex router handles on their behalf.

Read the agents guide