Product

Bullfrog Egress Control

An outbound policy for every agent.

Can your agent run a command, execute code or open a web page? Then any request it makes is a possible way out for your data.

Bullfrog judges every request before it leaves.

Outbound requests

agents-prod-01

Install a package

GET registry.npmjs.org/express
npm Allowed

Open a pull request in your organization

POST api.github.com/repos/<your-org>/<your-repo>/pulls
gh Allowed

Call the model with your company’s key

POST api.anthropic.com/v1/messagesAPI key · <your-org>
python Allowed

Call the model with a key you don’t own

POST api.anthropic.com/v1/messagesAPI key · <other-org>
python Blocked

Create an issue in another organization via MCP

POST api.githubcopilot.com/mcpMCP tools/call · create_issue · <other-org>
Claude Code Blocked

Upload to a bucket you don’t own

PUT s3.amazonaws.com/<external-bucket>/export.csv
aws Blocked

Map it. Decide it. Enforce it.

  1. Map

    Start in audit mode. See every destination your agents reach, sorted into your accounts, shared services, and destinations seen for the first time.

  2. Decide

    Add an integration for each service your agents use and lock it to your accounts and keys.

  3. Enforce

    Every request is judged before it leaves. Anything not allowed is blocked and logged with the process that made it.

Start from the services your agents already use.

The integrations catalog bundles what each service needs: the domains to allow, the requests to inspect, and where writes may go. Pick an integration, name your accounts, and your agents can work with the service without it becoming a way out for your data.

Request-level control for the agent harnesses you run

  • Claude Code
  • Cursor
  • Codex
  • OpenClaw
  • Hermes
  • OpenCode
  • Pi
  • Goose
  • Aider

Manage centrally. Enforce locally.

Set policies for the servers running your AI agents from one console. Share policies across servers or define different boundaries, and review outbound activity and policy decisions in one place.

Central console
Example servers, policies and illustrative last activity.
ServerPolicyLast activity
agents-prod-01
 Production 2m ago
agents-prod-02
 Production 8m ago
agents-staging-01
 Staging 1h ago
Policy enforced on each server

Built for the way agents run

Per request, not per domain

Decide on the method, path and body of each HTTPS request, so shared services like GitHub stay usable without becoming a way out.

No CA, no proxy

No interception certificates to create, distribute or rotate, and no custom trust store to configure per tool. Certificate pinning stays intact on supported tools and TLS stacks.

A policy per server

Give servers different boundaries, or deliberately share a policy. Allowing a site for one server does not have to open it for the others.

Covers container workloads

Inspect supported container traffic from the host, with nothing baked into your images. Coverage depends on the tools and TLS stacks inside.

Knows which process asked

See process context alongside outbound activity and policy decisions, not just an IP and a port.

Payloads stay local

Requests are inspected where the agent runs, not sent elsewhere for inspection. Activity metadata is reported centrally, but there is no separate inspection service in the traffic path.

Bullfrog Egress Control vs network firewallsBullfrog Egress Control vs MITM proxies

Simple to install. Simple to manage.

  • No proxy
  • No custom CA
  1. 1

    Install

    Deploy Bullfrog on the servers running your AI agents.

  2. 2

    Set policy

    Define policies for outbound requests and remote MCP tools in one central console.

  3. 3

    Govern

    See outbound activity and policy decisions across your servers from the same console.

See where your agents send data.

Get in touch