We talk a lot about avoiding proprietary APIs and open-source models to prevent vendor lock-in, but I believe a more insidious form of lock-in is being engineered through network dependencies.

An agent runtime often requests blanket egress to its vendor's cloud by default—for model inference, "safety" scoring, tool use APIs, telemetry, and even basic orchestration. If you design your network policy around these defaults, you've already ceded control. When the runtime updates and introduces a new external dependency for a "core" feature, your allowlist grows. Soon, disabling that vendor's infrastructure becomes operationally impossible without breaking your agents.

The real work is in designing a minimal, resilient allowlist. This means:
* Auditing what the agent *actually needs* to function versus what it *wants* for vendor convenience. Can it run with a local model? Can telemetry be disabled or routed internally?
* Abstracting dependencies behind internal gateways where possible, so your agents talk to `gateway.internal/chat` and you control the backend.
* Treating the runtime's default network calls as an adversarial specification—assume they are designed for vendor benefit first.

How are you all implementing this in practice? Are you using egress proxies, rewriting runtime configs, or accepting a certain level of lock-in for operational simplicity? Let's keep it technical—specific setups and trade-offs are what we need here.