Bullfrog vs MITM 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 terminating the client’s TLS connection, decrypting the traffic, and establishing another encrypted connection to the destination. It presents a certificate of its own to the client. That only works if every inspected machine, runtime and container trusts its certificate authority, and their traffic passes through the proxy.
Bullfrog takes a different approach. It runs as a background service on the machine where your agents run, reads supported requests there, and blocks what your configured policy does not allow before it leaves. There is no interception certificate to trust, no separate customer proxy to deploy and no per-tool proxy routing to maintain.
How they differ
Man-in-the-middle proxy
Bullfrog
Bullfrog management holds your policies and activity metadata. It is outside the application-traffic path.
The proxy diagram shows a separate-proxy deployment. MITM proxies can also run locally; the interception-CA trust requirement remains.
Feature comparison
| Feature | MITM proxy | Bullfrog |
|---|---|---|
| Certificates | Create, distribute, rotate, protect an interception CA | No interception CA to manage |
| Tools that pin their certificate | Can reject the proxy’s replacement certificate | No substituted certificate; supported TLS/tool coverage still applies |
| Runtimes with their own trust store | CA trust settings for each inspected runtime | No interception-CA trust settings |
| Code running in containers | CA trust through images or runtime configuration | Supported container traffic inspected from the host |
| Who sees your payloads | Decrypted by the proxy | Inspected locally; activity metadata reported centrally |
| In the critical path | Inspected traffic depends on the proxy | Local enforcement; management outside the traffic path |
| Which process made the request | Requires additional endpoint context | Process context collected on the host |
What this means in practice
Certificates
With a proxy
You run a certificate authority. You create it, install its trust certificate on each inspected client, rotate it, and protect its private key, which can impersonate websites to clients that trust it.
With Bullfrog
There is no interception certificate authority to manage. Install and enroll Bullfrog on a supported Linux machine and define its policy. You do not distribute a custom CA to your tools.
Tools that pin their certificate
With a proxy
Some tools only accept the certificate they expect. A pinned client can reject the proxy’s replacement certificate. Exempting it from interception restores connectivity, but also removes that inspection.
With Bullfrog
Bullfrog does not substitute the service’s certificate, so it does not introduce this certificate-pinning conflict. Inspection still depends on supported tools and TLS stacks, not just whether a connection succeeds.
Runtimes with their own trust store
With a proxy
Node, Python and Java do not always use the system’s certificates. Depending on the runtime and client library, you may need NODE_EXTRA_CA_CERTS, REQUESTS_CA_BUNDLE or a Java keystore. A new tool can mean another trust setting to maintain.
With Bullfrog
No interception-CA trust settings to configure. Bullfrog does not depend on which certificates a runtime trusts. Enrollment and request policy still apply, as does support for the runtime’s TLS stack.
Containers
With a proxy
Inspected container clients need to trust the proxy’s CA too, including clients in images you pull and do not build. You can supply that trust through the image or runtime configuration. Missing trust can cause certificate failures; bypassing the proxy removes inspection.
With Bullfrog
Supported container traffic is inspected from the host, without adding an interception CA to your images. Coverage depends on the tools and TLS stacks inside those containers; it is not automatic coverage of every container workload.
Who sees your payloads
With a proxy
Inspected requests are decrypted on the proxy, including the credentials and data they carry. The proxy becomes one of the most sensitive systems you run.
With Bullfrog
Requests are judged on the machine that sends them and do not leave it to be inspected elsewhere. Allowed requests still reach their destinations. Activity metadata is reported centrally; application traffic is not routed through Bullfrog management.
Availability
With a proxy
Traffic routed through the proxy depends on it. When that service is down or slow, the agents using it can be affected. A separate proxy adds another traffic-path service to operate.
With Bullfrog
Enforcement is local to each machine. Management is outside the application-traffic path, and an existing valid cached policy can continue locally during a management outage. Enrollment, policy updates and local-agent health still matter.
Knowing which process made the request
With a proxy
A network proxy sees a source IP and port. Distinguishing your agent from git or a package install on the same machine requires additional endpoint context.
With Bullfrog
Bullfrog collects process context on the host, alongside outbound activity and policy decisions. That gives you endpoint context for investigation without relying on a network address alone; attribution is not guaranteed for every verdict.
When a proxy still makes sense
Bullfrog runs on supported Linux machines where your agents run. If you need to inspect traffic from machines you cannot install software on, a network-edge proxy may be a better fit, provided the clients can be routed through it and trust its CA. Bullfrog coverage depends on tools, TLS stacks, configured policy and enforcement mode.
Contact us at info@bullfrogsec.com