AWS Rex publica como código abierto la capa de ejecución de seguridad de IA agente
El 4 de mayo de 2026, AWS publicó Introducing Trusted Remote Execution: Policy-Enforced Scripts for AI Agents and Humans, liberando Rex como código abierto bajo la licencia Apache 2.0. La arquitectura es sencilla: los scripts se escriben en Rhai, un lenguaje embebido ligero sin acceso al sistema operativo por defecto. La única forma en que un script puede interactuar con el host es a través de un SDK diseñado para ese propósito. Cada operación se autoriza según una política Cedar antes de permitir la llamada al sistema. Si la política niega la acción, el script recibe un ACCESS_DENIED_EXCEPTION y la operación nunca llega al kernel.
AWS está admitiendo, en código de producción, lo que la comunidad de investigación en seguridad ha argumentado durante dos años: la revisión de código, los flujos de aprobación y los comandos permitidos no pueden controlar el código generado en tiempo de ejecución por un sistema de IA. Las redes de seguridad tradicionales dejan de funcionar cuando el agente es el autor.
5 conclusiones clave
1. AWS introdujo la aplicación de políticas en tiempo de ejecución como una categoría.
Trusted Remote Execution (Rex) controla cada operación del sistema que un script generado por IA intenta ejecutar, aplicando una política Cedar definida por el propietario del host — no por el agente. Es el primer reconocimiento importante, respaldado por un hyperscaler, de que la capa de tiempo de ejecución en la seguridad de IA agente no puede dejarse al propio agente. Cuando AWS implementa infraestructura de producción asumiendo que la inyección de prompts no se resolverá, la implicación para los arquitectos empresariales es clara: diseña como si el agente fuera a comportarse mal.
2. El modelo de amenazas es explícito e incómodo.
AWS menciona el código alucinado, la inyección de prompts y la interpretación excesivamente entusiasta de tareas como los modos de fallo específicos que Rex está diseñado para contener. OpenAI ha dicho que la inyección de prompts «probablemente nunca se ‘resuelva’ por completo». Anthropic ha reconocido que está lejos de resolverse, «especialmente a medida que los modelos toman más acciones en el mundo real». Rex se lanza bajo esas concesiones — y tu arquitectura de gobernanza de IA también debería hacerlo.
3. Rex restringe al host, no al agente.
La mayoría de los entornos sandbox para agentes intentan limitar lo que produce el modelo. Rex invierte ese enfoque: sin importar lo que genere el agente, la llamada al sistema no puede exceder lo que permite la política. Esta inversión arquitectónica — trasladar el perímetro de aplicación a lo que el agente puede hacer contra el host — no es un refinamiento incremental. Es un cambio en dónde se permite que resida la confianza. La confianza pasa de las salidas del agente al motor de políticas del host.
4. El control en tiempo de ejecución es necesario. No es suficiente.
Las políticas Cedar sobre llamadas al sistema no pueden indicarle a un agente qué documento no debería haber solicitado, qué campos cumplen con el mínimo necesario, o si una recuperación cruza un límite jurisdiccional que la clasificación de datos marca como fuera de alcance. Estos son los controles que exige el Artículo 5 del GDPR, el estándar mínimo necesario de HIPAA y las familias de control de acceso de CMMC nivel 2. Rex no los resuelve.
5. La capa defendible en auditoría está por debajo del tiempo de ejecución.
Reguladores, auditores y demandantes pedirán pruebas de quién autorizó qué acceso a datos. Esa evidencia debe residir donde viven los datos — en registros de auditoría a prueba de manipulaciones que cubran cada interacción de IA con contenido regulado. Una política que permite una lectura de llamada al sistema es la política correcta en la capa de tiempo de ejecución. Es la política incorrecta en la capa de datos, y son instrumentos diferentes.
Confías en que tu organización es segura. Pero ¿puedes comprobarlo?
Lee ahora
Lo que AWS está admitiendo sobre la IA agente
Tres concesiones arquitectónicas en el anuncio de AWS son tan importantes como el propio código.
La primera es el modelo de amenazas. El código alucinado, la inyección de prompts y la interpretación excesivamente entusiasta de tareas se mencionan explícitamente — no como casos teóricos, sino como los modos de fallo específicos que Rex está diseñado para contener. Cuando un hyperscaler lanza infraestructura asumiendo que estos problemas no se resolverán, los arquitectos empresariales deben diseñar en consecuencia.
La segunda es la inversión arquitectónica. Rex traslada el perímetro de aplicación a lo que el agente puede hacer contra el host, en lugar de intentar limitar las salidas del agente. Esa formulación es precisa: restringir al agente supone que sus salidas pueden limitarse de forma fiable. Cambiar al host supone que esos límites no son fiables y traslada la aplicación a donde realmente se ejecuta el sistema. Es una decisión de arquitectura de confianza, no una decisión de funcionalidad.
La tercera está en el modelo de políticas. Cedar — liberado como código abierto por AWS en mayo de 2023 y ahora un proyecto Sandbox de CNCF — soporta tanto RBAC como ABAC. El propietario del host, no el agente, define la política. El script y la política se versionan por separado. Esto es política como código aplicada a la capa de llamadas al sistema — la capa adecuada para ese patrón, y también la única que aborda Rex.
Por qué el control en tiempo de ejecución es necesario
Rex resuelve un problema real. La mayoría de los entornos de ejecución de scripts otorgan a los scripts todos los permisos que tiene el contexto de ejecución — un script pensado para leer un archivo de registro puede eliminarlo igual de fácil. Cuando ese script es generado por un agente de IA en tiempo de ejecución, los controles tradicionales de revisión nunca tienen oportunidad de actuar. Un agente que se comporta mal en ese entorno está a una tarea mal interpretada de causar daños en producción.
La previsión Kiteworks 2026 cuantifica esta exposición. El 63% de las organizaciones no puede imponer limitaciones de propósito a los agentes de IA. El 60% no puede terminar rápidamente un agente que se comporta mal. El 55% no puede aislar los sistemas de IA del acceso más amplio a la red. El 54% no puede validar las entradas de IA. La aplicación de políticas en tiempo de ejecución al estilo Rex cierra de manera significativa la primera y la última de esas brechas. También hay una dimensión regulatoria: las organizaciones bajo presión de la Ley de IA de la UE están construyendo la infraestructura de tiempo de ejecución, identidad y políticas que representa Rex más rápido que sus pares fuera de ese perímetro. El entorno de asesoría está cerrando esa brecha rápidamente en todas las jurisdicciones.
Por qué el control en tiempo de ejecución no es suficiente
Rex es un control de tiempo de ejecución. Gobierna las llamadas al sistema. No puede decirle a un agente qué documento no debería haber solicitado en primer lugar. No puede imponer que un registro devuelto contenga solo los campos que el usuario humano está autorizado a ver. No puede evaluar si una recuperación cruza un límite jurisdiccional que la clasificación de datos marca como fuera de alcance.
Estos no son casos teóricos. Son los controles que exige el Artículo 5 del GDPR — limitación de propósito, minimización de datos, limitación de almacenamiento, responsabilidad. Son lo que requiere el estándar mínimo necesario de HIPAA. Son lo que asumen las familias de control de acceso de CMMC nivel 2. Son lo que CISA, NSA y el comunicado conjunto de Five Eyes sobre IA agente mencionan explícitamente en sus categorías de riesgo de responsabilidad y privilegios.
Una política que permite file_system::Action::"read" en /var/data/customer-records.csv es la política correcta en la capa de tiempo de ejecución. Es la política incorrecta en la capa de datos. La capa de datos debe hacer preguntas diferentes: ¿Esta lectura ocurre en nombre de un usuario con la autorización adecuada? ¿El solicitante opera dentro del alcance de la relación que lo autorizó? ¿Los registros son los mínimos necesarios para la tarea? ¿Alguno está sujeto a una solicitud de eliminación que aún no se ha propagado? ¿El acceso se registra con suficiente detalle para reconstruir quién autorizó qué tres años después de que el modelo haya sido retirado? Rex no responde a esas preguntas.
La imagen arquitectónica que realmente funciona
El patrón que funciona es por capas. Los controles de tiempo de ejecución como Rex imponen lo que el host permitirá. Los controles de identidad determinan en nombre de quién actúa el agente. Los controles de la capa de datos — controles de acceso basados en atributos evaluados según clasificación, jurisdicción y consentimiento — imponen qué datos puede manipular el agente. Cada capa aborda un modo de fallo distinto, y ninguna capa por sí sola es suficiente.
Kiteworks Secure MCP Server y AI Data Gateway implementan el componente de capa de datos de esta arquitectura: cada operación de IA se autentica mediante OAuth 2.0, se evalúa según la política ABAC en el motor de políticas de datos de Kiteworks, se cifra con criptografía validada FIPS 140-3 y se registra en un registro de auditoría a prueba de manipulaciones que alimenta la infraestructura SIEM existente. Kiteworks Private Data Network amplía esa gobernanza a correo electrónico, uso compartido de archivos, MFT, SFTP, formularios web y APIs bajo un solo motor de políticas y un registro de auditoría consolidado.
AWS acaba de lanzar una infraestructura robusta para la capa de tiempo de ejecución. La capa de identidad y la de datos aún deben construirse — y la previsión Kiteworks 2026 confirma que solo el 43% de las organizaciones cuenta con una puerta de enlace de datos IA centralizada.
Qué deben aprender los equipos de seguridad y cumplimiento
Primero, toma el anuncio de AWS como una señal importante. Cuando un hyperscaler libera como código abierto un control de tiempo de ejecución que aplica políticas independientes del agente a cada llamada al sistema, la aplicación de políticas en tiempo de ejecución deja de ser opcional en implementaciones de IA serias. Rex cierra una brecha significativa en la capa de tiempo de ejecución que la mayoría de las organizaciones ha dejado abierta.
Segundo, no confundas la aplicación en tiempo de ejecución con la gobernanza de datos. Rex aborda lo que un agente puede hacer en un host. No dice nada sobre qué datos puede manipular el agente. Añadir control en tiempo de ejecución sin gobernanza en la capa de datos no cierra la brecha de auditoría — documenta una capa y deja la otra abierta.
Tercero, diseña explícitamente la arquitectura por capas. Mapea los controles de tiempo de ejecución (Rex), controles de identidad (OAuth, credenciales de corta duración) y controles de la capa de datos (ABAC, clasificación, jurisdicción, consentimiento) a los modos de fallo específicos que aborda cada uno. Cada capa plantea preguntas distintas; todas son necesarias para una respuesta completa.
Cuarto, trata el control de versiones de políticas como evidencia de auditoría. La separación de política y código en Cedar produce artefactos que los auditores pueden revisar. Combina los artefactos de tiempo de ejecución de Rex con registros de auditoría a prueba de manipulaciones en la capa de datos para obtener un paquete de evidencia completo — la brecha entre la visibilidad de lo que se ejecutó y la visibilidad de qué datos se manipularon es donde surgen la mayoría de los hallazgos de auditoría.
Quinto, utiliza el comunicado conjunto de Five Eyes como prueba arquitectónica. Aplica las cinco categorías de riesgo de la CISA «Adopción cuidadosa de servicios de IA agente» — privilegio, diseño y configuración, comportamiento, estructura, responsabilidad — a tu implementación actual de IA. Rex aborda partes de privilegio y comportamiento. Las categorías de estructura y responsabilidad requieren gobernanza en la capa de datos que ningún control de tiempo de ejecución puede proporcionar por sí solo.
Si quieres saber más sobre cómo gobernar datos sensibles mientras optimizas agentes de IA, agenda una demo personalizada hoy mismo.
Preguntas frecuentes
Rex aborda la aplicación de políticas a nivel de llamadas al sistema en scripts — la capa donde un script generado por un agente se controla mediante una política Cedar antes de que cualquier lectura, escritura o apertura llegue al kernel. No reemplaza los controles de identidad, la segmentación de red ni la gobernanza en la capa de datos. Solo el 43% de las organizaciones cuenta con una puerta de enlace de datos IA centralizada según la previsión Kiteworks 2026. Añadir Rex sin esa capa de datos cierra una brecha y deja otra más amplia abierta.
El modelo de política como código de Cedar produce artefactos versionados que cumplen con los controles de acceso SOC 2 CC6 y la gestión de acceso ISO 27001 A.5/A.8 — pero no es evidencia suficiente de autorización en la capa de datos. Combina el registro de auditoría de tiempo de ejecución de Rex con la aplicación ABAC en la capa de datos y registros a prueba de manipulaciones para obtener un paquete de evidencia completo. Los auditores solicitan cada vez más evidencia de contención — prueba de que un agente que se comporta mal puede ser terminado y aislado rápidamente.
No. El estándar mínimo necesario de HIPAA requiere controles sobre qué datos puede acceder el agente en nombre de un usuario autorizado — no solo sobre qué llamadas al sistema puede hacer el script. La limitación de propósito es un control semántico de datos. El 63% de las organizaciones no puede imponerlo a agentes de IA según la previsión Kiteworks 2026. Los controles de tiempo de ejecución y la aplicación ABAC en la capa de datos funcionan juntos; ninguno reemplaza al otro.
Rex aborda partes de dos de las cinco categorías de riesgo en el comunicado de CISA: riesgos de privilegio (aplicando el menor privilegio en operaciones del sistema) y riesgos de comportamiento (contener código alucinado o inyectado). No aborda las categorías de riesgo estructural o de responsabilidad. La categoría de responsabilidad — la que más revisan auditores y reguladores — requiere un registro de auditoría en la capa de datos que el control en tiempo de ejecución por sí solo no puede producir.
Existe cierto solapamiento y una clara separación. Rex aplica políticas en el límite de llamadas al sistema dentro de un host. Los proxies con reconocimiento de identidad y las políticas de service mesh aplican políticas en los límites de red y de solicitudes. Ambos son controles de tiempo de ejecución en diferentes capas de la tecnología. El aislamiento de red de los sistemas de IA — una brecha que abordan las políticas de mesh pero no Rex — sigue siendo una deficiencia en toda la industria. La aplicación por capas es la respuesta arquitectónica; tratar cualquier capa como suficiente es el error arquitectónico. Kiteworks Private Data Network proporciona el componente de capa de datos que necesita esta tecnología.
Recursos adicionales
- Artículo del Blog
Estrategias Zero‑Trust para una protección de privacidad de IA asequible - Artículo del Blog
Cómo el 77% de las organizaciones está fallando en la seguridad de datos de IA - eBook
Brecha de gobernanza de IA: por qué el 91% de las pequeñas empresas juega a la ruleta rusa con la seguridad de datos en 2025 - Artículo del Blog
No existe «–dangerously-skip-permissions» para tus datos - Artículo del Blog
Los reguladores ya no preguntan si tienes una política de IA. Quieren pruebas de que funciona.