At Deno, we run Deno Deploy, JSR, and a handful of other production services. We’re increasingly using agents to help with operations: triage PagerDuty alerts, check dashboards, query logs, run kubectl, roll back a bad deploy, and so on.

That means giving the agents access to many of the production systems an engineer has: AWS, GCP, Postgres, Kubernetes, ClickHouse, GitHub, Slack, Grafana.

This requires extreme care, and presents a dilemma.

An agent with limited access isn’t very useful. But the more access it has, the more dangerous it is: kubectl delete namespace prod and psql -c 'DROP TABLE users' are both one tool call away.

An agent cannot be trusted to police itself. The agent process holds tools (psql, kubectl, gh, curl) and the credentials those tools need. A prompt injection, a hallucination, or a bad tool call can use them.

And we can’t change how the agent behaves. Most of what we run (Claude Code, Codex) is code we install, not code we wrote. Any solution has to sit outside the agent.

A concrete example from our setup: We have a production Aurora database inside a VPC, reachable only through an EKS apiserver. It’s extremely useful if our agents, which run 24/7, have read access to this database. But we must ensure the agent could never call DROP TABLE.

That’s an outbound network path the agent’s host can’t reach, on a protocol that isn’t HTTP, gated by a rule that has to understand SQL.

There’s a growing set of projects and products around this area:

• LLM gateways (Helicone, Portkey, OpenRouter, LiteLLM) and content guardrails (NeMo Guardrails, Lakera) watch the model call. Agents talk to many services other than the models; those calls never reach the LLM gateway.
• HTTP tool-proxies (httpjail, Crab Trap) gate the outbound HTTP call. Agents also speak other non-HTTP protocols like Postgres and SSH.
• Process sandboxes (NVIDIA OpenShell, agentsh) are generally focused on local access that the agent can make. We already run our agents on standalone VMs; for us these are only marginally useful.
• Credential-injecting forward proxies (Agent Vault, Clawvisor) terminate TLS, inject credentials, and filter outbound HTTP. They match on HTTP method and URL, not other protocols; they decide allow or deny, without composing LLM judges and human approvers in chains; and they don’t tunnel onward to networks the agent’s host can’t reach. (Deno Sandbox ships a similar capability.)

Each of these is solving part of the problem. None of them speak anything beyond HTTP, however, and no combination of them reaches a Postgres database through an EKS apiserver, or gates by SQL verb.

For agents touching real production systems, that gap is the whole game.

Today we’re open-sourcing our solution to this problem: Claw Patrol

Agent traffic routes through a WireGuard or Tailscale tunnel to a gateway that terminates TLS, parses the inner protocol, holds and injects the real credentials, and evaluates each request against rules you write in HCL. The gateway can tunnel onward to reach networks the agent’s host can’t (a kubectl port-forward into EKS, a Cloud SQL proxy, a tailnet).

Here’s one rule from our config, as an example, denying reads of Kubernetes secrets across our deploy clusters:

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"
}

Rules match on parsed protocol facets: HTTP method, path, and body; SQL verb, tables, and functions; Kubernetes verb, resource, and namespace. Verdicts can be allow, deny, or a chain of approvers: a model judging against a policy you write, a human in Slack, or both in sequence. We use the chain to gate customer-support replies our agent drafts. The LLM checks the body for markdown and tone, then a human in #support approves or edits the draft.

Credentials live on the gateway, not the agent. The agent sends a placeholder like {{github_pat}} and the gateway swaps in the real token on the wire. A compromised agent process can’t leak keys it never held in the first place.

While we’re excited to share Claw Patrol (under MIT license), it is currently alpha software. This is what’s working for us, so the protocol support is as broad as we need it. You’ll find sufficient documentation to code up support for other protocols. We’d especially love to see rule patterns from real deployments, protocols you’d want gated next, and rough edges in the install path. Issues and PRs welcome.

The getting-started guide takes you from zero to a working gateway in five minutes.

• Site: clawpatrol.dev
• Code: github.com/denoland/clawpatrol
• Security model
• Architecture
• Demo Claw Patrol instance