{ "slug": "sandboxed-execution", "category": "safety", "updated": "2026-08-22", "version": "1.0", "url": "https://santismm.com/en/patterns/sandboxed-execution", "canonical_url": "https://santismm.com/en/patterns/sandboxed-execution", "api_url": "https://santismm.com/api/patterns/sandboxed-execution", "urls": { "en": "https://santismm.com/en/patterns/sandboxed-execution", "es": "https://santismm.com/es/patterns/sandboxed-execution", "pt": "https://santismm.com/pt/patterns/sandboxed-execution", "fr": "https://santismm.com/fr/patterns/sandboxed-execution", "de": "https://santismm.com/de/patterns/sandboxed-execution", "ja": "https://santismm.com/ja/patterns/sandboxed-execution", "zh": "https://santismm.com/zh/patterns/sandboxed-execution" }, "evidence": { "evidenceLevel": "industry_observation", "confidenceLevel": "high", "sourceType": [ "industry_observation", "personal_experience", "paper" ] }, "technologies": [ "Containers", "microVMs (Firecracker / gVisor)", "Ephemeral workspaces", "Resource quotas and timeouts", "Scoped secret injection" ], "references": [ { "title": "OWASP — Top 10 for LLM Applications", "url": "https://genai.owasp.org/llm-top-10/" }, { "title": "MITRE ATLAS — Adversarial Threat Landscape for AI Systems", "url": "https://atlas.mitre.org/" }, { "title": "NIST — AI Risk Management Framework (AI RMF 1.0)", "url": "https://www.nist.gov/itl/ai-risk-management-framework" } ], "related": [ "least-privilege-tooling", "egress-allowlist", "recovery-strategy", "human-approval-gate" ], "locales": { "en": { "name": "Sandboxed Execution", "summary": "Run everything an agent generates or invokes inside a disposable, isolated environment with no ambient credentials, a bounded filesystem, controlled egress and hard resource caps. The sandbox is not there because the agent is malicious; it is there because the agent's input can be.", "definition": "Sandboxed execution is the practice of running agent-generated code and agent-invoked actions inside an isolated, ephemeral environment whose filesystem, network, credentials and resources are bounded by the host rather than by the agent, so that a hijacked or mistaken agent cannot affect anything outside it.", "problem": "An agent that executes code on the host inherits the host: its credentials, its filesystem, its network position. One successful injection or one confidently wrong command is then indistinguishable from a compromise of the machine.", "context": "Use it whenever an agent runs code, executes shell commands, installs packages or processes untrusted files. The threshold is low: if the agent can cause execution, the execution belongs in a sandbox.", "solution": [ "Make it ephemeral. Create the environment per task, destroy it after, and never carry state forward that the next task did not ask for. Persistence is how a one-off compromise becomes a foothold.", "Remove ambient credentials. Nothing in the environment should be usable simply because it is present; inject only the narrowly scoped secrets the task needs, for its duration.", "Bound the filesystem to the working set. Mount the repository or the input, nothing else, and mount read-only whatever does not need writing.", "Constrain egress inside the sandbox, not around it. The isolation and the network policy are the same control from the attacker's point of view, and a sandbox with open network is a jail with a phone.", "Cap resources — CPU, memory, disk, wall-clock, process count. Runaway consumption is the failure mode that arrives first and most often, usually without any adversary at all.", "Log what crossed the boundary: which files came in, which came out, which destinations were reached. The boundary is only useful if you can see what passed through it." ], "components": [ "An isolation primitive: container, microVM or equivalent, chosen for the strength the workload needs.", "Ephemeral lifecycle management, with destruction as the default rather than a cleanup step.", "A secret-injection path scoped to the task and its duration.", "A network policy applied inside the sandbox boundary.", "Resource quotas and timeouts, enforced by the host.", "Boundary logging: inputs, outputs and destinations." ], "benefits": [ "Converts 'the agent ran something bad' from an incident into a discarded container.", "Makes it safe to give an agent genuine execution ability, which is often what makes it useful at all.", "Bounds honest mistakes as well as attacks — the same control catches an infinite loop and an injected payload.", "Gives a clean place to observe: everything the task touched crossed one boundary." ], "risks": [ "Isolation weaker than assumed: a shared kernel is not a security boundary against determined escape, and treating a container as a microVM is a category error.", "Credentials smuggled in for convenience — one mounted config file undoes the whole pattern.", "Sandboxes that quietly become persistent because rebuilding is slow, so the ephemerality that carried the guarantee is gone.", "Escape via the shared surface that remains: mounted volumes, the orchestrator API, or the network the sandbox still reaches." ], "whenNot": [ "Read-only agents with no execution capability, where there is nothing to isolate and the cost buys nothing.", "Latency-critical inline paths where environment startup dominates the task and a narrower control — a restricted interpreter, a pure function — fits better.", "When the sandbox would need the very credentials it exists to withhold, which is a sign the task should be split rather than isolated." ], "examples": [ "A coding agent that clones into a fresh container per task, with the repository mounted, no cloud credentials present and egress limited to the package registry. A malicious dependency install destroys a container and nothing else.", "A data-analysis agent executing generated Python in a microVM with the input dataset mounted read-only, no network at all and a wall-clock cap. The generated code can be wrong; it cannot be expensive or exfiltrating.", "A document-processing agent that opens untrusted PDFs inside a disposable environment, because a parser exploit in an uploaded file is a real path to the host and the file arrived from outside." ], "kpis": [ { "metric": "Share of executions sandboxed", "note": "The coverage number. Anything running outside the sandbox is the actual security posture, regardless of what the sandboxed share does." }, { "metric": "Sandbox lifetime", "note": "How long environments live. Rising lifetimes mean ephemerality is eroding into persistence." }, { "metric": "Resource-cap hits", "note": "Tasks stopped by a quota or timeout. A useful mix of runaway generations and genuine limits set too tight." }, { "metric": "Secrets present at runtime", "note": "Count of credentials reachable inside the environment. The target is the minimum the task needs, and often zero." } ], "failureModes": [ "The convenience mount: a home directory, a credentials file or a socket mounted in so a task would stop failing.", "Persistent reuse: the environment stops being per-task because rebuilding costs too much, so state and compromise both survive.", "Open egress inside the boundary: strong isolation with a free network is containment against the filesystem only.", "Orchestrator reachability: the sandbox can call the API that manages sandboxes, which is escape by design rather than by exploit." ], "lessons": [ "Isolate execution before you trust generation. The sandbox is what makes it reasonable to let an agent run code at all.", "Ephemeral is the security property; isolation alone only postpones the problem.", "The credential that is not present cannot be stolen — and it is the only control that holds after an escape.", "Most sandbox activations are honest mistakes, not attacks. That is the pattern working, not evidence it was unnecessary." ], "faqs": [ { "q": "Is a container enough, or do I need a microVM?", "a": "It depends on what runs inside. For your own code with an injection risk, a hardened container with no credentials and constrained egress is usually proportionate. For arbitrary code from untrusted sources, assume the shared kernel can be escaped and use a microVM." }, { "q": "How does this differ from least-privilege tooling?", "a": "Least privilege bounds what the agent may ask for; the sandbox bounds what happens when something runs anyway. One governs the request, the other the environment it executes in, and agents that run code need both." }, { "q": "The sandbox slows everything down. Is it worth it?", "a": "Compare against the alternative cost, not against zero. Most of the latency is environment startup, which pools and pre-warmed images largely remove; the failure it prevents is a compromise of the host that runs the agent." } ] }, "es": { "name": "Ejecución en Sandbox", "summary": "Ejecuta todo lo que un agente genera o invoca dentro de un entorno aislado y desechable, sin credenciales ambientales, con sistema de ficheros acotado, salida controlada y límites duros de recursos. El sandbox no está porque el agente sea malicioso, sino porque su entrada puede serlo.", "definition": "La ejecución en sandbox es la práctica de correr el código generado por el agente y las acciones que invoca dentro de un entorno aislado y efímero cuyo sistema de ficheros, red, credenciales y recursos los acota el anfitrión y no el agente, de forma que un agente secuestrado o equivocado no pueda afectar a nada fuera de él.", "problem": "Un agente que ejecuta código en el anfitrión hereda el anfitrión: sus credenciales, su sistema de ficheros, su posición de red. Una inyección con éxito o un comando confiadamente equivocado pasan entonces a ser indistinguibles de un compromiso de la máquina.", "context": "Úsala siempre que un agente ejecute código, corra comandos de shell, instale paquetes o procese ficheros no confiables. El umbral es bajo: si el agente puede provocar ejecución, la ejecución va en un sandbox.", "solution": [ "Hazlo efímero. Crea el entorno por tarea, destrúyelo al terminar y no arrastres estado que la siguiente tarea no haya pedido. La persistencia es cómo un compromiso puntual se convierte en punto de apoyo.", "Elimina las credenciales ambientales. Nada del entorno debería ser utilizable solo por estar presente; inyecta únicamente los secretos acotados que la tarea necesita, durante lo que dure.", "Acota el sistema de ficheros al conjunto de trabajo. Monta el repositorio o la entrada y nada más, y monta en solo lectura todo lo que no necesite escritura.", "Restringe la salida dentro del sandbox, no alrededor. Desde el punto de vista del atacante el aislamiento y la política de red son el mismo control, y un sandbox con red abierta es una celda con teléfono.", "Limita recursos: CPU, memoria, disco, tiempo de reloj, número de procesos. El consumo desbocado es el modo de fallo que llega primero y más a menudo, normalmente sin ningún adversario.", "Registra lo que cruzó la frontera: qué ficheros entraron, cuáles salieron, a qué destinos se llegó. La frontera solo sirve si puedes ver qué pasó por ella." ], "components": [ "Una primitiva de aislamiento: contenedor, microVM o equivalente, elegida por la fuerza que la carga necesita.", "Gestión de ciclo de vida efímero, con la destrucción como comportamiento por defecto y no como paso de limpieza.", "Una vía de inyección de secretos acotada a la tarea y a su duración.", "Una política de red aplicada dentro de la frontera del sandbox.", "Cuotas de recursos y timeouts aplicados por el anfitrión.", "Registro de frontera: entradas, salidas y destinos." ], "benefits": [ "Convierte «el agente ejecutó algo malo» de incidente en contenedor descartado.", "Hace seguro dar a un agente capacidad real de ejecución, que suele ser justo lo que lo hace útil.", "Acota los errores honestos igual que los ataques: el mismo control atrapa un bucle infinito y un payload inyectado.", "Da un buen sitio donde observar: todo lo que la tarea tocó cruzó una única frontera." ], "risks": [ "Aislamiento más débil de lo supuesto: un kernel compartido no es una frontera de seguridad frente a un escape decidido, y tratar un contenedor como una microVM es un error de categoría.", "Credenciales coladas por comodidad: un solo fichero de configuración montado deshace el patrón entero.", "Sandboxes que se vuelven persistentes en silencio porque reconstruir es lento, y con ello desaparece la efimeridad que sostenía la garantía.", "Escape por la superficie compartida que queda: volúmenes montados, la API del orquestador o la red a la que el sandbox sigue llegando." ], "whenNot": [ "Agentes de solo lectura sin capacidad de ejecución, donde no hay nada que aislar y el coste no compra nada.", "Rutas en línea críticas en latencia donde el arranque del entorno domina la tarea y encaja mejor un control más estrecho: un intérprete restringido, una función pura.", "Cuando el sandbox necesitaría justo las credenciales que existe para retener, que es señal de que la tarea hay que partirla en lugar de aislarla." ], "examples": [ "Un agente de programación que clona en un contenedor nuevo por tarea, con el repositorio montado, sin credenciales de nube presentes y con salida limitada al registro de paquetes. Una instalación de dependencia maliciosa destruye un contenedor y nada más.", "Un agente de análisis de datos que ejecuta Python generado en una microVM con el dataset montado en solo lectura, sin red alguna y con límite de tiempo de reloj. El código generado puede estar mal; no puede salir caro ni exfiltrar.", "Un agente de procesamiento documental que abre PDFs no confiables dentro de un entorno desechable, porque un exploit del parser en un fichero subido es una vía real al anfitrión y el fichero vino de fuera." ], "kpis": [ { "metric": "Porcentaje de ejecuciones en sandbox", "note": "El número de cobertura. Lo que corre fuera del sandbox es la postura de seguridad real, diga lo que diga la parte que sí está dentro." }, { "metric": "Vida del sandbox", "note": "Cuánto duran los entornos. Vidas crecientes significan que la efimeridad se está erosionando hacia la persistencia." }, { "metric": "Choques con límites de recursos", "note": "Tareas detenidas por una cuota o un timeout. Una mezcla útil de generaciones desbocadas y límites legítimos puestos demasiado estrechos." }, { "metric": "Secretos presentes en ejecución", "note": "Número de credenciales alcanzables dentro del entorno. El objetivo es el mínimo que la tarea necesite, y a menudo cero." } ], "failureModes": [ "El montaje por comodidad: un directorio home, un fichero de credenciales o un socket montados para que una tarea dejara de fallar.", "Reutilización persistente: el entorno deja de ser por tarea porque reconstruir cuesta demasiado, así que sobreviven el estado y el compromiso.", "Salida abierta dentro de la frontera: aislamiento fuerte con red libre es contención solo frente al sistema de ficheros.", "Alcance al orquestador: el sandbox puede llamar a la API que gestiona sandboxes, lo que es escapar por diseño y no por exploit." ], "lessons": [ "Aísla la ejecución antes de confiar en la generación. El sandbox es lo que hace razonable dejar que un agente ejecute código.", "Lo efímero es la propiedad de seguridad; el aislamiento por sí solo únicamente aplaza el problema.", "La credencial que no está presente no se puede robar, y es el único control que aguanta después de un escape.", "La mayoría de activaciones del sandbox son errores honestos, no ataques. Eso es el patrón funcionando, no la prueba de que sobraba." ], "faqs": [ { "q": "¿Basta un contenedor o necesito una microVM?", "a": "Depende de qué corre dentro. Para código propio con riesgo de inyección, un contenedor endurecido sin credenciales y con salida acotada suele ser proporcionado. Para código arbitrario de origen no confiable, asume que el kernel compartido se puede escapar y usa una microVM." }, { "q": "¿En qué se diferencia del mínimo privilegio en herramientas?", "a": "El mínimo privilegio acota lo que el agente puede pedir; el sandbox acota lo que ocurre cuando algo se ejecuta igualmente. Uno gobierna la petición y el otro el entorno donde se ejecuta, y un agente que corre código necesita ambos." }, { "q": "El sandbox lo ralentiza todo, ¿compensa?", "a": "Compáralo con el coste de la alternativa, no con cero. Casi toda la latencia es el arranque del entorno, que los pools y las imágenes precalentadas eliminan en buena parte; el fallo que evita es un compromiso del anfitrión que ejecuta el agente." } ] }, "pt": { "name": "Execução em Sandbox", "summary": "Execute tudo o que um agente gera ou invoca dentro de um ambiente isolado e descartável, sem credenciais ambientais, com sistema de arquivos limitado, saída controlada e limites rígidos de recursos. O sandbox não existe porque o agente seja malicioso, mas porque a entrada dele pode ser.", "definition": "Execução em sandbox é a prática de rodar o código gerado pelo agente e as ações que ele invoca dentro de um ambiente isolado e efêmero cujo sistema de arquivos, rede, credenciais e recursos são limitados pelo host e não pelo agente, de modo que um agente sequestrado ou equivocado não afete nada fora dele.", "problem": "Um agente que executa código no host herda o host: suas credenciais, seu sistema de arquivos, sua posição de rede. Uma injeção bem-sucedida ou um comando confiantemente errado passam a ser indistinguíveis de um comprometimento da máquina.", "context": "Use sempre que um agente executar código, rodar comandos de shell, instalar pacotes ou processar arquivos não confiáveis. O limiar é baixo: se o agente pode provocar execução, a execução vai para um sandbox.", "solution": [ "Torne-o efêmero. Crie o ambiente por tarefa, destrua ao final e não carregue estado que a próxima tarefa não pediu. A persistência é como um comprometimento pontual vira ponto de apoio.", "Remova as credenciais ambientais. Nada no ambiente deveria ser utilizável só por estar presente; injete apenas os segredos restritos de que a tarefa precisa, pelo tempo dela.", "Limite o sistema de arquivos ao conjunto de trabalho. Monte o repositório ou a entrada e nada mais, e monte como somente leitura tudo o que não precisa de escrita.", "Restrinja a saída dentro do sandbox, não em volta dele. Do ponto de vista do atacante, o isolamento e a política de rede são o mesmo controle, e um sandbox com rede aberta é uma cela com telefone.", "Limite recursos: CPU, memória, disco, tempo de relógio, número de processos. O consumo descontrolado é o modo de falha que chega primeiro e com mais frequência, normalmente sem adversário algum.", "Registre o que cruzou a fronteira: quais arquivos entraram, quais saíram, quais destinos foram alcançados. A fronteira só é útil se você puder ver o que passou por ela." ], "components": [ "Uma primitiva de isolamento: contêiner, microVM ou equivalente, escolhida pela força que a carga exige.", "Gestão de ciclo de vida efêmero, com a destruição como comportamento padrão e não como etapa de limpeza.", "Um caminho de injeção de segredos restrito à tarefa e à duração dela.", "Uma política de rede aplicada dentro da fronteira do sandbox.", "Cotas de recursos e timeouts aplicados pelo host.", "Registro de fronteira: entradas, saídas e destinos." ], "benefits": [ "Converte “o agente executou algo ruim” de incidente em contêiner descartado.", "Torna seguro dar a um agente capacidade real de execução, que costuma ser justamente o que o torna útil.", "Limita erros honestos tanto quanto ataques: o mesmo controle pega um laço infinito e um payload injetado.", "Dá um bom lugar para observar: tudo o que a tarefa tocou cruzou uma única fronteira." ], "risks": [ "Isolamento mais fraco do que o suposto: um kernel compartilhado não é fronteira de segurança contra um escape determinado, e tratar um contêiner como microVM é um erro de categoria.", "Credenciais contrabandeadas por conveniência: um único arquivo de configuração montado desfaz o padrão inteiro.", "Sandboxes que ficam persistentes em silêncio porque reconstruir é lento, e com isso some a efemeridade que sustentava a garantia.", "Escape pela superfície compartilhada que resta: volumes montados, a API do orquestrador ou a rede que o sandbox ainda alcança." ], "whenNot": [ "Agentes somente leitura sem capacidade de execução, onde não há o que isolar e o custo não compra nada.", "Caminhos em linha críticos em latência onde a inicialização do ambiente domina a tarefa e um controle mais estreito cabe melhor: um interpretador restrito, uma função pura.", "Quando o sandbox precisaria justamente das credenciais que ele existe para reter, o que é sinal de que a tarefa deve ser dividida em vez de isolada." ], "examples": [ "Um agente de programação que clona em um contêiner novo por tarefa, com o repositório montado, sem credenciais de nuvem presentes e com saída limitada ao registry de pacotes. Uma instalação de dependência maliciosa destrói um contêiner e nada mais.", "Um agente de análise de dados que executa Python gerado em uma microVM com o dataset montado somente leitura, sem rede alguma e com limite de tempo de relógio. O código gerado pode estar errado; não pode sair caro nem exfiltrar.", "Um agente de processamento de documentos que abre PDFs não confiáveis dentro de um ambiente descartável, porque um exploit de parser em um arquivo enviado é um caminho real até o host e o arquivo veio de fora." ], "kpis": [ { "metric": "Percentual de execuções em sandbox", "note": "O número de cobertura. O que roda fora do sandbox é a postura de segurança real, independentemente do que a parte de dentro faça." }, { "metric": "Tempo de vida do sandbox", "note": "Quanto duram os ambientes. Vidas crescentes significam que a efemeridade está erodindo para persistência." }, { "metric": "Batidas em limites de recursos", "note": "Tarefas interrompidas por cota ou timeout. Uma mistura útil de gerações descontroladas e limites legítimos apertados demais." }, { "metric": "Segredos presentes em execução", "note": "Número de credenciais alcançáveis dentro do ambiente. O alvo é o mínimo de que a tarefa precisa, e muitas vezes zero." } ], "failureModes": [ "A montagem por conveniência: um diretório home, um arquivo de credenciais ou um socket montados para que uma tarefa parasse de falhar.", "Reutilização persistente: o ambiente deixa de ser por tarefa porque reconstruir custa demais, então estado e comprometimento sobrevivem.", "Saída aberta dentro da fronteira: isolamento forte com rede livre é contenção apenas contra o sistema de arquivos.", "Alcance ao orquestrador: o sandbox consegue chamar a API que gerencia sandboxes, o que é escapar por design e não por exploit." ], "lessons": [ "Isole a execução antes de confiar na geração. O sandbox é o que torna razoável deixar um agente rodar código.", "O efêmero é a propriedade de segurança; o isolamento sozinho apenas adia o problema.", "A credencial que não está presente não pode ser roubada — e é o único controle que resiste depois de um escape.", "A maioria das ativações do sandbox são erros honestos, não ataques. Isso é o padrão funcionando, não prova de que era desnecessário." ], "faqs": [ { "q": "Um contêiner basta ou preciso de microVM?", "a": "Depende do que roda dentro. Para código próprio com risco de injeção, um contêiner endurecido sem credenciais e com saída limitada costuma ser proporcional. Para código arbitrário de origem não confiável, assuma que o kernel compartilhado pode ser escapado e use uma microVM." }, { "q": "Em que difere de ferramentas com privilégio mínimo?", "a": "O privilégio mínimo limita o que o agente pode pedir; o sandbox limita o que acontece quando algo executa mesmo assim. Um governa a requisição, o outro o ambiente em que ela roda, e agentes que executam código precisam dos dois." }, { "q": "O sandbox deixa tudo mais lento. Compensa?", "a": "Compare com o custo da alternativa, não com zero. Quase toda a latência é a inicialização do ambiente, que pools e imagens pré-aquecidas removem em boa parte; a falha que ele evita é um comprometimento do host que roda o agente." } ] }, "fr": { "name": "Exécution en bac à sable", "summary": "Exécutez tout ce qu'un agent génère ou invoque au sein d'un environnement isolé et jetable, sans identifiants ambiants, avec un système de fichiers restreint, une sortie contrôlée et des limites strictes de ressources. Le bac à sable n'est pas là parce que l'agent est malveillant, mais parce que les entrées de l'agent peuvent l'être.", "definition": "L'exécution en bac à sable consiste à exécuter le code généré par l'agent et les actions invoquées par celui-ci au sein d'un environnement isolé et éphémère dont le système de fichiers, le réseau, les identifiants et les ressources sont limités par l'hôte plutôt que par l'agent, afin qu'un agent compromis ou erroné ne puisse rien affecter en dehors de cet environnement.", "problem": "Un agent qui exécute du code sur l'hôte hérite de cet hôte : ses identifiants, son système de fichiers, sa position réseau. Une seule injection réussie ou une seule commande erronée mais exécutée avec assurance devient alors impossible à distinguer d'une compromission de la machine.", "context": "Utilisez-le dès qu'un agent exécute du code, lance des commandes shell, installe des paquets ou traite des fichiers non approuvés. Le seuil est bas : si l'agent peut déclencher une exécution, cette exécution doit se faire dans un bac à sable.", "solution": [ "Rendez-le éphémère. Créez l'environnement par tâche, détruisez-le ensuite, et ne transmettez jamais un état que la tâche suivante n'a pas demandé. C'est par la persistance qu'une compromission ponctuelle devient un point d'ancrage.", "Supprimez les identifiants ambiants. Rien dans l'environnement ne devrait être utilisable simplement parce qu'il s'y trouve ; n'injectez que les secrets strictement nécessaires à la tâche, pour sa seule durée.", "Limitez le système de fichiers à l'ensemble de travail. Montez le dépôt ou l'entrée, rien d'autre, et montez en lecture seule tout ce qui n'a pas besoin d'être écrit.", "Contraignez les flux de sortie à l'intérieur du bac à sable, pas autour. L'isolation et la politique réseau représentent le même contrôle du point de vue de l'attaquant, et un bac à sable avec un réseau ouvert est une prison avec un téléphone.", "Limitez les ressources — CPU, mémoire, disque, temps d'exécution réel, nombre de processus. La consommation incontrôlée est le mode de défaillance qui survient en premier et le plus souvent, généralement sans le moindre adversaire.", "Journalisez ce qui a franchi la limite : quels fichiers sont entrés, lesquels sont sortis, quelles destinations ont été atteintes. La limite n'est utile que si vous pouvez voir ce qui l'a traversée." ], "components": [ "Une primitive d'isolation : conteneur, microVM ou équivalent, choisie selon le niveau de robustesse requis par la charge de travail.", "Une gestion du cycle de vie éphémère, avec la destruction comme comportement par défaut plutôt que comme simple étape de nettoyage.", "Un mécanisme d'injection de secrets limité à la tâche et à sa durée.", "Une politique réseau appliquée à l'intérieur des limites du bac à sable.", "Des quotas de ressources et des délais d'expiration (timeouts), appliqués par l'hôte.", "Une journalisation aux limites : entrées, sorties et destinations." ], "benefits": [ "Transforme l'événement « l'agent a exécuté quelque chose de malveillant » d'un incident grave en un conteneur jeté.", "Permet de donner en toute sécurité une véritable capacité d'exécution à un agent, ce qui est souvent indispensable pour le rendre utile.", "Limite aussi bien les erreurs involontaires que les attaques — le même contrôle intercepte une boucle infinie et une charge utile injectée.", "Offre un espace d'observation clair : tout ce que la tâche a touché a franchi une seule et unique limite." ], "risks": [ "Une isolation plus faible que prévu : un noyau partagé ne constitue pas une barrière de sécurité contre une évasion déterminée, et traiter un conteneur comme une microVM est une erreur de catégorie.", "Des identifiants introduits en douce par commodité — un seul fichier de configuration monté annule tout l'intérêt du modèle.", "Des bacs à sable qui deviennent discrètement persistants parce que la reconstruction est lente, faisant ainsi disparaître le caractère éphémère qui garantissait la sécurité.", "Une évasion via la surface partagée restante : volumes montés, API de l'orchestrateur ou réseau que le bac à sable peut encore atteindre." ], "whenNot": [ "Les agents en lecture seule sans capacité d'exécution, où il n'y a rien à isoler et où le coût n'apporte aucun bénéfice.", "Les parcours en ligne critiques en termes de latence, où le démarrage de l'environnement domine la tâche et où un contrôle plus restreint — un interpréteur limité, une fonction pure — est plus adapté.", "Lorsque le bac à sable aurait besoin des identifiants mêmes qu'il a pour but de retenir, ce qui indique que la tâche devrait être divisée plutôt qu'isolée." ], "examples": [ "Un agent de codage qui clone un dépôt dans un conteneur neuf par tâche, avec le dépôt monté, aucun identifiant cloud présent et des flux de sortie limités au registre de paquets. L'installation d'une dépendance malveillante détruit le conteneur et rien d'autre.", "Un agent d'analyse de données exécutant du code Python généré dans une microVM avec le jeu de données d'entrée monté en lecture seule, aucun réseau et une limite de temps d'exécution réel. Le code généré peut être erroné ; il ne peut pas être coûteux ni exfiltrer de données.", "Un agent de traitement de documents qui ouvre des PDF non approuvés dans un environnement jetable, car une faille d'analyseur dans un fichier téléversé constitue une véritable voie d'accès à l'hôte et le fichier provient de l'extérieur." ], "kpis": [ { "metric": "Part des exécutions exécutées en bac à sable", "note": "Le taux de couverture. Tout ce qui s'exécute en dehors du bac à sable représente la posture de sécurité réelle, indépendamment de ce que fait la part exécutée en bac à sable." }, { "metric": "Durée de vie du bac à sable", "note": "La durée de vie des environnements. Des durées de vie croissantes signifient que le caractère éphémère s'érode au profit de la persistance." }, { "metric": "Dépassements des limites de ressources", "note": "Tâches arrêtées par un quota ou un délai d'expiration. Un indicateur utile mêlant générations incontrôlées et limites réelles définies de manière trop stricte." }, { "metric": "Secrets présents au moment de l'exécution", "note": "Nombre d'identifiants accessibles à l'intérieur de l'environnement. L'objectif est le strict minimum requis par la tâche, et souvent zéro." } ], "failureModes": [ "Le montage de commodité : un répertoire personnel, un fichier d'identifiants ou un socket monté pour qu'une tâche cesse d'échouer.", "La réutilisation persistante : l'environnement cesse d'être propre à chaque tâche car la reconstruction coûte trop cher, de sorte que l'état et la compromission survivent tous deux.", "Flux de sortie ouverts à l'intérieur de la limite : une isolation forte avec un réseau libre n'est qu'un confinement limité au système de fichiers.", "Accessibilité de l'orchestrateur : le bac à sable peut appeler l'API qui gère les bacs à sable, ce qui constitue une évasion par conception plutôt que par faille." ], "lessons": [ "Isolez l'exécution avant de faire confiance à la génération. C'est le bac à sable qui permet de laisser un agent exécuter du code de manière raisonnable.", "Le caractère éphémère est la véritable propriété de sécurité ; l'isolation seule ne fait que différer le problème.", "L'identifiant qui n'est pas présent ne peut pas être volé — et c'est le seul contrôle qui tient après une évasion.", "La plupart des activations de bac à sable sont des erreurs involontaires, pas des attaques. C'est la preuve que le modèle fonctionne, et non qu'il était inutile." ], "faqs": [ { "q": "Un conteneur est-il suffisant ou ai-je besoin d'une microVM ?", "a": "Cela dépend de ce qui s'y exécute. Pour votre propre code présentant un risque d'injection, un conteneur durci sans identifiants et avec des flux de sortie restreints est généralement proportionné. Pour du code arbitraire provenant de sources non approuvées, partez du principe que le noyau partagé peut être contourné et utilisez une microVM." }, { "q": "En quoi cela diffère-t-il des outils de moindre privilège ?", "a": "Le moindre privilège limite ce que l'agent peut demander ; le bac à sable limite ce qui se passe lorsque quelque chose s'exécute malgré tout. L'un régit la requête, l'autre régit l'environnement dans lequel elle s'exécute, et les agents qui exécutent du code ont besoin des deux." }, { "q": "Le bac à sable ralentit tout. Est-ce que cela en vaut la peine ?", "a": "Comparez par rapport au coût de l'alternative, pas par rapport à zéro. La majeure partie de la latence provient du démarrage de l'environnement, ce que les pools et les images préchauffées éliminent en grande partie ; la défaillance qu'il prévient est une compromission de l'hôte qui exécute l'agent." } ] }, "de": { "name": "Sandbox-Ausführung", "summary": "Führen Sie alles, was ein Agent generiert oder aufruft, in einer verworfenen, isolierten Umgebung ohne implizite Anmeldedaten (Ambient Credentials), mit einem begrenzten Dateisystem, kontrolliertem Egress und harten Ressourcenlimits aus. Die Sandbox existiert nicht, weil der Agent bösartig ist, sondern weil es die Eingaben des Agenten sein können.", "definition": "Sandbox-Ausführung bezeichnet die Praxis, von Agenten generierten Code und von Agenten aufgerufene Aktionen in einer isolierten, flüchtigen (ephemeren) Umgebung auszuführen, deren Dateisystem, Netzwerk, Anmeldedaten und Ressourcen durch den Host statt durch den Agenten begrenzt sind, sodass ein gekaperter oder fehlerhafter Agent nichts außerhalb dieser Umgebung beeinflussen kann.", "problem": "Ein Agent, der Code auf dem Host ausführt, erbt dessen Umgebung: seine Anmeldedaten, sein Dateisystem und seine Netzwerkposition. Eine einzige erfolgreiche Injection oder ein einziger selbstbewusst falscher Befehl ist dann nicht mehr von einer Kompromittierung des Systems zu unterscheiden.", "context": "Nutzen Sie dies immer dann, wenn ein Agent Code ausführt, Shell-Befehle ausführt, Pakete installiert oder nicht vertrauenswürdige Dateien verarbeitet. Die Hürde ist niedrig: Wenn der Agent eine Ausführung bewirken kann, gehört diese Ausführung in eine Sandbox.", "solution": [ "Machen Sie es flüchtig (ephemer). Erstellen Sie die Umgebung pro Task, zerstören Sie sie danach und übertragen Sie niemals einen Zustand, der vom nächsten Task nicht angefordert wurde. Persistenz ist der Weg, wie aus einer einmaligen Kompromittierung ein dauerhafter Zugang wird.", "Entfernen Sie implizite Anmeldedaten (Ambient Credentials). Nichts in der Umgebung sollte nutzbar sein, nur weil es vorhanden ist; injizieren Sie nur die eng begrenzten Secrets, die der Task für seine Dauer benötigt.", "Begrenzen Sie das Dateisystem auf das Working Set. Mounten Sie das Repository oder den Input und nichts anderes, und mounten Sie alles schreibgeschützt (read-only), was nicht beschrieben werden muss.", "Beschränken Sie den Egress innerhalb der Sandbox, nicht um sie herum. Die Isolation und die Netzwerkrichtlinie sind aus Sicht des Angreifers dieselbe Kontrollmaßnahme, und eine Sandbox mit offenem Netzwerk ist wie ein Gefängnis mit Telefon.", "Begrenzen Sie die Ressourcen – CPU, Arbeitsspeicher, Festplatte, Laufzeit (Wall-Clock), Prozessanzahl. Unkontrollierter Ressourcenverbrauch ist das Fehlerszenario, das zuerst und am häufigsten auftritt, meist ganz ohne Angreifer.", "Protokollieren Sie, was die Grenze überschritten hat: Welche Dateien kamen hinein, welche gingen heraus, welche Ziele wurden erreicht. Die Grenze ist nur dann nützlich, wenn Sie sehen können, was sie passiert hat." ], "components": [ "Ein Isolations-Primitiv: Container, MicroVM oder Ähnliches, ausgewählt nach der für den Workload erforderlichen Stärke.", "Ephemeres Lifecycle-Management, bei dem die Zerstörung der Standardzustand und nicht nur ein Bereinigungsschritt ist.", "Ein Pfad zur Secret-Injektion, der auf den Task und dessen Dauer begrenzt ist.", "Eine Netzwerkrichtlinie, die innerhalb der Sandbox-Grenze angewendet wird.", "Ressourcen-Quotas und Timeouts, die vom Host erzwungen werden.", "Grenzprotokollierung (Boundary Logging): Eingaben, Ausgaben und Ziele." ], "benefits": [ "Verwandelt das Szenario „Der Agent hat etwas Schädliches ausgeführt“ von einem Sicherheitsvorfall in einen verworfenen Container.", "Ermöglicht es, einem Agenten echte Ausführungsfähigkeiten zu geben, was ihn oft überhaupt erst nützlich macht.", "Begrenzt sowohl ehrliche Fehler als auch Angriffe – dieselbe Kontrollmaßnahme fängt eine Endlosschleife ebenso ab wie ein injiziertes Payload.", "Bietet einen sauberen Ort für die Beobachtung: Alles, was der Task berührt hat, hat genau eine Grenze überschritten." ], "risks": [ "Schwächere Isolation als angenommen: Ein gemeinsam genutzter Kernel ist keine Sicherheitsgrenze gegen einen entschlossenen Ausbruch (Escape), und einen Container wie eine MicroVM zu behandeln, ist ein Kategorienfehler.", "Aus Bequemlichkeit eingeschmuggelte Anmeldedaten – eine einzige gemountete Konfigurationsdatei macht das gesamte Pattern zunichte.", "Sandboxes, die unbemerkt persistent werden, weil der Neuaufbau zu langsam ist, wodurch die Flüchtigkeit (Ephemerality), die die Garantie bot, verloren geht.", "Ausbruch über die verbleibende gemeinsame Schnittstelle: gemountete Volumes, die Orchestrator-API oder das Netzwerk, das die Sandbox noch erreicht." ], "whenNot": [ "Read-only-Agenten ohne Ausführungsfähigkeit, bei denen es nichts zu isolieren gibt und die Kosten keinen Nutzen bringen.", "Latenzkritische Inline-Pfade, bei denen der Start der Umgebung den Task dominiert und eine engere Kontrolle – wie ein eingeschränkter Interpreter oder eine reine Funktion – besser geeignet ist.", "Wenn die Sandbox genau die Anmeldedaten benötigen würde, die sie eigentlich vorenthalten soll – was ein Zeichen dafür ist, dass der Task eher aufgeteilt als isoliert werden sollte." ], "examples": [ "Ein Coding-Agent, der für jeden Task in einen frischen Container klont, wobei das Repository gemountet ist, keine Cloud-Anmeldedaten vorhanden sind und der Egress auf die Paketregistrierung beschränkt ist. Die Installation einer bösartigen Abhängigkeit zerstört lediglich den Container und sonst nichts.", "Ein Datenanalyse-Agent, der generierten Python-Code in einer MicroVM ausführt, wobei der Eingabedatensatz schreibgeschützt gemountet ist, keinerlei Netzwerkverbindung besteht und ein Laufzeitlimit (Wall-Clock Cap) gilt. Der generierte Code kann fehlerhaft sein; er kann jedoch weder teuer sein noch Daten exfiltrieren.", "Ein Dokumentenverarbeitungs-Agent, der nicht vertrauenswürdige PDFs in einer Einwegumgebung öffnet, da ein Parser-Exploit in einer hochgeladenen Datei ein realer Pfad zum Host ist und die Datei von außen stammt." ], "kpis": [ { "metric": "Anteil der in einer Sandbox ausgeführten Prozesse", "note": "Die Abdeckungsrate. Alles, was außerhalb der Sandbox läuft, bestimmt das tatsächliche Sicherheitsniveau, unabhängig davon, was der in der Sandbox ausgeführte Anteil tut." }, { "metric": "Lebensdauer der Sandbox", "note": "Wie lange Umgebungen existieren. Steigende Lebensdauern bedeuten, dass die Flüchtigkeit (Ephemerality) schleichend in Persistenz übergeht." }, { "metric": "Erreichen von Ressourcenlimits", "note": "Tasks, die durch ein Kontingent oder ein Timeout gestoppt wurden. Eine nützliche Mischung aus unkontrollierten Generierungen und tatsächlich zu eng gesetzten Limits." }, { "metric": "Zur Laufzeit vorhandene Secrets", "note": "Anzahl der innerhalb der Umgebung erreichbaren Anmeldedaten. Das Ziel ist das für den Task erforderliche Minimum, oft null." } ], "failureModes": [ "Das Bequemlichkeits-Mounting: Ein Home-Verzeichnis, eine Anmeldedatendatei oder ein Socket, die gemountet werden, damit ein Task nicht mehr fehlschlägt.", "Persistente Wiederverwendung: Die Umgebung wird nicht mehr pro Task erstellt, weil der Neuaufbau zu viel kostet, sodass sowohl der Zustand als auch eine Kompromittierung überdauern.", "Offener Egress innerhalb der Grenze: Eine starke Isolation bei freiem Netzwerkzugriff schützt lediglich das Dateisystem.", "Erreichbarkeit des Orchestrators: Die Sandbox kann die API aufrufen, die die Sandboxes verwaltet – was ein systembedingter Ausbruch (Escape by Design) statt eines Exploits ist." ], "lessons": [ "Isolieren Sie die Ausführung, bevor Sie der Generierung vertrauen. Erst die Sandbox macht es überhaupt vertretbar, einen Agenten Code ausführen zu lassen.", "Flüchtigkeit (Ephemerality) ist die eigentliche Sicherheitseigenschaft; Isolation allein verschiebt das Problem nur nach hinten.", "Anmeldedaten, die nicht vorhanden sind, können nicht gestohlen werden – und das ist die einzige Kontrollmaßnahme, die nach einem Ausbruch noch greift.", "Die meisten Sandbox-Aktivierungen sind ehrliche Fehler, keine Angriffe. Das zeigt, dass das Pattern funktioniert, und ist kein Beweis dafür, dass es unnötig war." ], "faqs": [ { "q": "Reicht ein Container aus oder benötige ich eine MicroVM?", "a": "Das hängt davon ab, was darin ausgeführt wird. Für eigenen Code mit einem Injection-Risiko ist ein gehärteter Container ohne Anmeldedaten und mit eingeschränktem Egress meist verhältnismäßig. Für beliebigen Code aus nicht vertrauenswürdigen Quellen sollten Sie davon ausgehen, dass aus dem gemeinsam genutzten Kernel ausgebrochen werden kann, und eine MicroVM verwenden." }, { "q": "Wie unterscheidet sich dies von Least-Privilege-Tooling?", "a": "Least Privilege (das Prinzip der minimalen Rechte) begrenzt, was der Agent anfordern darf; die Sandbox begrenzt, was passiert, wenn dennoch etwas ausgeführt wird. Das eine regelt die Anfrage, das andere die Umgebung, in der sie ausgeführt wird – und Agenten, die Code ausführen, benötigen beides." }, { "q": "Die Sandbox verlangsamt alles. Lohnt sich das?", "a": "Vergleichen Sie dies mit den Alternativkosten, nicht mit null. Der Großteil der Latenz entsteht beim Starten der Umgebung, was durch Pools und vorgewärmte Images weitgehend vermieden werden kann. Der Fehler, den sie verhindert, ist eine Kompromittierung des Hosts, auf dem der Agent läuft." } ] }, "ja": { "name": "サンドボックス実行", "summary": "エージェントが生成または呼び出すものはすべて、環境固有の資格情報（ambient credentials）を持たず、制限されたファイルシステム、制御された送信（egress）、および厳格なリソース制限を備えた、使い捨ての隔離環境内で実行します。サンドボックスが存在するのは、エージェントが悪意を持っているからではなく、エージェントへの入力が悪意を持っている可能性があるからです。", "definition": "サンドボックス実行とは、エージェントが生成したコードやエージェントが呼び出したアクションを、隔離されたエフェメラル（一時的）な環境内で実行する手法です。そのファイルシステム、ネットワーク、資格情報、およびリソースは、エージェントではなくホストによって制限されるため、乗っ取られたり誤動作したりしたエージェントが外部に影響を与えるのを防ぐことができます。", "problem": "ホスト上でコードを実行するエージェントは、ホストの資格情報、ファイルシステム、ネットワーク上の位置などをそのまま継承します。そのため、インジェクションが1回成功したり、自信満々に間違ったコマンドが1回実行されたりするだけで、マシン全体の侵害と区別がつかなくなります。", "context": "エージェントがコードを実行したり、シェルコマンドを実行したり、パッケージをインストールしたり、信頼できないファイルを処理したりする場合は、常にこれを使用します。基準は低く設定すべきです。エージェントが実行を引き起こす可能性があるなら、その実行はサンドボックス内で行われるべきです。", "solution": [ "エフェメラル（一時的）にします。タスクごとに環境を作成し、終了後に破棄します。次のタスクが要求していない状態（ステート）は決して引き継がないでください。永続化こそが、単発の侵害を足がかりへと変えてしまう原因です。", "環境固有の資格情報（ambient credentials）を排除します。環境内に存在するからという理由だけで利用できるものは何もない状態にすべきです。タスクが必要とする、範囲を厳密に限定したシークレットのみを、その実行期間中だけ注入します。", "ファイルシステムを作業セットに制限します。リポジトリや入力のみをマウントし、それ以外はマウントしません。また、書き込みが不要なものはすべて読み取り専用でマウントします。", "サンドボックスの周囲ではなく、サンドボックスの「内部」で送信（egress）を制限します。攻撃者の視点からは、隔離とネットワークポリシーは同一のコントロールであり、ネットワークが開放されたサンドボックスは「電話のある刑務所」と同じです。", "リソース（CPU、メモリ、ディスク、実時間、プロセス数）に上限を設けます。リソースの暴走消費は、攻撃者がいなくても、最も早く、最も頻繁に発生する障害モードです。", "境界を越えたもの（どのファイルが入り、どのファイルが出ていき、どの宛先にアクセスしたか）をログに記録します。境界は、そこを通過したものを可視化できて初めて役に立ちます。" ], "components": [ "隔離プリミティブ：ワークロードが必要とする強度に応じて選択された、コンテナ、microVM、またはそれと同等のもの。", "クリーンアップステップとしてではなく、デフォルトで破棄を行うエフェメラルなライフサイクル管理。", "タスクとその実行期間にスコープを限定したシークレット注入パス。", "サンドボックスの境界内部に適用されるネットワークポリシー。", "ホストによって強制されるリソースクォータとタイムアウト。", "境界ログ：入力、出力、およびアクセス先。" ], "benefits": [ "「エージェントが悪質なものを実行した」という事態を、インシデントから「破棄されたコンテナ」へと変換します。", "エージェントに本物の実行能力を安全に付与できるようにします。これこそが、多くの場合においてエージェントを真に有用なものにする要素です。", "攻撃だけでなく、悪意のない誤りも制限します。同一のコントロールで、無限ループとインジェクションされたペイロードの両方を捕捉できます。", "観察のための明確な場所を提供します。タスクが触れたものはすべて、単一の境界を越えるためです。" ], "risks": [ "想定よりも隔離が弱いこと：共有カーネルは、執拗なエスケープに対するセキュリティ境界にはならず、コンテナをmicroVMのように扱うのはカテゴリーエラーです。", "利便性のために資格情報が持ち込まれること：マウントされた設定ファイルが1つあるだけで、このパターン全体が台無しになります。", "再構築が遅いためにサンドボックスが密かに永続化し、安全性を担保していたエフェメラル（一時的）な性質が失われること。", "残された共有サーフェス（マウントされたボリューム、オーケストレーターAPI、またはサンドボックスが依然として到達できるネットワーク）を介したエスケープ。" ], "whenNot": [ "実行能力を持たない読み取り専用のエージェント。隔離すべき対象がなく、コストに見合うメリットが得られません。", "環境の起動時間がタスクの大部分を占める、レイテンシーが極めて重要なインラインパス。この場合は、制限されたインタプリタや純粋関数など、より限定的なコントロールの方が適しています。", "サンドボックスが、本来は与えないために存在するはずの資格情報を必要とする場合。これは、タスクを隔離するのではなく、分割すべきであるという兆候です。" ], "examples": [ "タスクごとに新しいコンテナにクローンを作成するコーディングエージェント。リポジトリはマウントされ、クラウドの資格情報は存在せず、送信（egress）はパッケージレジストリに制限されています。悪意のある依存関係がインストールされても、破棄されるのはそのコンテナだけであり、それ以外に影響はありません。", "入力データセットを読み取り専用でマウントし、ネットワーク接続を一切持たず、実行時間の上限を設定したmicroVM内で、生成されたPythonを実行するデータ分析エージェント。生成されたコードが誤っている可能性はありますが、高コストになったり、データを外部に流出させたりすることはありません。", "信頼できないPDFを使い捨て環境内で開く文書処理エージェント。アップロードされたファイル内のパーサーの脆弱性を突くエクスプロイトは、ホストへの現実的な侵入経路であり、そのファイルは外部から届いたものだからです。" ], "kpis": [ { "metric": "サンドボックス化された実行の割合", "note": "カバレッジの数値。サンドボックス化された割合がどうであれ、サンドボックスの外で実行されているものこそが、実際のセキュリティ体制を示します。" }, { "metric": "サンドボックスの生存期間", "note": "環境が存続する期間。生存期間が長くなっている場合は、エフェメラル（一時的）な性質が失われ、永続化へと侵食されていることを意味します。" }, { "metric": "リソース上限への到達回数", "note": "クォータやタイムアウトによって停止されたタスク。暴走した生成と、厳しすぎる実際の上限設定の両方が混在する、有用な指標です。" }, { "metric": "実行時に存在するシークレット数", "note": "環境内でアクセス可能な資格情報の数。目標はタスクが必要とする最小限であり、多くの場合ゼロです。" } ], "failureModes": [ "利便性のためのマウント：タスクのエラーを解消するために、ホームディレクトリ、資格情報ファイル、またはソケットをマウントしてしまうこと。", "永続的な再利用：再構築コストが高すぎるために環境がタスクごとのものではなくなり、状態と侵害の両方が存続してしまうこと。", "境界内部での送信（egress）の開放：強力に隔離されていてもネットワークが自由であれば、それはファイルシステムに対してのみ機能する封じ込めにすぎません。", "オーケストレーターへの到達可能性：サンドボックスがサンドボックスを管理するAPIを呼び出せる状態。これはエクスプロイトによるものではなく、設計上のエスケープです。" ], "lessons": [ "生成を信頼する前に、実行を隔離します。サンドボックスこそが、エージェントにコードを実行させることを妥当にする要素です。", "エフェメラル（一時的）であることがセキュリティ特性です。隔離だけでは問題を先送りするにすぎません。", "存在しない資格情報は盗まれません。そして、それこそがエスケープが発生した後に機能する唯一のコントロールです。", "サンドボックスが作動する原因のほとんどは、攻撃ではなく悪意のない誤りです。それはこのパターンが機能している証拠であり、不要であったことを示すものではありません。" ], "faqs": [ { "q": "コンテナで十分ですか、それともmicroVMが必要ですか？", "a": "内部で何を実行するかによって異なります。インジェクションのリスクがある自社コードの場合、資格情報を持たず、送信（egress）を制限した堅牢なコンテナで通常は十分です。信頼できないソースからの任意のコードを実行する場合は、共有カーネルからエスケープされる可能性があると想定し、microVMを使用してください。" }, { "q": "最小権限のツール設定とはどのように異なりますか？", "a": "最小権限はエージェントが要求できるものを制限し、サンドボックスは何かを実行したときに起こることを制限します。一方はリクエストを管理し、もう一方はそれが実行される環境を管理します。コードを実行するエージェントにはその両方が必要です。" }, { "q": "サンドボックスを導入すると動作が遅くなります。それだけの価値はありますか？", "a": "ゼロと比較するのではなく、代替コストと比較してください。レイテンシーの大部分は環境の起動によるものですが、これはプールや事前ウォームアップされたイメージによって大幅に削減できます。サンドボックスが防ぐ障害は、エージェントを実行するホストの侵害です。" } ] }, "zh": { "name": "沙箱化执行", "summary": "在一次性的隔离环境中运行智能体生成或调用的所有内容，该环境不提供环境凭据，具有受限的文件系统、受控的出站流量和严格的资源上限。引入沙箱并不是因为智能体本身具有恶意，而是因为智能体的输入可能具有恶意。", "definition": "沙箱化执行是指在隔离的临时环境中运行智能体生成的代码和智能体调用的操作。该环境的文件系统、网络、凭据和资源由宿主机而非智能体进行限制，从而确保被劫持或出错的智能体不会影响到沙箱外部的任何内容。", "problem": "在宿主机上执行代码的智能体会继承宿主机的属性：其凭据、文件系统和网络位置。此时，一次成功的注入或一个极其自信的错误命令，其后果与整台机器被攻破无异。", "context": "每当智能体运行代码、执行 Shell 命令、安装包或处理不可信文件时，都应使用此模式。门槛很低：只要智能体能够触发执行，该执行就应当在沙箱中进行。", "solution": [ "使其具备临时性。为每个任务创建独立环境，并在任务结束后将其销毁，绝不传递下一个任务未要求的状态。持久化是单次攻破演变为长期据点的原因。", "移除环境凭据。环境中的任何内容都不应仅仅因为存在即可被使用；仅在任务执行期间注入该任务所需的、范围严格受限的机密信息。", "将文件系统限制在工作集内。仅挂载代码仓库或输入，不挂载其他任何内容，并将不需要写入的所有内容挂载为只读。", "在沙箱内部限制出站流量，而不是在沙箱外围。从攻击者的角度来看，隔离和网络策略是同一种控制手段，而一个网络开放的沙箱就像是一个配有电话的监狱。", "限制资源——CPU、内存、磁盘、实际运行时间（wall-clock）和进程数。资源失控消耗是最先且最常出现的失效模式，而且通常在没有任何对手攻击的情况下就会发生。", "记录跨越边界的行为：哪些文件进入、哪些文件输出、访问了哪些目标地址。只有当您能看清什么通过了边界时，边界才是有用的。" ], "components": [ "隔离原语：容器、microVM 或同等技术，根据工作负载所需的强度进行选择。", "临时生命周期管理，将销毁作为默认操作，而非作为清理步骤。", "限定于任务及其执行期间的机密注入路径。", "在沙箱边界内部应用的网络策略。", "由宿主机强制执行的资源配额和超时限制。", "边界日志记录：输入、输出和目标地址。" ], "benefits": [ "将“智能体运行了恶意内容”这一安全事件转化为一个被废弃的容器。", "使得赋予智能体真正的执行能力变得安全，而这往往是其发挥作用的关键所在。", "既能限制无意的错误，也能防御恶意的攻击——同一种控制手段既能捕获死循环，也能拦截注入的有效载荷（payload）。", "提供了一个干净的观测场所：任务所触及的一切都跨越了同一个边界。" ], "risks": [ "隔离性弱于预期：共享内核并不是防范蓄意逃逸的安全边界，将容器等同于 microVM 是一种概念性错误。", "为了方便而暗中引入凭据——一个挂载的配置文件就会让整个模式功亏一篑。", "由于重建缓慢，沙箱悄然变得持久化，从而失去了作为安全保障的临时性。", "通过残留的共享界面逃逸：挂载的卷、编排器 API，或沙箱仍可访问的网络。" ], "whenNot": [ "无执行能力的只读智能体，此时无需隔离，且引入沙箱无法带来任何收益。", "对延迟极其敏感的内联路径，此时环境启动时间占用了任务的大部分时间，而更窄范围的控制（如受限的解释器、纯函数）会更合适。", "当沙箱需要其本应扣留的凭据时，这表明该任务应该被拆分，而不是被隔离。" ], "examples": [ "一个编码智能体，为每个任务克隆到一个全新的容器中，挂载代码仓库，不提供云凭据，且出站流量限制在包注册表。恶意依赖项的安装只会销毁该容器，而不会产生其他影响。", "一个数据分析智能体，在 microVM 中执行生成的 Python 代码，输入数据集挂载为只读，完全断网，并设有实际运行时间上限。生成的代码可能会出错，但绝不会产生高昂开销或泄露数据。", "一个文档处理智能体，在一次性环境中打开不可信的 PDF 文件，因为上传文件中的解析器漏洞是通往宿主机的真实路径，且该文件来自外部。" ], "kpis": [ { "metric": "沙箱化执行的比例", "note": "覆盖率指标。无论沙箱化部分的表现如何，在沙箱外运行的任何内容才代表了实际的安全态势。" }, { "metric": "沙箱生命周期", "note": "环境存活的时间。生命周期的延长意味着临时性正在向持久化侵蚀。" }, { "metric": "触及资源上限的次数", "note": "因配额或超时而停止的任务。这有助于识别失控的生成内容以及设置过紧的实际限制。" }, { "metric": "运行时存在的机密数量", "note": "环境中可访问的凭据数量。目标是任务所需的最小值，通常为零。" } ], "failureModes": [ "便利性挂载：为了让任务不再报错而挂载用户主目录、凭据文件或套接字（socket）。", "持久化复用：由于重建成本过高，环境不再针对每个任务独立创建，导致状态和安全漏洞得以存留。", "边界内开放出站流量：在网络自由开放的情况下，强隔离仅仅是对文件系统的限制。", "编排器可达性：沙箱可以调用管理沙箱的 API，这属于设计上的逃逸，而非通过漏洞利用实现的逃逸。" ], "lessons": [ "在信任生成内容之前，先隔离执行。沙箱是允许智能体运行代码的合理前提。", "临时性才是安全属性；单靠隔离只能延缓问题的发生。", "不存在的凭据无法被窃取——这也是发生逃逸后唯一有效的控制手段。", "大多数沙箱的触发都是无意的错误，而非恶意攻击。这恰恰证明了该模式正在发挥作用，而不是它没有必要。" ], "faqs": [ { "q": "容器足够安全吗，还是我需要使用 microVM？", "a": "这取决于内部运行的内容。对于存在注入风险的自有代码，一个无凭据且限制出站流量的加固容器通常是相称的。对于来自不可信来源的任意代码，应假定共享内核可以被逃逸，并使用 microVM。" }, { "q": "这与最小特权工具有何不同？", "a": "最小特权限制了智能体可以请求的内容；而沙箱限制了在代码实际运行后发生的事情。前者管理请求，后者管理执行环境，运行代码的智能体两者都需要。" }, { "q": "沙箱会降低运行速度。这值得吗？", "a": "请与替代方案的成本进行对比，而不是与零成本对比。大部分延迟来自于环境启动，这可以通过资源池和预热镜像在很大程度上消除；而它所防范的失效后果是运行智能体的宿主机被攻破。" } ] } } }