Bullfrog vs man-in-the-middle proxies
To control what an AI agent sends out, you have to read its requests, and almost all of them are HTTPS. The usual way to do that is a man-in-the-middle proxy: a TLS-inspecting service that sits between your machines and the internet.
A proxy reads HTTPS by ending every connection, decrypting it, and encrypting it again with a certificate of its own. That only works if every machine, every runtime and every container trusts that certificate, and if every tool agrees to talk through the proxy.
Bullfrog takes a different approach. It runs as a background service on the machine where your agents run, reads each request there, and blocks anything that machine's policy does not allow before it leaves. There is no certificate to trust and nothing to route traffic through.
How they differ
Man-in-the-middle proxy
Bullfrog
The Bullfrog control plane holds each machine's policy and the verdict log. It is never in the path of your traffic.
Feature comparison
| Man-in-the-middle proxy | Bullfrog | |
|---|---|---|
| Certificates | Create, distribute, rotate, protect | None |
| Tools that pin their certificate | Broken, or bypassed | Covered |
| Runtimes with their own trust store | A CA setting per tool | Nothing to configure |
| Code running in containers | The CA baked into every image | Covered in every container |
| Who sees your payloads | Decrypted by the proxy | Never leave your machine |
| In the critical path | One more service that can go down | Enforcement is local |
| Which process made the request | Unknown. It sees an IP and a port | Known |
What this means in practice
Certificates
You run a certificate authority. You create it, install it on every machine, rotate it, and protect its private key, which can impersonate any website to every machine that trusts it.
There is no certificate authority. Install Bullfrog and the machine is covered.
Tools that pin their certificate
Some tools only accept the certificate they expect. Behind a proxy they fail, so they end up on an exception list, and their traffic is no longer inspected.
Nothing is swapped on the wire, so pinned tools work as they are, and they are still covered.
Runtimes with their own trust store
Node, Python and Java do not all use the system's certificates. Each needs its own setting, such as NODE_EXTRA_CA_CERTS, REQUESTS_CA_BUNDLE or a Java keystore, and a new tool means a new setting.
Nothing to configure. Bullfrog does not depend on which certificates a runtime trusts.
Containers
Every image needs the CA baked in, including images you pull and do not build. Miss one and its traffic either fails or goes around the proxy.
Code running in containers on the machine is covered, with nothing added to your images.
Who sees your payloads
Every request is decrypted on the proxy, including the credentials and data it carries. The proxy becomes one of the most sensitive systems you run.
Requests are judged on the machine that sends them and never leave it to be inspected. The control plane receives policies and verdicts, not your traffic.
Availability
All outbound traffic depends on the proxy. When it is down or slow, your agents are too.
Enforcement is local to each machine. The control plane is out of the path, so it cannot take your traffic down with it.
Knowing which process made the request
The proxy sees a source IP and port. It cannot tell your agent from git or a package install on the same machine.
Every verdict names the process that made the request.
When a proxy still makes sense
Bullfrog runs on Linux, on the machines where your agents run. If you need to inspect traffic from machines you cannot install software on, such as unmanaged laptops or other operating systems, a proxy at the network edge can reach them and Bullfrog cannot.