Principle:OWASP Www project top 10 for large language model applications Sandbox Deployment
| Knowledge Sources | OWASP/www-project-top-10-for-large-language-model-applications |
|---|---|
| Domains | GenAI Red Team Testing, Containerized Sandboxing, LLM Application Security |
| Last Updated | 2026-02-14 |
Overview
Deploying containerized vulnerable LLM applications for controlled security testing enables red teams to safely exercise adversarial techniques without affecting production systems.
Description
Sandbox Deployment is the principle of creating isolated, reproducible, and purposefully vulnerable LLM application environments that red teams can attack without risk to production infrastructure. The problem it solves is twofold: first, it eliminates the legal and operational risk of testing against live systems; second, it provides a deterministic target whose behavior can be studied, reproduced, and compared across test runs.
The GenAI Red Team Handbook defines a standard architecture in which an Exploitation Environment (containing scripts, scanners, and agent tools) communicates with a Sandbox Container that hosts the target application. The sandbox container exposes two interfaces: a Gradio web UI on port 7860 for interactive testing and a FastAPI REST endpoint on port 8000 for programmatic access. Behind these interfaces sits the application logic, which may include mock services such as vector databases, object storage, and LLM API proxies.
Two sandbox types are provided:
- RAG_local: A comprehensive Retrieval-Augmented Generation sandbox that includes a mock Pinecone-compatible vector database, mock S3-compatible object storage, and a mock LLM API. This sandbox is designed for testing vulnerabilities such as embedding inversion, data poisoning, and retrieval manipulation.
- llm_local: A lightweight sandbox that mocks an OpenAI-compatible LLM API using Ollama for local inference. It is ideal for testing prompt injection and client-side interaction vulnerabilities without incurring external API costs.
Both sandbox types run inside Podman containers, providing rootless isolation and ensuring that any exploitation activity is fully contained.
Usage
Use this principle whenever:
- A red team exercise requires a target LLM application that can be freely attacked.
- Vulnerability researchers need a reproducible environment to develop and validate new attack techniques.
- Automated scanners need a stable endpoint to probe during CI/CD-integrated security testing.
- Training exercises require a safe environment for teaching adversarial testing methodologies.
Theoretical Basis
The sandbox deployment methodology follows a configure-build-launch-validate lifecycle:
1. CONFIGURE
- Select sandbox_type: "RAG_local" or "llm_local"
- Set configuration parameters (model name, port mappings, mock service options)
2. BUILD
- Invoke container build using Podman with the sandbox Containerfile
- Layer application code, mock services, and dependencies into the image
3. LAUNCH
- Start the container with port mappings:
host:7860 -> container:7860 (Gradio UI)
host:8000 -> container:8000 (FastAPI API)
- Initialize internal services (mock Vector DB, mock S3, Ollama model pull)
4. VALIDATE
- Health-check Gradio UI at http://localhost:7860
- Health-check FastAPI at http://localhost:8000/docs
- Confirm mock services respond to baseline queries
The architecture ensures a clear separation between the exploitation environment and the sandbox target. All attack traffic flows through well-defined network interfaces (ports 7860 and 8000), making it straightforward to capture, replay, and analyze attack patterns.
The containerized approach also supports parallel deployment of multiple sandboxes on different port ranges, enabling simultaneous testing of RAG and non-RAG configurations or A/B comparison of different system prompt configurations.