Egress allowlists need destination identity and a bounded IP range

An internal service can make outbound requests to package registries, model providers, webhooks, and partner APIs. Those connections are often treated as normal infrastructure traffic. If the service is compromised, the same network path can become a channel for data exfiltration, command-and-control, or access to a cloud metadata endpoint. An egress allowlist narrows that path, but only when it identifies the destination and protocol that the application actually needs.

An allowlist based on a broad IP range is easy to bypass when the destination uses a content delivery network or a shared cloud address. A hostname rule can also be too broad if it permits every path and method on a shared domain. The policy should combine a destination, a port, a protocol, and, where the proxy understands it, a path or TLS server name.…