CrabTrap: an outbound HTTP proxy that puts an LLM judge between your agent and the internet
An LLM-as-a-judge HTTP proxy to secure agents in production
At a glance
- What is it?
- CrabTrap is a Go forward proxy from Brex that terminates TLS, applies deterministic URL rules, then falls back to an LLM policy judge for anything the rules miss. It is a useful fit for teams running agents that call third-party APIs, and the wrong tool if you need response filtering or human approval.
- Who is it for?
- Adopt CrabTrap if your agents make outbound HTTP calls to SaaS APIs and you want a single choke point where deterministic rules run first and an LLM judge handles the long tail, with every decision written to PostgreSQL. Do not adopt it if you need inbound inspection, response redaction, WebSocket frame filtering, or a human approval queue; the README states plainly that it does none of those.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 50 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap CrabTrap fills: agents with credentials and no outbound policy
An agent that holds a Slack token, a GitHub token and a Gmail token can call anything those tokens reach. The usual controls do not cover this. An inbound WAF never sees the traffic, because the request originates inside your network. Egress firewall rules operate on hostnames and ports, not on the semantics of a request body. CrabTrap's answer is to make the agent route through a forward proxy (set HTTP_PROXY and HTTPS_PROXY to point at it) and evaluate each request there. The README frames the audience directly: teams that run AI agents calling external services and want guardrails plus a complete audit trail. The unit of policy is the agent, and policies are written in natural language, which is the part that distinguishes this from a conventional egress allowlist.
Two-tier evaluation: static rules first, LLM judge only on a miss
The request flow is the design. The agent connects through the proxy. CrabTrap terminates TLS by generating a per-host certificate from its own CA and decrypts the request. The request is then matched against URL pattern rules (prefix, exact, or glob) with optional HTTP method filters. A match decides immediately, with no LLM call, and deny rules always take priority over allow. Only when nothing matches does the LLM judge evaluate the request against that agent's natural-language security policy. Allowed requests are forwarded; denied ones get a 403 with the reason. Every request, decision and response is recorded in PostgreSQL. The ordering matters for cost and latency: the deterministic tier absorbs the predictable traffic, and the model is paid for only on the residue. The judge path is wrapped in a circuit breaker that trips after 5 consecutive LLM failures and reopens after a 10s cooldown, with a configurable fallback of deny (the default) or passthrough. Passthrough is the setting to think hardest about, because it converts an LLM outage into an open door.
Getting it running: Docker, a copied CA cert, and a token in the proxy URL
The README's short version is four steps. Start the stack with docker compose up -d, which brings up CrabTrap and Postgres. Copy the generated CA out of the container with docker compose cp crabtrap:/app/certs/ca.crt ./ca.crt. Create an admin with docker compose exec -it crabtrap ./gateway create-admin-user test-admin, then take the last line of that output and cut the second field to get admin_token. Create a non-admin user by POSTing to http://localhost:8081/admin/users with an Authorization: Bearer header and a JSON body such as {"id": "alice@example.com", "is_admin": false}; the response contains a channels array, and the entry with channel_type == "gateway_auth" carries the gateway_auth_token. That token is the credential the agent presents to the proxy. The documented test is curl -x http://${token}:@localhost:8080 --cacert ca.crt https://httpbin.org/get. Note the shape: the token goes in the proxy URL's userinfo, not in a header, and the CA must be trusted by the client or the TLS interception fails. The proxy listens on 8080, the admin UI on 8081, and the admin token logs you into the UI.
Configuration surface and the operational pieces around it
Configuration is YAML, with config/gateway.yaml.example given as the full reference. The documented sections are proxy (port, timeouts, rate limits, SSRF CIDR allowlist), tls (CA cert and key paths, certificate cache size defaulting to 10,000), approval (mode llm or passthrough, 30s default timeout), llm_judge (provider, model IDs, fallback mode, circuit breaker), database (a PostgreSQL URL that supports ${DATABASE_URL} expansion), audit (destination stderr by default, or stdout, or a file path), alerting (enablement and cooldown), and log_level. Beyond the proxy itself there are three operational tools worth naming. The policy builder is an agentic loop that analyzes observed traffic and drafts policies. The eval system replays historical audit log entries against a policy to measure accuracy, which is the only way the README offers to check a policy before trusting it. Denial alerting notifies bot managers when a new URL pattern is denied, deduped with a configurable cooldown, documented in docs/alerting.md. There is also a React and TypeScript admin UI for the audit trail, policy editor, eval results and agent management.
What it explicitly does not do, and why that matters more than the feature list
The README's own limitations section is unusually candid and should drive the adoption decision. CrabTrap is a forward proxy for outbound traffic only; it is not a WAF and does not inspect inbound requests to your services. It does not redact sensitive data: the proxy sees all request content in cleartext, including Authorization and Cookie headers, and the README calls this by design, with the trust boundary being the proxy itself. There is no human-in-the-loop approval, no approval queue, no Slack prompt, no escalation path; decisions are automatic. Responses are not filtered. Only the WebSocket upgrade request is evaluated, and frames pass through uninspected afterward. Two consequences follow. First, if your threat model includes secrets leaking outward in a request body, CrabTrap will log that body to Postgres rather than scrub it, so your database becomes part of the sensitive-data perimeter. Second, an agent that needs a human to sign off on a destructive call has no place to stand here; you would have to express that as a static deny rule and accept a hard block instead of a prompt.
The honest alternative: a conventional egress proxy or service mesh
The realistic comparison is not another LLM judge but the egress control you may already run, such as an Envoy-based egress gateway or a service mesh sidecar with an external authorization filter. The difference in approach is where the decision is made. A mesh or Envoy egress path decides on identity and destination: which workload, which host, which path, expressed in configuration that is reviewed and versioned like code. It is deterministic, fast, and has no model dependency. CrabTrap decides partly on the content and intent of the request, expressed as a natural-language policy per agent, which lets you write rules like "do not post to public channels" that no hostname allowlist can express. The cost is a model call on every unmatched request, a fallback mode you must choose deliberately, and a policy artifact whose correctness is measured by replaying audit logs rather than by reading a diff. If your policies can be written as host and path patterns, an egress gateway is simpler and has no outage mode. CrabTrap earns its place when the policy genuinely needs to describe intent.
Maintenance cost, licence, and what the release cadence suggests
CrabTrap is MIT licensed, which permits commercial use, modification and redistribution; the repository does not include a NOTICE or additional terms in the supplied material, and this is not legal advice, so have counsel confirm anything that matters to you. Operationally you are running two stateful things: the proxy container and PostgreSQL, which holds the audit trail, policies and users. The audit table grows with every request and, per the README, stores responses as well as requests, so retention and vacuum strategy are yours to design. Upgrades mean watching the schema migrations under internal/db and the config schema, since config/gateway.yaml.example is the reference and keys have moved between sections across the three releases. The release history shows v0.0.1 in April 2026, v0.0.2 in May, and v0.0.3 in June, with the last push in July 2026. Three zero-dot releases in three months is a project still settling its interfaces, so pin an image tag rather than tracking a moving one. The certificate cache default of 10,000 entries and the per-IP rate limiter default of 50 req/s with burst 100 are the two knobs most likely to need tuning on day one.
Editorial conclusion
Adopt CrabTrap if your agents make outbound HTTP calls to SaaS APIs and you want a single choke point where deterministic rules run first and an LLM judge handles the long tail, with every decision written to PostgreSQL. Do not adopt it if you need inbound inspection, response redaction, WebSocket frame filtering, or a human approval queue; the README states plainly that it does none of those. Before rolling it out, verify three things against your own config: that the generated CA certificate in certs/ is distributed to every agent runtime, that the llm_judge fallback mode is set to deny unless you have deliberately chosen passthrough, and that your Postgres instance is sized for the full request and response audit volume, because the proxy stores both.
Community notes