Envoy Egress Allowlist: CIDR Example for MCP Tools

An Envoy egress allowlist CIDR example has two jobs: limit which internal workloads can use the proxy, then limit where their MCP tools can connect. In Envoy RBAC, a CIDR match normally identifies the downstream caller's source IP. It does not, by itself, make a hostname-based outbound allowlist.

In 2026, I treat these as two separate rules. First, only the agent network may call the proxy. Second, a permitted tool may reach only the named upstreams it needs. For OpenClaw, pair that network boundary with the sandbox and tool policies that decide which tools an agent can invoke. The OpenClaw configuration guide is a useful starting point for that local policy.

What an Envoy egress allowlist actually controls

An Envoy egress allowlist is a proxy policy that accepts only the destinations and request shapes you explicitly approve. It reduces the blast radius when a tool is prompt-injected or configured with the wrong endpoint.

OpenClaw documents tool policy and sandboxing as separate controls. I do not put shell tools in an agent just because a proxy exists. I also keep a separate guide to local OpenClaw and Ollama agents for the model-side setup. Do not claim that an Envoy file is an OpenClaw setting. OpenClaw can limit a tool. Envoy limits a network path.

CIDR example: restrict who can use the proxy

A CIDR rule is useful when an Envoy listener should only accept requests from a known workload network. In this generic HTTP RBAC example, 10.42.0.0/16 is the internal subnet allowed to call the proxy. Replace it with your actual workload range, not a public or guessed CIDR.

http_filters:
  - name: envoy.filters.http.rbac
    typed_config:
      "@type": type.googleapis.com/envoy.extensions.filters.http.rbac.v3.RBAC
      rules:
        action: ALLOW
        policies:
          mcp-workloads-only:
            permissions:
              - any: true
            principals:
              - direct_remote_ip:
                  address_prefix: 10.42.0.0
                  prefix_len: 16

Envoy's RBAC reference defines ALLOW as allowing a request only when a policy matches. Put the filter on the listener that receives proxy traffic, and verify the real source address Envoy sees. A sidecar, a load balancer, or an address translation layer can change that address.

Do not mistake this for destination filtering. The CIDR rule above answers "which workload may use this listener?" It does not answer "may this workload reach api.github.com?" Destination restrictions need a deliberately configured proxy route, cluster, or egress-gateway policy for the approved upstreams.

Build an Envoy egress allowlist from tool dependencies

An Envoy egress allowlist should come from a short tool inventory. I list each external call first. I allow only the hosts the tool needs. Then I test it before I trust it.

Keep the policy close to the infrastructure that owns routing. For TLS traffic, validate hostname and certificate handling rather than trusting an application-provided Host header. Avoid wildcard domains unless you can explain every subdomain that becomes reachable.

Test a deny case before calling it protected

A policy that has never blocked a request is not proven. Test one permitted endpoint and one intentionally unapproved endpoint using the same network path your MCP process uses. Capture the Envoy access log, the proxy response status, and the tool name that made the attempt.

docker logs <envoy-container> --since 10m

The exact log fields and status depend on your Envoy configuration. Do not hard-code an expected 403 or an RBAC: access denied line unless your own proxy emits it. What matters is evidence that the unapproved request did not reach its destination and that the event is observable.

Record these four facts for each test:

• Caller: the workload or pod that made the request.
• Target: the exact host and port it tried to reach.
• Decision: allowed or denied by the proxy policy.
• Evidence: the timestamp, request ID, and matching access-log entry.

After the network test, run openclaw security audit --deep. OpenClaw's security guidance recommends the audit after configuration changes. It also says a gateway is for one trusted operator or team. If users do not share a trust boundary, separate gateways and credentials are safer than a larger allowlist. For a concrete MCP threat model, review the OpenClaw OSINT MCP safety guide before adding tools that handle sensitive data.

Common mistakes with MCP egress controls

Treating a CIDR as a domain allowlist. CIDR matches IP address ranges. It is useful for a caller network or a fixed IP destination, but it is not a safe substitute for hostname-aware TLS routing.

Allowing broad proxy access. A proxy that accepts traffic from every container or every developer laptop becomes an SSRF relay. Limit the listener to the workloads that need it and protect its administrative interface separately.

Skipping OpenClaw's tool policy. Envoy limits a network path. It does not decide whether an agent should be allowed to run a shell, browser, or MCP tool. Use both layers and keep high-risk tools out of agents that do not need them.

Expanding on the first denial. Denials are a review queue, not an automatic permission request. Confirm the tool, endpoint, protocol, and business need before changing the policy.

FAQ

Does OpenClaw include an Envoy egress allowlist setting?

OpenClaw documents sandbox and tool-policy controls, not a standard OPENCLAW_MCP_EGRESS_PROXY or Envoy-bootstrap command in its current security documentation. Treat Envoy as infrastructure you operate separately. Keep the network policy and the OpenClaw configuration independently documented so an upgrade does not silently remove either boundary.

Is a CIDR rule enough to restrict MCP egress?

No. A CIDR rule can restrict which IP range reaches an Envoy listener, or it can be part of a destination rule where fixed IPs are appropriate. It does not safely express a hostname allowlist for changing SaaS endpoints. Use a proxy design that validates the intended upstream host and TLS behavior.

Should local OpenClaw agents use an egress proxy?

Use one when the local agent has credentials, private data, or network access that a compromised tool should not freely use. A small personal setup may begin with OpenClaw sandboxing, tool restrictions, and loopback-only services. Add the proxy once tool egress crosses a meaningful trust boundary.

Wrap-up

An Envoy egress allowlist is valuable only when it is specific: known callers, known upstreams, verified TLS behavior, and a tested denial path. Pair it with OpenClaw sandbox and tool policies, keep the list short, and review every exception as a security change.

Written by Matteo Giardino, CTO and founder. I build AI agents for SMEs in Italy. My projects.