Implementation guide
OWASP AISVS v1.01
Orchestration & Agentic Security · Component Isolation and Tool Authorization
Sandbox every tool
Verify that each tool/plugin executes in a least-privilege sandbox or is otherwise isolated from model operations.
OWASP AISVS v1.01, requirement 9.3.1
In plain English
Run each tool in its own sandbox with only the access it needs, apart from the model and from other tools. Tools handle untrusted input and run real code. When one goes wrong, the sandbox limits the damage.
What good looks like
- Each tool runs in its own process, container or function, and never inside the agent's process.
- Each has only the files, network destinations and credentials it needs.
- A compromised tool cannot reach other tools' data, the model host or the orchestrator's secrets.
- Tools that execute code get the strongest isolation.
How teams usually do it
- A container or serverless function per tool, with its own least-privilege role.
- For code execution, a purpose-built sandbox: gVisor, Firecracker microVMs, or WebAssembly runtimes, with no network by default.
- Operating system sandboxing (for example seccomp, Landlock, or the macOS sandbox) for tools that must run on a developer's machine.
Suggested evidence
- Tool deployment configuration.
- The permissions attached to each tool's identity.
- A test showing a tool cannot read another tool's files or credentials.
Common mistakes
- Running every tool in the agent's process with shared credentials.
- A code-execution tool with network access and the host's environment variables.
- Mounting the host's home directory or Docker socket into the sandbox.
Not sure which requirements apply to your system? Take the assessment, or browse every guide in this chapter.
Requirement text from the OWASP AI Security Verification Standard, licensed under CC BY-SA 4.0. This guidance is shared under the same licence.