EgressProof

Modern applications often appear self-contained during development but silently depend on external services at runtime. AI applications are especially vulnerable: model weights, tokenizers, configuration files, APIs, telemetry, or other resources may be fetched only when a particular feature is used. Everything works during development with internet access, but the same application can fail when deployed into a restricted, controlled, or offline environment. EgressProof turns these deployment assumptions into repeatable tests. Developers define a real application workflow, such as checking service health, uploading a document, and asking a question. EgressProof builds and runs the application under a restricted-egress boundary, executes the workflow step by step, captures runtime evidence, and generates both human-readable and machine-readable reports identifying where the workflow failed and which external dependency was observed. We demonstrate EgressProof using LocalDocQA, a containerized document question-answering application. With normal network access, all workflow steps succeed. Under restricted egress, health and document upload still succeed, but question answering fails. EgressProof captures evidence showing an attempted connection to huggingface.co: the SentenceTransformer embedding model was being downloaded only when the question-answering feature was first used. The generated EgressProof report is then provided to IBM Bob. Bob analyzes the evidence and repository, identifies the packaging problem, and repairs the Docker deployment so the required model is downloaded at build time and available locally at runtime. EgressProof then rebuilds the application and executes the exact same workflow under the same restriction. This time every step succeeds and EgressProof reports VERIFIED. The key idea is verification rather than assumption: detecting a problem is not enough, and applying a fix is not enough. EgressProof proves the repair by rerunning the same developer workflow against the same deployment boundary. The target users are developers, platform engineers, DevOps teams, and organizations deploying applications into controlled environments. The prototype currently demonstrates a DNS-blocked restricted-egress boundary; production versions could integrate stronger container, Kubernetes, firewall, or enterprise network policies. EgressProof creates a repeatable loop: Build → Restrict → Execute → Detect → Diagnose → Repair → Rebuild → Verify. Instead of discovering hidden dependencies after deployment, developers can discover and repair them before release.