# Show HN: I built a smart proxy so your coding agent can run loose > Source: > Published: 2026-07-14 14:55:53+00:00 ## Isn't this just mitmproxy with extra steps? mitmproxy is an interception toolkit; trollbridge is a policy-enforced gateway. You could build trollbridge on top of mitmproxy in a weekend — the parts that take longer are the rule engine, the optional LLM advisor, the JSONL audit log with per-request correlation, and the approval TUI. Operationally, you set `HTTPS_PROXY` once and forget it; there's no Python deployment story. ## Why an LLM in the proxy path — isn't that slow or expensive? The advisor only ever sees what policy *holds*. Your inline allow/deny lists settle the bulk of traffic at the wire, before any model is consulted. When a request is held — that's default-ask mode, or a rule that returns `ask_llm` — a configured advisor classifies it against your lists and, if it's confident, resolves it; low-confidence or unreachable verdicts fall to the operator queue instead of auto-allowing. It's off unless you configure one, so most setups never call a model at all. ## What happens when the LLM advisor is wrong? Every LLM verdict is written to the audit log alongside the request metadata, the model that decided, and the confidence floor it cleared — `grep` and `jq` are the review interface. Below the floor, or when the advisor is unreachable, the decision falls back to the operator approval queue instead of auto-allowing, so close calls land in front of a human. ## How is this different from gVisor, firejail, or Bubblewrap network policy? Those gate egress at the kernel boundary — binary allow/deny by destination IP or port. trollbridge gates at HTTP semantics: host and port for HTTPS by default, plus path/method/query/body when TLS interception is on. It also stays out of the file system and the process table entirely. The layers are complementary; run both. ## Can I run it without sending data to a third-party LLM? Yes — two ways. First, the LLM advisor is off by default: with no `advisor` block configured and no rule returning `ask_llm` , trollbridge never calls out to a model, decisions stay on the deterministic policy and operator-queue path, and the binary makes zero outbound calls. Second, if you do want the advisor, run your own model — point the advisor `endpoint` at a local, OpenAI-compatible server (Ollama, vLLM, llama.cpp, and friends) so the judgment runs on hardware you control and request data never leaves your network.