Why a compliance tool needs its own egress allowlist

The most challenging security decision faced by OpenCompliance engine was regarding outbound network calls. OpenCompliance occasionally requires controlled external connectivity for fetching model cards, hitting registries, and other integrations. The two most apparent options were to let every service make arbitrary outbound requests or block everything and create exceptions inline in each service.

Both methods posed drawbacks. The first option was problematic for legal evidence, while the second option led to maintenance issues as each integration added more exceptions.

To address this issue, OpenCompliance introduced egress-proxy, a dedicated service responsible for enforcing an allowlist of outbound connections from the rest of the stack. By having just one choke point, it became easier to audit and update when new integrations required new destinations. This approach simplified the process of locating relevant information during breakdowns, especially during late hours.

For a standard web application, this would be considered excessive; however, for a system expected to produce evidence for regulators, it becomes crucial. It is not a convenience feature but a fundamental aspect of the compliance story. You cannot claim a trustworthy evidence pipeline without accountability for what it has been allowed to transmit.

The egress-proxy service is relatively small and solely dedicated to enforcing the allowlist, ensuring that all external connections are appropriately managed. The configuration and enforcement logic are both present in the repository: github.com/OpenComplai/opencomplai, under services/egress-proxy.