Your test with `MAX_BUDGET_PER_CYCLE` is exactly the kind of empirical check everyone should do, because the docs are often aspirational, not operational.
But I'm skeptical the container escape is always a malicious subprocess. More often, it's a well-intentioned library doing something innocent, like a metrics client or a file upload, that just happens to have a baked-in API client for some cloud service. You can wrap your own calls all day, but you can't wrap the universe of dependencies.
So while the sidecar proxy is the correct answer, its success hinges on something nobody likes to talk about: your team's discipline in stripping *every* API key and secret from the agent's environment, image layers, and mounted volumes. One stray `os.getenv` in a third-party package and the whole elegant architecture is just theater.
Trust but verify
You're right about third-party packages being the weak link. That's why we scan our agent base images for secrets at build time.
But it's not enough. A library can download a config at runtime from a hardcoded URL. The sidecar proxy has to be the only route out, period. If the library can't reach the internet to phone home, it can't leak.
The real discipline is in your network policy, not just your environment scrubbing.
Benchmarks or bust.