Sandboxes d'execució per a agents d'IA: arquitectura, riscos i patrons del món real

Inici » Pitó » Sandboxes d'execució per a agents d'IA: arquitectura, riscos i patrons del món real

Permetre que els agents d'IA executin codi, toquin fitxers, obrin navegadors i accedeixin a les API els converteix de l'autocompleció sofisticada en quelcom molt més semblant a un enginyer júnior amb root en una màquina. Aquest poder addicional és exactament el motiu pel qual semblen màgics, i exactament el motiu pel qual poden ser perillosos. Un agent desalineat o simplement amb errors pot esborrar una base de dades, filtrar una clau API a Internet o implementar una compilació defectuosa en producció sense realment "entendre" què ha anat malament.

La veritable pregunta ja no és "quina precisió té el model?", sinó "què pot arribar a aconseguir quan s'equivoca, està enganyat o té massa confiança?". Els sandboxes d'execució per a agents són la resposta d'enginyeria: entorns amb un abast estricte on els agents poden llegir i escriure codi, executar shells, iniciar servidors o iniciar navegadors, mentre tu controles estrictament els sistemes de fitxers, la xarxa, les credencials i el cicle de vida. En lloc de confiar en el model, restringeixes el radi de blast.

Per què els agents de codificació necessiten un sandbox d'execució dedicat

Els agents de codificació moderns com Claude Code, LangChain Deep Agents, els sandboxes de codificació de Docker i eines similars ja no es comporten com a simples chatbots amb accés a fitxers. Llegeixen repositoris sencers, editen fitxers, executen ordres de shell, manipulen Git, inicien compilacions de Docker, comuniquen amb API externes i fins i tot operen entorns complets semblants a un escriptori a través d'un navegador. La documentació dels proveïdors és molt explícita sobre això: Claude Code es presenta com un assistent de desenvolupament àgil que pot inspeccionar la vostra base de codi, fer edicions i executar ordres; els agents profunds de LangChain tracten un backend de sandbox com el lloc on executen ordres de shell, gestionen sistemes de fitxers i deleguen la feina a subagents per a l'aïllament.

Aquest conjunt de capacitats és exactament el que fa que aquests agents siguin útils, i operativament arriscats. Un cop un model pot executar-se pytest, instal·lar paquets npm, obrir branques o depurar errors de compilació, només calen unes quantes crides a eines per modificar scripts de desplegament, enviar imatges trencades, ajustar configuracions de CI o exfiltrar tokens mitjançant sol·licituds HTTP. La pròpia guia de seguretat dels agents d'OpenAI i el treball del NIST sobre el segrest d'agents emfatitzen la injecció ràpida: les instruccions malicioses amagades en fitxers, pàgines web o registres poden conduir silenciosament un agent a accions que mai no havíeu volgut autoritzar.

Molts equips comencen amb fluxos ingenus de "sol·licitud d'aprovació" per a cada ordre i descobreixen ràpidament que no escalen. Anthropic ha compartit públicament que els usuaris van aprovar el 93% de les sol·licituds de permís de Claude Code; el sandbox Claude de Docker fins i tot llança Claude Code amb --skip-permissions per defecte, basant-se en l'aïllament en temps d'execució en lloc d'una allau de diàlegs. La gent experimenta fatiga d'aprovació, especialment quan executen diversos agents en paral·lel i canvien de context a través de moltes indicacions. En aquest punt, els diàlegs de confirmació es converteixen en una cerimònia, no en un control fiable.

Un sandbox d'execució canvia el model de seguretat de "confiar que l'usuari llegeixi cada indicació" a "assumir que algunes ordres seran incorrectes o contradictòries i limitar els danys que poden causar". La zona de proves esdevé el límit dur al voltant dels fitxers, processos, xarxes i secrets que l'agent pot tocar, fins i tot quan es manipula mitjançant una injecció ràpida o simplement cometent errors.

També hi ha un argument bàsic sobre l'experiència del desenvolupador: els agents necessiten prou espai per treballar realment. Si s'utilitza un sandbox amb restriccions rudimentàries, ordres simples com ara compilacions o proves fallen constantment en errors de permisos obscurs. Els millors sistemes, com els que implementa Cursor a macOS/Linux/Windows o Cloudflare, Heroku i Google Cloud per a càrregues de treball allotjades, tenen com a objectiu donar als agents una sensació d'"ordinador real" dins d'un perímetre ajustat.

Què aïlla realment un sandbox d'execució per a agents

Una zona de proves d'agent adequada no és només "un altre lloc per executar codi", sinó un conjunt de límits explícits que defineixen el radi de l'explosió. Podeu pensar en cinc límits principals que apareixen una vegada i una altra en plataformes líders com Docker Sandboxes, Cloudflare Sandboxes, GKE Agent Sandbox, Freestyle VMs, E2B o Daytona.

Primer, el límit del sistema de fitxers: l'agent només hauria de veure l'espai de treball que compartiu intencionadament. La documentació de LangChain emmarca la zona de proves com la barrera que manté els agents allunyats dels fitxers amfitrions; el model de zona de proves de Docker és molt clar que la microVM només veu un directori de projecte muntat explícitament. Qualsevol cosa fora d'aquest arbre és invisible o de només lectura, de manera que l'agent no pot llegir-la casualment. ~/.ssh o reescriure les configuracions del sistema.

En segon lloc, el límit del procés i del nucli: les càrregues de treball dels agents no haurien de compartir un nucli amfitrió ni una taula de processos en brut. L'arquitectura sandbox de Docker aïlla cada entorn en el seu propi microVM i nucli de LinuxFirecracker (utilitzat en secret per diversos proveïdors) tracta aquest límit de màquina virtual com la primera capa d'aïllament, i després afegeix seccomp, espais de noms, grups de control i restriccions tipus jail a la part superior. GKE Agent Sandbox de Google aconsegueix un efecte similar dins de Kubernetes mitjançant gVisor: una capa "sentry" intercepta les crides del sistema i media l'accés al node subjacent.

En tercer lloc, el límit de la xarxa: sense una política de xarxa, un agent en zona de proves continua sent una màquina d'exfiltració de dades. La majoria de plataformes serioses ara inclouen la funció de "denejar la sortida de totes les dades" per defecte. Els Docker Sandboxes, per exemple, bloquegen HTTP/HTTPS fins que es permeti explícitament, tallen TCP/UDP/ICMP en brut i no permeten el trànsit a rangs d'IP privades i localhost, tret que configureu excepcions. Cloudflare, Google i altres dissenyen els seus sandboxes de manera que les trucades sortints passin per proxies programables on podeu injectar autenticació, filtrar destinacions i auditar l'ús.

En quart lloc, el límit de les credencials: l'exposició de secrets en brut dins de la zona de proves s'ha de tractar com a últim recurs, no per defecte. El disseny de Docker encamina les trucades HTTP a través d'un proxy del costat de l'amfitrió que pot adjuntar tokens o claus API a les sol·licituds sense col·locar mai aquests valors en brut dins de la màquina virtual. Els Sandboxes de Cloudflare injecten de manera similar les credencials a la capa de xarxa, no a través de variables d'entorn. D'aquesta manera, fins i tot si la injecció ràpida convenç l'agent d'"imprimir totes les variables d'entorn", no hi ha res interessant per robar.

Cinquè, el límit del cicle de vida: els espais de treball dels agents rarament viuen per a una sola ordre; necessiten una semàntica explícita per a l'inici, la pausa, la instantània, la bifurcació i el desmuntatge. E2B exposa sistemes de fitxers aïllats, ordres en segon pla i volums que poden sobreviure més enllà de la vida útil d'una única sandbox. Freestyle se centra en l'arrencada, la suspensió i la represa molt ràpides de les màquines virtuals amb instantànies i ramificació de l'estat en memòria. Daytona afegeix sandboxes basades en instantànies, a més de polítiques d'aturada automàtica, arxivament automàtic i supressió automàtica perquè pugueu mantenir alguns entorns de llarga durada i tractar-ne d'altres com a d'un sol ús.

Un cop veieu aquests cinc eixos (sistema de fitxers, procés, xarxa, credencials i cicle de vida), podeu llegir qualsevol pàgina de producte de sandbox com una sèrie de compromisos. Un contenidor de nucli compartit amb un muntatge d'amfitrió gran però amb regles de sortida estrictes és molt diferent d'una microVM sense muntatges d'amfitrió però amb una xarxa més permissiva. Per als agents de codificació que necessiten instal·lar dependències, executar navegadors o crear imatges de Docker, els límits més forts d'estil VM solen ser el valor per defecte més segur.

Sandboxing a macOS, Linux i Windows per a agents de codificació locals

En els ordinadors portàtils de desenvolupador, no sempre es poden generar sandboxes de microVM pesants, de manera que els equips han hagut de ser creatius amb l'aïllament natiu del sistema operatiu. El treball recent de Cursor en sandboxes locals és un bon exemple d'adaptació a les especificitats de macOS, Linux i Windows tot mantenint una API unificada per a la capa d'agent.

A macOS, es van avaluar diverses opcions: App Sandbox, contenidors genèrics, màquines virtuals completes i una tecnologia de llarga durada però "obsoleta" anomenada Seatbelt. L'App Sandbox hauria requerit signar tots els binaris que un agent pogués executar, augmentant dràsticament la complexitat i fins i tot atorgant confiança transitiva als binaris generats. Els contenidors de Linux haurien obligat els usuaris de macOS a utilitzar binaris només per a Linux, i les màquines virtuals completes haurien tingut una latència d'arrencada i una sobrecàrrega de memòria inacceptables per als fluxos de codificació interactius.

Cinturó de seguretat, accessible per sandbox-exec, va acabar sent l'elecció pragmàtica malgrat la seva antiguitat. Permet executar una ordre sota un perfil de sandbox que restringeix tot l'arbre de processos amb un llenguatge de polítiques detallat: podeu incloure a la llista blanca o bloquejar crides al sistema específiques i limitar els permisos de lectura/escriptura a fitxers o directoris específics. El cursor genera aquestes polítiques dinàmicament en temps d'execució basant-se en la configuració de l'espai de treball i de l'administrador, a més de la de l'usuari. .cursorignore, de manera que els camins ignorats queden fora de l'abast dins de la zona de proves.

A Linux, el nucli exposa les primitives correctes (seccomp per al filtratge de crides al sistema i Landlock per a les restriccions del sistema de fitxers), però deixa la composició a l'espai de l'usuari. En lloc de dependre dels embolcalls OSS existents que no admetien ignoracions específiques del repositori com ara .cursorignore, Cursor va optar per orquestrar Landlock i seccomp directament. Seccomp prohibeix les crides de sistema perilloses; Landlock aplica regles de lectura/escriptura basades en camins, fins i tot permetent-les superposar-se als espais de treball de l'usuari de manera que els fitxers ignorats siguin totalment inaccessibles o substituïts per còpies protegides que els processos en espai de proves no puguin llegir ni modificar.

Una subtilesa a Linux és el rendiment: tornar a muntar o reescriure tots els fitxers ignorats és la part més lenta de la configuració de la sandbox. Un filtratge diferit a l'estil de macOS que pot veure la ruta exacta del fitxer en el moment de la crida al sistema simplificaria això, però seccomp-bpf de Linux no facilita aquesta inspecció de rutes, de manera que hi ha un veritable compromís d'enginyeria entre un aïllament ajustat i la velocitat d'inici.

A Windows, construir un sandbox natiu realment equivalent continua sent més difícil perquè la majoria de primitives d'aïllament estan optimitzades per a navegadors i no per a eines de desenvolupament d'ús general. Actualment, Cursor executa un sandbox de Linux dins de WSL2 per a usuaris de Windows, essencialment aprofitant l'aïllament de Linux fins que estiguin disponibles primitives més riques. Estan treballant amb Microsoft per exposar les capacitats adequades perquè, amb el temps, els agents de Windows puguin gaudir d'un sandboxing natiu de primera classe sense WSL com a crossa.

El fil conductor d'aquests enfocaments específics del sistema operatiu és una API de sandbox unificada a la part superior. Des del punt de vista de l'agent, només hi ha una "eina de shell" amb capacitats i regles clares. Sota el capó, Seatbelt, Landlock/seccomp o l'aïllament basat en WSL2 apliquen aquestes regles de manera diferent segons la plataforma.

Ensenyar als agents a entendre i respectar la zona de proves

Una zona de proves només ajuda si l'agent pot anticipar què funcionarà dins i quan necessita escalar privilegis o sortir de la zona. Això sembla obvi, però a la pràctica va requerir una iteració sorprenentment profunda en el disseny d'eines i suggeriments per als proveïdors que envien agents de codificació.

El primer pas que molts equips van fer va ser millorar les descripcions de les eines, especialment per a l'execució de l'intèrpret d'ordres. En lloc d'una eina genèrica "run_shell_command", la descripció indica explícitament quins recursos són accessibles: si l'ordre té accés al sistema de fitxers, accés a Git, accés a la xarxa o un entorn completament fora de línia, depenent de la configuració de l'usuari. També documenta com l'agent pot sol·licitar drets elevats (per exemple, per accedir a Internet públic) quan cal. Aquest treball d'enginyeria ràpida tendeix a ser molt empíric: els equips executen fluxos de desplegament comuns, observen on el model prediu malament les capacitats, ajusten les descripcions de les eines i repeteixen.

Els punts de referència interns com ara "Cursor Bench" o conjunts d'avaluació similars s'utilitzen per comparar el rendiment dels agents amb i sense sandboxing. Un dels primers modes d'error era molt consistent: l'agent tornava a intentar cegament la mateixa ordre de terminal que fallava una vegada i una altra en comptes d'adonar-se que estava topant amb una restricció de sandbox. Sense un senyal clar sobre per què fallava l'ordre, el model no podia aprendre el patró.

La solució va ser mostrar explícitament els errors de la zona de proves a les sortides de l'eina, sovint amb un suggeriment sobre què fer a continuació. Quan una ordre es bloquejava a causa d'un sistema de fitxers o d'una regla de xarxa, l'eina de shell començava a incloure una breu explicació com ara "bloquejat per sandbox: accés de xarxa de sortida desactivat per a aquesta sessió" i, en alguns casos, un indici que l'agent podia sol·licitar permisos elevats. Després d'aquest canvi, els agents es van tornar molt més resistents: van deixar de repetir ordres sense èxit i van ajustar el seu pla o van sol·licitar la capacitat necessària.

Les avaluacions fora de línia són útils, però només expliquen una part de la història. Per saber realment si el sandboxing degrada l'experiència de l'usuari, els equips han implementat gradualment el suport per a sandboxes en producció i han observat les taxes d'error, els temps de finalització i els canals de retroalimentació. A la pràctica, els proveïdors informen que una fracció substancial de les consultes en plataformes compatibles ara s'executen completament dins de sandboxes (amb clients empresarials com NVIDIA entre els primers usuaris) i que els agents en sandboxes realment s'aturen per a l'aprovació al voltant d'un 40% menys sovint en fluxos de treball reals, cosa que estalvia hores de revisió manual i redueix el risc.

De cara al futur, hi ha molt interès en els "agents de sandbox natius", és a dir, models entrenats directament amb les restriccions del seu entorn. En lloc de tractar l'intèrpret d'ordres, el navegador o el sistema de fitxers com a eines abstractes, aquests agents entendrien que viuen en un temps d'execució d'abast estricte, poden escriure scripts i programes de llarga durada i han de respectar condicions límit com ara "no hi ha xarxa de sortida" o "l'espai de treball és de només lectura". Aquest entrenament podria fer-los molt millors a l'hora de planificar seqüències d'accions segures i eficients sense xocar contra parets invisibles.

Espais de proves al núvol: Cloudflare, Google Cloud, Heroku i altres

Fora de l'ordinador portàtil del desenvolupador, una gran onada de proveïdors d'infraestructures s'estan preparant per oferir sandboxes allotjades ajustades específicament per a agents d'IA. Els seus objectius són els mateixos: aïllament, control i rendiment, però els inconvenients semblen una mica diferents a escala de núvol.

Els Sandboxes de Cloudflare, creats sobre els contenidors de Cloudflare i ara disponibles de manera general, tenen com a objectiu semblar i funcionar com a entorns de desenvolupament complets per a agents. Cada sandbox és un espai de treball persistent i aïllat al qual t'adreçaràs pel seu nom. Si està inactiu, s'activa quan ho demanes; si està inactiu, se suspèn automàticament per desar el càlcul i es reprèn a la següent sol·licitud. Els desenvolupadors (o agents) poden interactuar-hi mitjançant mètodes tipats com ara exec, gitCheckout, writeFile, i més, utilitzant un SDK de JavaScript/TypeScript.

Un dels problemes més complicats del núvol és l'autenticació segura des de dins dels sandboxes d'agents. Els agents sovint necessiten accedir a serveis privats, però no voleu que les credencials en brut es trobin en variables d'entorn. Cloudflare injecta credencials a la capa de proxy de xarxa, assignant sol·licituds sortints per host a una lògica personalitzada que adjunta tokens des d'un emmagatzematge segur. El procés de sandbox mai veu els secrets reals, però la trucada encara s'autentica. Aquest disseny admet la injecció de credencials dinàmica i sensible a la identitat i funciona bé amb els enllaços de treballadors.

Per a fluxos de treball amb molts terminals, Cloudflare va afegir una experiència PTY (pseudoterminal) completa connectada a WebSockets i xterm.js. Els agents i els humans poden obrir sessions de shell en directe, interrompre processos, reconnectar-se més tard i reproduir la sortida anterior. Cada PTY té el seu propi directori de treball i entorn, i la sortida s'emmagatzema a la memòria intermèdia del servidor perquè els clients que es reconnecten puguin posar-se al dia amb els registres perduts.

A més de l'accés a shell en brut, Cloudflare també ofereix "contextos d'execució de codi" persistents per a llenguatges com Python, JavaScript i TypeScript. A diferència de molts executors de fragments que executen cada fragment de forma aïllada, aquests contextos mantenen variables, importacions i estats entre crides, de manera molt semblant a un bloc de notes de Jupyter. Els agents poden carregar dades en una crida, transformar-les en una altra i representar gràfics o taules HTML sense haver de tornar a analitzar i reimportar-ho tot constantment.

Per a tasques de desenvolupament web, els sandboxes de Cloudflare admeten processos en segon pla, comprovacions d'estat i URL de vista prèvia en directe. Un agent pot començar npm run dev com a tasca en segon pla, revisa els registres fins que el servidor estigui a punt i, a continuació, exposa el port darrere d'una URL de vista prèvia pública. Mètodes com ara waitForPort() or waitForLog() permetre que els agents seqüenciïn accions basant-se en senyals de preparació reals en lloc de ingenus sleep(2s) conjectures.

Els fluxos de treball basats en esdeveniments s'impulsen amb les primitives de vigilància de fitxers que es basen en el mecanisme inotify de Linux. Un agent pot subscriure's als canvis sota /workspace/src i tornar a executar automàticament proves o compilacions quan es modifiquen els fitxers TypeScript. Aquest és el mateix bucle de retroalimentació en què es basen els desenvolupadors humans, però fet natiu de l'agent mitjançant API com ara sandbox.watch() i fluxos d'esdeveniments enviats pel servidor.

Per tancar el cercle del cicle de vida, Cloudflare està implementant instantànies reals: captures d'estat a nivell de màquina virtual que es poden restaurar en segons des de l'emmagatzematge R2. Les instantànies conserven l'estat del sistema de fitxers, la configuració del sistema operatiu, les dependències instal·lades i els fitxers de dades; les versions futures també restauraran l'estat de la memòria en directe per a la represa instantània. Els agents (o orquestradors) poden activar instantànies mitjançant programació per a punts de control o escenaris de distribució en fan-out, i després bifurcar múltiples espais de proves a partir de la mateixa instantània per explorar hipòtesis paral·leles de forma aïllada.

Pel que fa als preus, Cloudflare ha passat a un model de "només CPU activa": es factura pels cicles de CPU realment utilitzats, no pel temps d'inactivitat mentre els agents esperen les LLM. Combinat amb enormes límits de concurrència per a instàncies "lite" i més grans, això fa possible executar una gran flota d'agents sense gastar diners en contenidors inactius.

En canvi, el GKE Agent Sandbox de Google Cloud està profundament integrat amb Kubernetes i gVisor. La idea és permetre't executar càrregues de treball d'agents en pods aïllats dins dels teus propis clústers. Crees un clúster GKE (Autopilot pot habilitar gVisor automàticament, mentre que els clústers estàndard necessiten classes d'execució explícites i grups de nodes habilitats per a gVisor) i, a continuació, implementes un controlador de sandbox d'agents mitjançant manifests versionats.

Dos recursos personalitzats principals impulsen el model: SandboxTemplate i SandboxWarmPool. SandboxTemplate actua com un pla reutilitzable que especifica una plantilla de pod (imatge, ports, recursos, runtimeClassName: gvisor, etc.) per a entorns d'execució en espai de proves, com ara un entorn Python. SandboxWarmPool manté un nombre configurat de càpsules preescalfades llestes per a una reclamació gairebé instantània, evitant els inicis en fred quan un agent necessita un entorn fresc en menys d'un segon.

A Sandbox Router El servei actua com a porta d'entrada per al trànsit entre els clients i aquests pods aïllats. En desenvolupament, podeu fer túnels de trànsit a través de kubectl port-forward sense exposar les IP públiques. En producció, normalment hauríeu de connectar l'encaminador amb l'entrada i mTLS adequats. Al costat del client, Google proporciona una biblioteca "Agentic Sandbox" de Python que engloba tot el cicle de vida: crear una reclamació de sandbox a partir d'una plantilla, esperar fins que estigui a punt, executar ordres de shell i netejar quan s'hagi acabat.

Tot això encara és "només Kubernetes" sota el capó, però empaquetat en una història coherent per als temps d'execució dels agents. gVisor proporciona aïllament de processos i de crides al sistema, SandboxTemplate estandarditza les configuracions, WarmPool resol la latència d'inici i l'encaminador més el client Python ho fan convenient per a aplicacions centrades en LLM.

Heroku, en canvi, es basa en un component bàsic molt madur: els dinamometries úniques. Durant anys, els usuaris d'Heroku han executat tasques ad hoc (migracions, scripts de manteniment, tasques administratives) en dinamòmetres efímers que s'inicien a demanda i moren quan acaben. Heroku va reutilitzar aquesta infraestructura com a sandboxes d'execució de codi, llançades juntament amb les seves ofertes d'inferència gestionada i agents. Un agent escriu fragments de Python, Ruby, Node o Go; Heroku els executa dins de dinamòmetres de curta durada i envia els resultats en flux, limitant el radi de blast al contenidor efímer.

Podeu accedir a aquests espais de prova mitjançant eines integrades a l'API d'Agents de Heroku o implementant servidors de codi obert Model Context Protocol (MCP). Els servidors MCP exposen punts finals d'eines estandarditzats, de manera que clients com Agentforce, Claude Desktop o Cursor poden tractar la zona de proves de Heroku com un backend genèric i remot d'execució de codi. Cada servidor admet límits específics del temps d'execució (com ara max_calls per bucle d'agent) per evitar que els agents girin en bucles estrets i costosos.

Els Deep Agents de LangChain afegeixen una altra dimensió integrant-se amb proveïdors de sandbox de tercers com Runloop, Daytona i Modal. El patró és senzill: el Deep Agent continua executant-se on vulgueu (localment o al núvol), però sempre que necessita executar ordres, crear fitxers o executar codi, aquestes operacions es reenvien a un sandbox remot. Els scripts de configuració poden precarregar variables d'entorn, clonar repositoris, instal·lar eines i més, de manera que cada agent obté un entorn net i controlat. Els gestors de context gestionen la creació i la neteja, tot i que la documentació recomana fermament supervisar els quadres de comandament dels proveïdors per detectar qualsevol sandbox oblidat que hagi durat molt de temps.

Rendiment, estat i ramificació: per què la velocitat és important per als agents

A la pràctica, s'evitarà un espai de proves lent però ultrasegur; les eines de desenvolupament depenen de la latència. Els agents de codificació no es comporten com a treballs per lots nocturns. Executen bucles interactius: llegeixen codi, proposen edicions, executen proves, analitzen registres, criden eines, esperen humans i després repeteixen. En sessions reals, també exploren múltiples branques d'un problema, abandonen algunes rutes i tornen a altres més tard.

És per això que plataformes com Freestyle s'obsessionen amb els temps de cicle de vida de les màquines virtuals inferiors a un segon i la semàntica d'estat ric. Les seves màquines virtuals són màquines Linux completes amb accés root, serveis systemd, compatibilitat amb la virtualització imbricada i xarxa completa. La documentació afirma que el provisionament es fa en menys de 800 ms des de la crida a l'API fins a l'execució de la màquina virtual, la suspensió/represa en menys de 100 ms i la capacitat de fer instantànies o bifurcar màquines virtuals a mitja execució amb una disminució mínima del rendiment. Criden explícitament l'estat del navegador com a beneficiari: si un agent ha portat un navegador a un estat interessant, pot bifurcar aquesta màquina virtual 20 vegades a partir de la mateixa instantània en lloc de recrear aquest estat des de zero.

El SandboxWarmPool de Google per a GKE expressa la mateixa idea en termes de Kubernetes: mantenir un conjunt de pods preescalfats perquè els agents no paguin penalitzacions completes per inici en fred per cada nova execució. Els espais de treball basats en instantànies de Daytona, a més de les polítiques d'aturada/arxivament/eliminació automàtica, ajusten el cicle de vida per a diferents tipus de sessions: entorns de desenvolupament actius, experiments efímers i línies de base de llarga durada.

L'èmfasi d'E2B en les tasques en segon pla, els directoris observables, els sistemes de fitxers aïllats i els volums reutilitzables és una altra cara de la mateixa moneda. Aquestes funcions permeten a un agent mantenir un servidor de desenvolupament o un arnès de proves en funcionament mentre explora els canvis de codi, o compartir un volum persistent a través de múltiples sandboxes efímeres al llarg del temps. Sense això, els agents acaben executant ordres puntuals i perdent context, cosa que redueix la productivitat.

Una manera útil d'avaluar qualsevol espai de proves per al treball dels agents és fer algunes preguntes directes. Puc engegar un entorn nou en menys d'un segon? Puc desar i restaurar l'estat de manera neta, incloent-hi compilacions parcials o sessions de navegador? Puc bifurcar l'estat per a l'exploració paral·lela? Puc mantenir espais de treball de llarga durada però eficients en l'ús de recursos per a fluxos de "torna més tard"? Com ​​més respostes "sí" rebis, més es podran comportar els teus agents com a enginyers reals en lloc d'executors de scripts sense estat.

Secrets, política de xarxa i confiança en l'espai de treball com a pla de control real

Fins i tot amb un aïllament perfecte de l'amfitrió, és fàcil construir un sistema insegur si ignoreu els secrets, la política de xarxa i la confiança de l'espai de treball. La documentació de la sandbox de Docker és refrescantment sincera en aquest sentit. La microVM i el seu daemon privat de Docker formen el límit de confiança principal amb l'amfitrió. Dins d'aquesta màquina virtual, però, l'agent té control total a nivell d'arrel i l'espai de treball compartit està muntat en lectura-escriptura. Per defecte, qualsevol edició de fitxers es reflecteix immediatament a l'amfitrió. La sortida de xarxa es denega per defecte i només es permet mitjançant regles explícites, i les sol·licituds HTTP utilitzen un proxy del costat de l'amfitrió que pot injectar credencials sense exposar secrets en brut a la màquina virtual.

Això significa que aïllar l'amfitrió és només el primer pas; encara cal pensar què pot fer l'agent a l'espai de treball i al món exterior. La documentació de Docker adverteix explícitament que si un agent edita scripts, els humans els executaran posteriorment: hooks de Git, configuracions de CI, definicions de tasques de l'IDE, Makefile objectius, package.json scripts: el dany pot "saltar" de nou a l'amfitrió o als sistemes de CI quan s'executen aquests scripts. Fins i tot destaquen que Git s'hi connecta .git/ no apareixes a git diff, facilitant la persistència silenciosa de la lògica maliciosa.

El proxy de credencials és potent però subtil. El proxy de sortida de Docker garanteix que els secrets romanguin fora de la màquina virtual, però encara permet que l'agent actuï utilitzant aquestes identitats contra els hosts permesos. Alguns fluxos, com ara escriure variables d'entorn personalitzades en fitxers com ara /etc/sandbox-persistent.sh – trencar aquest límit emmagatzemant intencionadament secrets dins de la màquina virtual, cosa que només és segura si realment confieu en l'agent i en la zona de proves.

L'abast de la configuració importa tant com els secrets. Les preguntes freqüents de Docker indiquen que les configuracions a nivell d'usuari com ara ~/.claude or ~/.codex a l'amfitrió no es copien a la zona de proves; només és visible la configuració de l'àmbit del projecte a l'espai de treball compartit. La documentació de configuració d'Anthropic reforça que la configuració a nivell de projecte (eines, permisos, servidors MCP, hooks) anul·la la de nivell d'usuari i es comparteix entre els equips. En altres paraules, qualsevol política, instrucció i complement que adjunteu al repositori es converteix en la superfície principal que veu l'agent.

L'orientació sobre habilitats d'OpenAI posa de manifest punts similars amb un vocabulari lleugerament diferent. Les habilitats (paquets d'eines) poden introduir riscos d'exfiltració de dades impulsades per la injecció ràpida. La documentació adverteix contra l'exposició directa d'un mercat d'habilitats públic i sense seleccionar als usuaris finals, ja que els fitxers SKILL.md maliciosos poden anul·lar polítiques, desencadenar accions destructives o filtrar dades privades. Recomanen verificar les habilitats dels desenvolupadors, limitar-les a fluxos de treball específics, ocultar accions d'alt impacte darrere d'aprovacions addicionals i comprovacions de polítiques, i tractar les habilitats com a part del vostre model d'amenaces.

Quan ajuntes les peces, el pla de control "real" per a les zones de proves d'agents abasta quatre capes. L'aïllament de l'amfitrió protegeix les màquines i els nodes del clúster. La confiança de l'espai de treball protegeix el futur humà o CI que executarà els fitxers produïts dins de la zona de proves. La política de xarxa protegeix els sistemes externs i les fonts de dades privades. La gestió de credencials protegeix les identitats a través de les quals l'agent pot actuar. Un disseny robust té respostes per a tots quatre, no només per a la primera.

A més a més, encara cal tenir un saludable escepticisme sobre la injecció ràpida i el segrest d'agents. NIST, OWASP i OpenAI descriuen variants del mateix patró: una entrada no fiable (un README, una pàgina web, un fitxer de registre) conté instruccions malicioses que redirigeixen el comportament de l'agent. La generació augmentada amb recuperació i l'afinament no solucionen això màgicament. Un sandbox ben instrumentat i una bona política no poden evitar que el model sigui enganyat, però poden reduir dràsticament els inconvenients quan ho és.

Les plataformes al núvol i els motors d'execució d'agents comencen a codificar aquestes lliçons. Els proxies secrets, els dominis sortints a la llista permesa, les configuracions amb àmbit de repositori, els subagents amb capacitats més reduïdes, els fluxos d'aprovació basats en hooks i els sandboxes reproduïbles són peces del mateix trencaclosques: acceptar que els models són fal·libles i dissenyar l'entorn de manera que el cost d'aquesta fal·libilitat es mantingui limitat.

En configuracions locals i al núvol, és millor pensar en un sandbox d'execució per a agents com una línia acuradament dibuixada: no fa que el model sigui més intel·ligent, sinó que fa que els seus errors siguin menys catastròfics i més observables. Amb la combinació adequada de controls de sistema de fitxers, processos, xarxa, secrets i cicle de vida, a més de l'ensenyament intel·ligent de l'agent sobre el seu entorn, podeu permetre que els sistemes d'IA clonin repositoris, executin proves, iniciïn navegadors i fins i tot toquin sistemes de producció, sense donar-los les claus de tot el que us importa.

Això significa que aïllar l'amfitrió és només el primer pas; encara cal pensar en què pot fer l'agent a l'espai de treball i al món exterior, inclosos els riscos com. execució remota de codi. La documentació de Docker adverteix explícitament que si un agent edita scripts, els humans els executaran posteriorment: hooks de Git, configuracions de CI, definicions de tasques de l'IDE, Makefile objectius, package.json scripts: el dany pot "saltar" de nou a l'amfitrió o als sistemes de CI quan s'executen aquests scripts.