{"schema_version":"1.0","service":"Publicasta","type":"article","id":648,"slug":"aws_lambda_microvms_make_agent_sandboxes_an_operations_problem","title":"Los MicroVM de AWS Lambda facilitan el despliegue de sandboxes para agentes de IA, pero vuelven más difícil su gobierno accidental","excerpt":"La arquitectura de referencia de AWS para MicroVM de Lambda ofrece entornos aislados y rápidos para tareas de agentes de IA. El cambio decisivo es operativo: identidad, salida de red, persistencia, observabilidad y limpieza deben diseñarse como un solo sistema.","language":"es","default_language":"en","canonical_url":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem?lang=es","image":{"url":"https://publicasta.com/storage/projects/17/pages/648/2026/09/9ce2aef8-5d39-4769-8619-63fe72237dd9.webp","alt":"Ilustración editorial de una tarea de un agente de IA ejecutándose dentro de una MicroVM aislada en la nube, rodeada de controles de identidad, red, observabilidad, persistencia y limpieza."},"publisher":{"id":17,"slug":"it_today_news","name":"IT Today","url":"https://publicasta.com/it_today_news"},"author":{"name":"Anton R"},"published_at":"2026-09-19T13:57:36+00:00","updated_at":"2026-09-19T13:57:36+00:00","content_markdown":"AWS ha publicado una arquitectura de referencia para ejecutar sandboxes de agentes de IA autogestionados sobre MicroVM de Lambda. La propuesta es práctica: una API recibe una tarea, inicia un entorno aislado, permite que un agente trabaje, transmite o almacena el resultado y destruye o suspende el entorno cuando el trabajo termina. Está dirigida a equipos que quieren ejecutar agentes dentro de su propia cuenta de AWS, en lugar de hacerlo en un espacio de desarrollo administrado por un proveedor.\n\n ![Ilustración editorial de una tarea de un agente de IA ejecutándose dentro de una MicroVM aislada en la nube, rodeada de controles de identidad, red, observabilidad, persistencia y limpieza.](https://publicasta.com/storage/projects/17/pages/648/2026/09/9ce2aef8-5d39-4769-8619-63fe72237dd9.webp)\n\n La noticia se puede reducir fácilmente a una historia de rendimiento. Los MicroVM de Lambda ofrecen un arranque rápido, aislamiento a nivel de máquina virtual, estado basado en instantáneas y redes administradas. Todo eso resulta útil. El cambio más importante está en otra parte: un sandbox que puede crearse bajo demanda, conectarse a una VPC real y recibir acceso a servicios internos deja de ser solo una función de seguridad. Se convierte en una carga de trabajo de producción de vida breve, con un modelo tomando decisiones en su interior.\n\n Por eso, para los equipos de plataforma, la primera pregunta no debería ser si un microVM es más seguro que un contenedor. Debería ser si la organización puede hacer que toda la ruta de ejecución sea observable, acotada y desechable. Un buen mecanismo de aislamiento ayuda, pero no decide qué credenciales recibe el agente, a qué dominios puede llegar, qué datos puede copiar a un espacio de trabajo ni si un entorno suspendido podrá reanudarse después de que cambie la política que lo regía.\n\n ## Qué anunció AWS\n\n La publicación del AWS Compute Blog, fechada el 18 de septiembre, describe una arquitectura autogestionada construida con AWS Serverless Application Model y varios servicios administrados. Entre sus componentes declarados están Amazon S3, IAM, Systems Manager Parameter Store, API Gateway, Lambda, AWS WAF, CloudWatch Logs y los MicroVM de Lambda. El diseño está pensado para llamadas a herramientas de agentes de IA que necesitan algo más que una invocación breve de una función: instalar paquetes, ejecutar comandos, trabajar con un sistema de archivos, iniciar procesos y conservar el estado durante una sesión interactiva.\n\n El servicio subyacente de Lambda MicroVM es una primitiva de cómputo más reciente basada en la virtualización de Firecracker. AWS lo describe como un entorno serverless con capacidades completas de sistema operativo, arranque basado en instantáneas y controles para el tráfico entrante y saliente. Un MicroVM puede asociarse con un conector de red durante la ejecución. Según la configuración, puede acceder a internet público, a una VPC o a servicios privados de AWS mediante endpoints de VPC.\n\n Esa combinación resuelve una incompatibilidad real de los sistemas actuales de agentes. Una función normal es cómoda, pero estrecha: tiene un modelo de ejecución limitado, un sistema de archivos local efímero y un tiempo de ejecución acotado. Una máquina virtual tradicional o un pod de Kubernetes ofrece más libertad, pero el equipo de plataforma debe gestionar capacidad, despliegue de imágenes, aislamiento, planificación y limpieza. Un contenedor puede arrancar rápido, aunque comparte el kernel del host con otras cargas de trabajo. Los MicroVM colocan un sistema operativo invitado entre la tarea y el host subyacente, al tiempo que conservan un ciclo de vida administrado y bajo demanda.\n\n La arquitectura de referencia de AWS no es un límite de seguridad listo para usar en cualquier agente. Es un conjunto de piezas y un patrón de despliegue. La diferencia importa porque los controles más relevantes están por encima de la capa de virtualización. La plataforma todavía debe decidir cómo se autentican las solicitudes, cómo se separan los usuarios, cómo se autorizan las tareas, cómo se inspeccionan los artefactos, cuánto puede durar una sesión y qué sucede cuando un agente pide repetidamente un permiso que no debería tener.\n\n ## Por qué este problema no es igual al del código serverless convencional\n\n Una función serverless convencional suele tener un propósito bastante acotado. Un evento invoca un manejador conocido, el manejador llama a un conjunto conocido de servicios y el flujo de despliegue define por adelantado buena parte del comportamiento. Siguen existiendo problemas de seguridad importantes, pero el operador normalmente puede razonar sobre la función a partir de su código, su política de IAM y su contrato de entrada.\n\n Un agente de IA cambia la forma de la ruta de ejecución. Puede seleccionar herramientas de manera dinámica, interpretar texto no confiable, instalar una dependencia, inspeccionar un repositorio, llamar a un cliente de línea de comandos, reintentar después de un error o decidir que una tarea necesita una nueva solicitud de red. La secuencia final de acciones no está especificada por completo en el manifiesto de despliegue. Se genera parcialmente durante la ejecución a partir del prompt, las descripciones de las herramientas, los documentos recuperados, el contenido de los archivos y el resultado de los comandos anteriores.\n\n Hay que tratar por separado varios límites. El límite del modelo se refiere a las instrucciones que el agente puede interpretar y a la forma en que maneja contenido hostil. El límite de herramientas se refiere a las API y los comandos que puede invocar. El límite de cómputo se refiere a lo que puede afectar el código que se ejecuta en el entorno. El límite de datos se refiere a aquello que puede leer, copiar o conservar. El límite organizativo se refiere a si un cliente, proyecto o equipo puede observar o influir en otro. Un microVM refuerza principalmente el límite de cómputo. No resuelve automáticamente los otros cuatro.\n\n Por eso la palabra sandbox puede resultar engañosa. Puede significar un entorno de sistema operativo recién creado, un contenedor con un sistema de archivos restringido, un proceso con un perfil de seccomp, una capa de aislamiento del navegador o simplemente un espacio de trabajo marcado como temporal. Esos mecanismos tienen fallos distintos. Un kernel invitado y un monitor de máquina virtual pueden reducir las consecuencias de que un proceso hostil escape de un contenedor, pero un agente que dispone de credenciales válidas todavía puede ejecutar una llamada autorizada y dañina a una API sin escapar de nada.\n\n El objetivo práctico no es que nunca pueda ocurrir nada malo. Es controlar el radio de impacto: cada tarea debería tener la identidad, el conjunto de datos, la ruta de red, el tiempo de ejecución, la vida útil del almacenamiento y el presupuesto de acciones mínimos para terminar su trabajo. El sistema debe conservar pruebas suficientes para explicar lo ocurrido y, después, hacer barato destruir el entorno.\n\n ## Piezas de la arquitectura que merecen una revisión detallada\n\n ### 1. La puerta de entrada de solicitudes\n\n La capa de API es la primera decisión de política, no solo una puerta de acceso. API Gateway y WAF pueden ayudar a autenticar solicitudes, rechazar tráfico evidentemente abusivo y aplicar límites de frecuencia, pero una solicitud válida aún necesita una decisión de autorización específica para la tarea. Un usuario que puede crear un sandbox para una tarea de documentación no debería poder solicitar automáticamente otro con acceso a una base de datos de producción.\n\n La solicitud debería incluir una clase de carga de trabajo explícita. Entre los campos útiles están el identificador del proyecto o tenant, las fuentes de datos permitidas, el perfil de red autorizado, el tiempo de ejecución máximo, el tipo de salida requerido y la indicación de si la tarea puede producir cambios externos. El lanzador debería derivar el entorno de esa política, en lugar de aceptar del solicitante nombres arbitrarios de roles de IAM, identificadores de VPC o parámetros de grupos de seguridad.\n\n Aquí también deben vivir las cuotas. Sin límites por usuario y por proyecto, un bucle del agente puede crear muchos entornos, asociar almacenamiento costoso o mantener sesiones activas mediante actividad repetida. El presupuesto de una solicitud debería cubrir más que el número de llamadas a API. Debe incluir MicroVM simultáneos, CPU y memoria acumuladas, bytes salientes, tamaño de los artefactos y cantidad de llamadas a herramientas privilegiadas.\n\n ### 2. La imagen y el sistema de archivos\n\n Un entorno desechable solo es tan confiable como la imagen desde la que arranca. La imagen debe tener una versión, estar firmada o vinculada de alguna otra forma a un registro de lanzamiento, reconstruirse con regularidad y analizarse en busca de paquetes vulnerables del sistema operativo y de las herramientas del agente. Los equipos deben saber si una tarea recibe una imagen base estable, una imagen específica del proyecto o un espacio de trabajo mutable superpuesto. Cada opción modifica la reproducibilidad y la aplicación de parches.\n\n Un agente suele necesitar instalar paquetes o compilar código nativo. Es un caso de uso legítimo para un sistema operativo completo, pero amplía la superficie de ataque y hace difícil razonar sobre el estado final. Un patrón más seguro consiste en separar el sistema de archivos escribible de la imagen base confiable, conservarlo poco tiempo y tratar todos los binarios producidos, cachés y scripts generados como artefactos no confiables.\n\n Las instantáneas introducen una cuestión de ciclo de vida menos evidente. Mejoran el arranque y pueden conservar una sesión interactiva, pero también preservan el estado de memoria y disco. Si hay un token, una cookie de sesión, un archivo de código privado o la salida de un comando cuando se suspende el entorno, ese material puede permanecer en el estado reanudado. Los operadores necesitan una regla documentada sobre qué se permite almacenar durante una suspensión y un mecanismo para invalidar o rotar material sensible antes de reanudar.\n\n Una instantánea también refleja la política vigente cuando se creó. Si la organización cambia después los destinos de red permitidos o revoca una dependencia, reanudar un estado antiguo no debe restaurar silenciosamente los privilegios anteriores. La política de red y de identidad debe evaluarse al iniciar y al reanudar, no solo cuando se construye la imagen.\n\n ### 3. IAM y entrega de secretos\n\n Asignar un rol de IAM a un MicroVM es cómodo, pero el rol no constituye una política para el agente. Es un mecanismo de autorización en la nube. El rol debe diseñarse para la clase de tarea y limitarse con permisos a nivel de recurso, condiciones, etiquetas de sesión y credenciales de corta duración siempre que sea posible. Un rol genérico que pueda leer todos los buckets de proyectos o invocar cada servicio interno convierte el sandbox en un custodio de credenciales de gran valor.\n\n Parameter Store puede mantener los secretos fuera de las imágenes, pero recuperar un secreto sigue siendo una acción que debe estar justificada. El lanzador no debería exponer un espacio de nombres amplio de parámetros y esperar que el modelo elija el valor correcto. En su lugar, un intermediario situado fuera del proceso del agente puede emitir una credencial limitada y temporal después de comprobar la política de la tarea. También puede impedir que los secretos en bruto aparezcan en prompts, logs y salidas de comandos visibles para el modelo.\n\n El mismo principio se aplica a los repositorios de código. Un token que permite clonar un repositorio quizá también permita hacer push, abrir una solicitud de cambios o leer proyectos no relacionados. Las rutas de lectura y escritura deben estar separadas. Si un agente necesita proponer un cambio, el resultado predeterminado debería ser un parche o un artefacto almacenado para revisión, no una credencial capaz de modificar la rama canónica.\n\n Las credenciales de corta duración reducen la exposición, pero no eliminan la necesidad de auditoría. Un agente comprometido puede usar un token válido durante su vida útil. Por eso cada operación sensible debe registrarse con el identificador de la tarea, el principal, el identificador del entorno y la decisión de política que la permitió. CloudTrail y los logs específicos de los servicios deben correlacionarse con los comandos y trazas de herramientas producidos dentro del entorno.\n\n ### 4. La salida de red forma parte del conjunto de capacidades del agente\n\n La documentación de AWS expone controles tanto para el tráfico entrante como para el saliente. Es importante porque muchas tareas de agentes necesitan descargar paquetes, recuperar código fuente o llamar a API externas. También es el punto en que un sandbox puede convertirse en un relay sin control. Si el entorno tiene acceso irrestricto a internet, el modelo puede subir archivos de código, contactar un endpoint controlado por un atacante, descargar una herramienta no revisada o participar en un canal de mando y control.\n\n El valor predeterminado seguro es una lista pequeña de destinos permitidos y vinculados a la tarea. Cuando sea viable, la instalación de paquetes debe usar mirrors o repositorios aprobados. El acceso a Git debe restringirse a las organizaciones o hosts necesarios para el trabajo. Los servicios internos deben alcanzarse mediante endpoints de VPC y grupos de seguridad explícitos, en lugar de depender de un enrutamiento amplio. Las solicitudes DNS también requieren atención: una lista de dominios que ignore el rebinding de DNS, las redirecciones o las direcciones resueltas recientemente es menos sólida de lo que parece.\n\n La política de red debería estar ligada a la identidad y a la clase de carga de trabajo, no solo a una subred compartida. Un agente de desarrollo, uno de revisión de código y otro de migración pueden usar la misma imagen base y, sin embargo, necesitar rutas de red completamente distintas. La arquitectura debe hacer visible esa diferencia en los objetos de despliegue y en los logs.\n\n Los controles sobre el contenido saliente son útiles cuando los datos son sensibles. Un proxy puede registrar el destino, el método, el tamaño de la respuesta y el resultado de la política. Para cargas de alto riesgo, puede bloquear subidas, descargas ejecutables o solicitudes que contengan patrones conocidos de secretos. Estos controles son imperfectos y no deben presentarse como una garantía de prevención de pérdida de datos, pero aportan evidencia y reducen las filtraciones accidentales.\n\n ### 5. Las llamadas a herramientas necesitan una capa de política\n\n El agente no debería recibir un shell sin restricciones solo porque el sandbox está aislado. Un shell suele ser la herramienta más útil para trabajar con software, pero combina acceso a archivos, creación de procesos, uso de red y descubrimiento de credenciales. El intermediario de herramientas debería clasificar los comandos por efecto y exigir aprobación adicional para acciones como publicar paquetes, cambiar infraestructura, borrar datos, modificar controles de acceso o enviar mensajes externos.\n\n Un diseño útil separa la observación de la mutación. Leer un log de compilación, ejecutar una prueba o inspeccionar un árbol de dependencias puede permitirse automáticamente. Escribir en una rama, abrir un ticket, cambiar un manifiesto de despliegue o invocar una API de producción puede generar una propuesta que otro servicio o una persona deba aprobar. El MicroVM contiene el trabajo; no decide si ese trabajo debe llegar a producción.\n\n Las descripciones de las herramientas son otra entrada de la política. Si una herramienta afirma que una operación es de solo lectura, pero llama a un endpoint con efectos secundarios, el agente puede tomar una decisión peligrosa mientras el sistema que lo rodea cree que todo es seguro. Los esquemas de herramientas, su implementación y los registros de auditoría deben probarse conjuntamente. El permiso debe basarse en el efecto real de la llamada, no en su nombre amigable.\n\n ## Qué cambia la arquitectura para los equipos de plataforma\n\n El mayor beneficio operativo es que el cómputo para agentes puede convertirse en una primitiva de plataforma. Los equipos pueden ofrecer un servicio interno de ejecutar tareas con una API consistente, logging común, gestión de imágenes, cuotas y reglas de ciclo de vida. Los desarrolladores no necesitan desplegar un grupo de workers dedicado para cada nuevo flujo de agentes. Los equipos de seguridad pueden revisar un número pequeño de perfiles de carga de trabajo, en lugar de una larga lista de hosts particulares.\n\n Ese beneficio solo aparece si la plataforma es propietaria del plano de control. Si cada equipo de producto crea su propio lanzador, rol de IAM, conector de red y bucket de logs, los MicroVM pueden multiplicar los mismos problemas de gobierno que pretendían simplificar. Una plataforma interna debería ofrecer capacidades seguras como productos: una tarea de repositorio de solo lectura, un ejecutor de pruebas aislado, un trabajo de análisis de dependencias o un worker que prepare propuestas de cambio. Cada perfil debería tener una imagen conocida, una política de red, un contrato de credenciales y una regla de retención definidos.\n\n La contabilidad de costes también se vuelve más precisa y más necesaria. La facturación serverless puede hacer atractivas las tareas breves, pero los agentes interactivos pueden pasar bastante tiempo esperando, reintentando o conservando estado. La suspensión puede reducir el consumo inactivo, pero no vuelve gratuita la carga de trabajo. Al total contribuyen el almacenamiento, las solicitudes a API Gateway, el logging, la transferencia de red, el procesamiento de WAF, las llamadas al modelo y la retención de artefactos. Una tarea que parece barata en la capa de cómputo puede resultar cara si el agente hace polling repetidamente o descarga espacios de trabajo grandes.\n\n Las etiquetas deberían ser obligatorias al crear el entorno. Como mínimo, hay que registrar el propietario, el proyecto, el tipo de tarea, la expiración del entorno, la clasificación de los datos y el centro de costes. Las etiquetas deben llegar a los logs y a los informes de facturación. Una plataforma que no puede responder qué equipo creó un entorno, qué política usó y por qué siguió activo todavía no está preparada para ofrecer ejecución autónoma a gran escala.\n\n ## La cuestión del aislamiento: mejor que los contenedores, pero no una respuesta completa\n\n AWS presenta los MicroVM de Lambda alrededor del aislamiento a nivel de máquina virtual, mediante tecnología Firecracker asociada con Lambda. Es una diferencia significativa frente a los contenedores ordinarios, cuyos procesos comparten el kernel del host. Puede ser una base adecuada para ejecutar código no confiable o parcialmente confiable, especialmente cuando la carga necesita funciones del sistema operativo difíciles de proporcionar mediante un sandbox a nivel de lenguaje.\n\n Sin embargo, los mecanismos de aislamiento deben compararse por el sistema completo, no por una sola etiqueta. Un microVM puede tener un sistema operativo invitado vulnerable, un rol con privilegios excesivos, una ruta de red abierta, una caché de paquetes envenenada, una integración peligrosa en el lado del host o un pipeline de logs que exponga secretos. Un contenedor con una política cuidadosamente diseñada puede ser suficiente para una tarea de bajo riesgo, mientras que un microVM con credenciales irrestrictas todavía puede provocar un incidente grave.\n\n La investigación reciente sobre sandboxes de código para IA plantea un punto parecido desde la perspectiva de la medición. Las variables relevantes incluyen la superficie de ataque del host, la fuga de información, la defensa en profundidad, el historial de vulnerabilidades, el ritmo de aplicación de parches y la calidad del fuzzing upstream. La clase de aislamiento importa, pero también importan las prácticas de actualización y operación del producto. Los MicroVM deben tratarse como una capa de un diseño de defensa en profundidad, no como una certificación de que la tarea es segura.\n\n La diferencia es especialmente importante frente a la inyección de prompts. Un README, un issue, una página web o una dependencia maliciosa puede persuadir a un agente para ejecutar una acción dentro del entorno. Si la acción solo cambia archivos desechables, el daño puede quedar contenido. Si el agente puede leer un token de código, enviarlo a un host externo, llamar a una API interna o modificar un bucket compartido de artefactos, el hecho de que haya permanecido dentro del MicroVM no vuelve aceptable el resultado.\n\n ## Una secuencia práctica para el despliegue\n\n Los equipos que evalúen el servicio deberían empezar con una tarea cuyo resultado sea útil, pero cuyo fallo pueda recuperarse. El análisis de dependencias, la ejecución de pruebas contra un repositorio sintético, la generación de documentación a partir de material público y la verificación de compilaciones son mejores primeras cargas que la mutación de infraestructura o el soporte de producción. El objetivo del primer despliegue es observar el plano de control tanto como medir el éxito de la tarea.\n\n Defina el contrato antes de activar el modelo. Especifique los datos de entrada, las herramientas permitidas, los artefactos esperados, el tiempo máximo, los destinos de red, la identidad, los campos de logging y el comportamiento al expirar. Escriba qué cosas no puede hacer nunca el agente. Una política breve que pueda aplicarse vale más que una declaración amplia que solo aparezca en un documento de revisión.\n\n Después, pruebe las rutas no deseadas. Coloque instrucciones maliciosas en un archivo del repositorio. Añada una dependencia con un script de instalación. Devuelva un error de herramienta que anime al agente a reintentar con privilegios más amplios. Incluya una cadena con apariencia de secreto en un fixture. Intente que el agente acceda a un hostname interno, cree un segundo entorno, escriba fuera del directorio de la tarea, conserve un token en una instantánea y mantenga la sesión activa después de su plazo. El objetivo es probar el comportamiento de la política, no enseñar a un agente a eludir las salvaguardas en producción.\n\n Instrumente toda la cadena. Un registro útil incluye la solicitud, el principal, el perfil de política, el digest de la imagen, el identificador del MicroVM, el inicio y el final de la tarea, las llamadas a herramientas, los comandos, los destinos de red, la emisión de credenciales, los archivos exportados, los eventos de suspensión y reanudación y el resultado de la limpieza. Los logs deben resistir manipulaciones y estar separados del sistema de archivos escribible de la tarea. Si un fallo no puede reconstruirse a partir de las pruebas, a la plataforma le costará distinguir entre error del modelo, error del usuario, error del servicio y ataque.\n\n Haga de la limpieza un flujo de trabajo de primera clase. Cada entorno necesita un plazo impuesto desde fuera del agente. La limpieza debe revocar las credenciales temporales, borrar o poner en cuarentena los artefactos según la política de datos, eliminar las asociaciones de red, terminar la sesión y registrar el estado final. Un worker que se cae mientras el agente sigue funcionando no debe dejar detrás un entorno válido indefinidamente. La reconciliación periódica debe encontrar recursos que perdieron su registro en el plano de control y aplicarles las mismas reglas de expiración.\n\n Solo después de que estos controles funcionen debería la plataforma añadir datos privados o derechos de mutación. Incluso entonces, mantenga estrecho el límite de permisos. Un agente que corrige código puede crear un parche sin poder fusionarlo. Un agente que planifica una migración puede producir SQL sin ejecutarlo. Un agente de soporte puede redactar una respuesta sin enviarla. La plataforma debe conservar un punto de revisión humano o determinista en la transición entre el análisis y el efecto externo.\n\n ## Preguntas que los operadores deben hacer a AWS y a sus propios equipos\n\n La documentación pública explica el modelo central del servicio, pero la adopción en producción todavía requiere respuestas específicas para la cuenta y la carga de trabajo. Los operadores deben verificar cómo se actualizan las imágenes, cómo se cifra y expira el estado de las instantáneas, cómo se comportan los conectores de red al reanudar, qué límites se aplican a la concurrencia y al almacenamiento y qué eventos están disponibles para auditoría. También deben confirmar la disponibilidad regional, las dimensiones de precio y el modelo de soporte para las capacidades concretas de MicroVM que planean utilizar.\n\n Internamente, los equipos deben preguntar quién es responsable de la imagen base, quién aprueba los perfiles de red, quién puede añadir un secreto, cómo se detiene una tarea, cómo recupera las pruebas un investigador de incidentes y qué ocurre cuando un empleado o cliente revoca el acceso mientras una tarea sigue activa. No son preguntas para una fase posterior de operaciones. Definen si la arquitectura es una plataforma controlada o simplemente un lanzador cómodo.\n\n También hay una pregunta de diseño de producto: ¿qué ve el usuario cuando el agente quiere cruzar un límite? Un sistema útil hace legible la acción propuesta. Debe mostrar el repositorio, el destino, la categoría de datos, el efecto secundario esperado y el motivo de la solicitud. Permitir no debería ser la única interacción. La plataforma necesita alternativas seguras, como producir un parche, guardar un informe, solicitar un token más estrecho o detener la tarea.\n\n ## El significado más amplio\n\n AWS está respondiendo a un patrón que se extiende por las plataformas cloud: los agentes necesitan entornos de ejecución reales, pero las organizaciones no quieren que cada equipo construya un shell remoto improvisado. Un MicroVM administrado puede reducir el trabajo de infraestructura necesario para ofrecer esa capacidad. También puede desplazar el centro de gravedad de la seguridad de agentes, desde el filtrado de prompts hacia la ingeniería de cargas de trabajo.\n\n Es un desplazamiento saludable. El filtrado de prompts puede reducir ataques de instrucciones evidentes, pero no puede expresar todas las reglas de autorización y flujo de datos. Un perfil de carga de trabajo puede decir que una tarea puede leer este repositorio, alcanzar estos mirrors de paquetes, escribir solo en este bucket de artefactos y ejecutarse durante diez minutos. IAM, la política de red, un intermediario de herramientas y un controlador externo de limpieza pueden hacer cumplir partes de ese contrato incluso cuando el modelo se comporta de forma impredecible.\n\n El riesgo es que la comodidad del aprovisionamiento serverless oculte el coste del gobierno. Un desarrollador puede lanzar un entorno de ejecución capaz con unas pocas llamadas a API, asociarle un rol, darle acceso a internet y llamar al resultado un sandbox. Eso basta para demostrar una función. No basta para operar un sistema autónomo alrededor de datos privados o controles de producción.\n\n El consejo adecuado para la próxima evaluación es concreto: construya un único perfil de tarea estrecho, mantenga sus datos sintéticos o públicos, niegue la salida de red amplia, no emita secretos de larga duración, registre cada acción de herramienta y red, imponga un plazo externo y verifique la limpieza. Mida no solo la latencia de arranque y la finalización de la tarea, sino también las infracciones de política, las solicitudes de red inexplicadas, la higiene de las instantáneas, la retención de artefactos y el esfuerzo necesario para investigar una ejecución fallida.\n\n Los MicroVM de Lambda pueden facilitar el despliegue de ejecuciones aisladas para agentes. No convierten la confianza en algo automático. Los equipos que obtengan beneficios serán los que traten el MicroVM como la capa de cómputo de un servicio de ejecución controlado, con identidad, red, datos, observabilidad y ciclo de vida diseñados alrededor desde el principio.\n\n ## Fuentes\n\n La atribución factual principal corresponde al artículo del AWS Compute Blog titulado «Running self-hosted AI agent sandboxes with AWS Lambda MicroVMs». La descripción del servicio y de sus capacidades procede de la documentación de AWS sobre Lambda MicroVMs y sobre sus redes. El contexto adicional incluye el anuncio de AWS sobre la compatibilidad con AWS PrivateLink, la presentación de los entornos serverless con aislamiento a nivel de máquina virtual y el estudio comparativo sobre la seguridad de sandboxes de código para IA publicado en arXiv. Las referencias de discusión comunitaria se consideran contexto y no sustituyen la documentación técnica de AWS.","available_translations":[{"language":"ar","title":"تجعل MicroVMs في AWS Lambda نشر بيئات عزل وكلاء الذكاء الاصطناعي أسهل، لكنها تجعل حوكمتها عرضة للتعقيد غير المقصود","html_url":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem?lang=ar","markdown_url":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem.md?lang=ar","json_url":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem.json?lang=ar","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem?lang=ar"},{"language":"de","title":"AWS-Lambda-MicroVMs machen Agenten-Sandboxen leichter bereitstellbar – und versehentlich schwerer steuerbar","html_url":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem?lang=de","markdown_url":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem.md?lang=de","json_url":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem.json?lang=de","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem?lang=de"},{"language":"en","title":"AWS Lambda MicroVMs make AI-agent sandboxes easier to deploy—and harder to govern by accident","html_url":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem?lang=en","markdown_url":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem.md?lang=en","json_url":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem.json?lang=en","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem?lang=en"},{"language":"es","title":"Los MicroVM de AWS Lambda facilitan el despliegue de sandboxes para agentes de IA, pero vuelven más difícil su gobierno accidental","html_url":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem?lang=es","markdown_url":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem.md?lang=es","json_url":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem.json?lang=es","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem?lang=es"},{"language":"fr","title":"Les MicroVM Lambda d’AWS simplifient le déploiement des environnements pour agents IA — et compliquent leur gouvernance par accident","html_url":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem?lang=fr","markdown_url":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem.md?lang=fr","json_url":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem.json?lang=fr","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem?lang=fr"},{"language":"pl","title":"MicroVM-y AWS Lambda ułatwiają wdrażanie piaskownic dla agentów AI — i przypadkiem utrudniają ich zarządzanie","html_url":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem?lang=pl","markdown_url":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem.md?lang=pl","json_url":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem.json?lang=pl","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem?lang=pl"},{"language":"ru","title":"Lambda MicroVM от AWS упрощают запуск песочниц для ИИ-агентов — и случайно усложняют управление ими","html_url":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem?lang=ru","markdown_url":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem.md?lang=ru","json_url":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem.json?lang=ru","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem?lang=ru"},{"language":"zh","title":"AWS Lambda MicroVM 让 AI 智能体沙箱更易部署，也让治理更容易被意外忽略","html_url":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem?lang=zh","markdown_url":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem.md?lang=zh","json_url":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem.json?lang=zh","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem?lang=zh"}],"_links":{"self":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem.json?lang=es","api":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem?lang=es","html":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem?lang=es","canonical":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem?lang=es","markdown":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem.md?lang=es","json":"https://publicasta.com/it_today_news/aws_lambda_microvms_make_agent_sandboxes_an_operations_problem.json?lang=es","channel":"https://publicasta.com/api/public/v1/channels/it_today_news","channel_articles":"https://publicasta.com/api/public/v1/channels/it_today_news/articles","search":"https://publicasta.com/api/public/v1/search","documentation":"https://publicasta.com/api-docs#reading-publicasta","openapi":"https://publicasta.com/api-docs/openapi.json","llms":"https://publicasta.com/llms.txt"}}