Agent egress sandboxing

A coding agent runs inside your build infrastructure. To be useful it must resolve and fetch dependencies from public registries, call two internal services whose responses it needs, and write files that later jobs read. It also reads repository content that includes credentials scoped to those internal services, and customer data in fixtures. Assume its context can be influenced by content it reads, so treat its outbound requests as adversary chosen within whatever the boundary permits.

Design the egress decision procedure and give a bound.

You may not require human approval per request, because the agent makes thousands. You may not solve this with a destination allowlist alone: the destinations it needs are general purpose, since a registry accepts arbitrary search strings and an internal service accepts structured writes, so restricting where it talks does not restrict what it can say. You may not deny network access, because that is a decision not to ship the agent. You may not assume a classifier can tell a legitimate request from an encoding one. You may use a classifier as a signal, but the bound may not depend on its accuracy.

Hand in an algorithm that decides allow, deny or transform per request, with a stated upper bound on the number of secret bits one session can move to a destination the operator does not control. List every assumption the bound needs, including the ones you believe are shaky, and name the channel the bound does not cover. Then give the measurement. Describe a harness that empirically estimates the capacity of the residual channel, and say what estimated capacity would make you turn the agent off. Ties break toward the design that is honest about a wide residual channel over the one that claims a narrow bound by assuming away timing, ordering, or the agent's freedom to choose identifiers.