Docs

Egress policy

Pin the hosts a sandboxed agent run is allowed to reach, per repo. Nothing else leaves. Each pinned domain or IP maps to exactly one network capability the sandbox grants, so the allowlist is the policy rather than a description of one. Loopback and private ranges can never be pinned, because allowing those would let a run call back into your own machine.

Where to find it

  • Localhost: /egress-policy.html
  • API: GET /api/egress-policy, POST /api/egress-policy
  • CLI: repoops egress-policy add <host> and remove <host>
  • Sidebar: Guard, then Egress policy

What it does for you

The allowlist is enforced, not advisory.Every pinned host becomes one granted network capability on the sandbox runtime, so the generated permission set can never be broader than what you pinned. There is no second place where a host could be allowed.
It fails closed, which is the only useful direction.A policy that will not load is treated as the empty allowlist. So a host that was reached is flagged, always. The failure mode of a config error is a noisy alert, never a silent allow.
You hear about an unlisted host without watching for it.A background check reads the sandbox run audit rows per repo, evaluates each run against the allowlist, and fires one unlisted-host alert through the same sinks the rest of RepoOps uses (Slack, PagerDuty, incident.io). With no sink configured it is an honest no-op rather than a silent one.
Private ranges are refused on principle.Loopback and private addresses cannot be pinned at all. An allowlist that can be pointed back at your own network is not a containment boundary.

Built vs. planned

The allowlist, the capability mapping, the fail-closed evaluation, the alerting hook and the CLI all ship today, LLM-free and local-only. This configures the sandbox runtime that already ships; it does not reinvent one. The alert is deduplicated per repo and host, so a repeatedly reached host does not turn into a stream.

Last updated