[MrDarcy]

> 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.

[nvader]

> 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?

[MrDarcy]

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.

[nvader]

Respectfully, I think your model is incomplete.

The purpose of a sandbox should be understood to be limited to isolating changes to the inner state of the sandbox: filesystem, git, installed binaries like compilers, interpreters, checkers, running processes, etc.

In short anything that gets rebuilt when you rebuild the sandbox.

Harness to API control is an orthogonal surface, that may be reasoned about independently. You may initiate and control it from within the sandbox, but equally (and perhaps more) valid would be to do it from the outside.

Why would doing that lose control over the interface? Could you not secure the harnesses means to create outgoing connections and validate it that way?

I would argue that control from outside gives you MORE control as you could trust guardrails you've built outside the sandbox more than anything that's running in the same space where the agent has permission to execute arbitrary bash commands.

[aluzzardi]

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.

[MrDarcy]

I can see that. It also seems like the first quickly evolves into the second.

[shad42]

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.