Mislav Ivanda, a developer-experience engineer at sandbox provider Daytona, draws a lesson from integrating its service with competing agent frameworks.
The shared operation
- Frameworks disagree on how to define an agent and how much workflow to prescribe. Their sandbox integrations repeatedly implement the same lifecycle: create an environment, run a task, then destroy it.
- An approval prompt or command allow list still leaves approved interpreters able to touch files and networks. A permitted command is broader than its name suggests.
- An embedded runtime can restrict generated code, but a tool call it exposes may execute in the host application with wider privileges.
Put a boundary around execution
- A separate sandboxed computer or VM can keep untrusted code and its file system apart from the host. Interact with it through a deliberately constrained interface.
- The boundary is only as strong as the credentials, network access, mounted data and host-side tools the sandbox retains. Ivanda’s claim that a compromised step need not compromise the app assumes those connections are properly restricted.
- Ivanda cites several frameworks’ moves toward sandboxes. The talk is a vendor’s account of their evolution, not a comparative security test.
Make the early architectural choice
- Prompts, models and framework features may be replaceable with tests and migration work. Durable execution is one feature he acknowledges is harder to add later.
- Tools written to assume a shared host file system are costly to relocate. Decide where agent code runs and how it reaches approved capabilities before those assumptions spread through the application.
“You defined what your model should use, but you didn’t define what your model can actually use.” — Mislav Ivanda