Why a compliance tool needs its own egress allowlist

I didn't expect the hardest security decision in a compliance engine to be about outbound network calls. It was.

Opencomplai's services occasionally need controlled external connectivity. Fetching a model card. Hitting a registry. Whatever a given integration requires.

The obvious options are two. Let every service make arbitrary outbound requests, which is bad for anything touching legal evidence. Or block everything and special-case exceptions inline in each service, which is a maintenance problem that grows with every integration.

I picked a third. egress-proxy is a dedicated service whose entire job is enforcing an allowlist for outbound connections from the rest of the stack. Nothing else talks to the outside world directly.

One choke point. One place to audit. One place to update when a new integration needs a new destination.

I'm the person who gets called when things break, sometimes at 1am. At that hour I want one place to look, not five.

For a normal web app this is overkill. For something that is supposed to produce evidence you can hand a regulator, "we can enumerate every external system this ever talked to" isn't a nice-to-have. It's part of the compliance story itself. You can't claim your evidence pipeline is trustworthy if you can't account for what it was allowed to phone home to.

It's a small service, and that is the point. It does exactly one thing instead of being a settings flag scattered across five others. Allowlist config and enforcement logic are both in the repo: github.com/Opencomplai/opencomplai, under services/egress-proxy.