Comment by MrDarcy
15 hours ago
> A lot of what an agent does doesn't need a sandbox at all: thinking, calling APIs, summarizing, waiting for CI.
I don’t get it. Calling an API requires a sandbox in most cases. The others could be abused in service of an un-sandboxed agent with API access.
If the harness is outside the sandbox then it’s just an ambiguous and confusing security model and boundary.
> Calling an API requires a sandbox in most cases.
I'm not following why this would this be the case? The purpose of calling the API is to get data or effect a state transition on some remote service, but I don't follow why the originating machine matters.
Or is your objection about auth?
The purpose of a sandbox is to control the interface between inside and outside of the sandbox. If you put the harness on the outside and connect it to a model and to an API then there’s no point in the sandbox. You don’t have any control over the interface.
Author here.
I think the confusion is that “agent” is used for two very different things:
- building an agent
- an “agent” product/runtime (Claude Code, etc)
In the first case, the model never executes anything. It just outputs something like “call this API”. Your code is the one doing it, with whatever validation you want. There’s no need for a sandbox there because there’s no arbitrary execution.
I can see that. It also seems like the first quickly evolves into the second.
No, for example a tool call calling an API. So the llm does not have access to the API keys, the tool does. For example an API call that fetches some data remotely and return it to the llm. You don’t need a sandbox for it. It’s faster and more efficient to keep this out of the sandbox.