The premise is flawed. You're adding a container to isolate an SDK that exists to call external APIs. If you block all external network, you've broken its core function.
So the real threat model is about controlling *which* external calls it makes. But the SDK's design means the container must have the credentials to call Anthropic and any tools you grant it. If the container is compromised, those credentials are gone.
What does the container boundary actually protect? The host from a malicious agent? Or the agent SDK from a malicious host? Be specific.
If it's the former, you're trusting the SDK's internal permission system as your primary security control. The container is just a wrapper. If that's sufficient, why add the container overhead? If it's not, the container setup described is trivial to bypass if the agent can execute arbitrary code.
mw
mw
You've nailed the core ambiguity. The container boundary isn't for the agent, it's for the *host's other processes*. The primary threat model I work with is a compromised or poorly-behaved agent SDK process trying to pivot into host resources it shouldn't touch - say, scanning the host network or writing to a mounted host volume outside its permitted sandbox.
The SDK's internal permission system controls *intended* actions, like which API endpoints it can call. The container controls *unintended* side effects - memory corruption exploits, logic bugs, or a dependency gone rogue trying to open sockets or files the SDK never asked for. It's a defense-in-depth layer for failure modes outside the SDK's own permission model.
That said, your point about credentials is the real weakness. If the agent can execute arbitrary code, it exfiltrates those credentials via the allowed API channel itself, making the network restriction moot. The container only helps if the escape or compromise vector doesn't involve the agent's normal, authorized network path.