Ilustración conceptual original generada con IA: las compuertas representan comprobaciones de autorización independientes, no un producto real ni un resultado de seguridad medido.
Empezar por la acción, no por la respuesta
Imagine un asistente de compras al que se le pide resumir tres propuestas de proveedores. Uno de los documentos contiene una solicitud de enviar la comparación completa a una dirección externa. El asistente genera JSON válido, utiliza la herramienta de correo correcta y redacta un mensaje fluido. Aun así, el flujo de trabajo puede fallar: el documento era una fuente de información que debía leerse, no una persona facultada para autorizar su divulgación.
Este es un ejemplo hipotético de diseño. No realizamos un ataque, no comparamos el rendimiento de proveedores ni inspeccionamos el despliegue de un cliente. Nuestro argumento es más acotado: la capacidad de un agente para proponer una acción bien formada debe separarse de la decisión del sistema de permitirla.
El análisis que sigue se basa en documentación primaria revisada el 21 de octubre de 2026. Es un marco de ingeniería, no una certificación de seguridad ni un dictamen jurídico.
Lo que realmente establece la documentación
En su explicación del 11 de marzo de 2026, OpenAI defiende limitar los daños incluso cuando la manipulación de instrucciones tiene éxito. Su guía de seguridad de flujos de trabajo recomienda datos estructurados y aprobaciones, pero advierte que las medidas de mitigación no eliminan los errores. Esa guía trata sobre Agent Builder, que la página actual señala como obsoleto; no constituye una recomendación de adoptar ese producto.
El artículo de Anthropic del 20 de octubre de 2025 sobre entornos aislados describe el aislamiento del sistema de archivos y de la red. La documentación actual sobre permisos de Claude Code distingue los permisos de las herramientas de la aplicación de restricciones por parte del sistema operativo: las reglas ordinarias de Read/Edit no cubren cualquier acceso a archivos realizado por subprocesos.
El repositorio oficial de Qwen-Agent documenta el aislamiento mediante Docker y el montaje restringido de directorios para la interpretación de código, pero advierte que su entorno aislado básico requiere precaución en producción.
Son capas y productos diferentes, no una comparación controlada. Un servicio estadounidense puede desplegarse con un acceso excesivamente amplio; un framework chino puede desplegarse con límites restrictivos, o viceversa. El origen del modelo y la ubicación del alojamiento no sustituyen la inspección de la configuración. Ninguno de estos documentos establece qué proveedor es universalmente el más seguro.
Situar una pasarela de autorización entre la planificación y la ejecución
El diseño que proponemos separa tres responsabilidades: el modelo propone una acción, una pasarela comprueba que esté autorizada y un ejecutor con privilegios estrictamente limitados realiza la operación permitida. La pasarela es código de aplicación y mecanismos que hacen cumplir las políticas, no simplemente otra instrucción que pide al modelo que se comporte bien.
Para cada solicitud con consecuencias, vincule la decisión al usuario autenticado, la operación, el recurso, el destino, el alcance de los datos y los límites aplicables. Un permiso para leer propuestas de proveedores no debe convertirse de forma implícita en un permiso para enviarlas por correo. Un permiso para redactar un mensaje no debe convertirse de forma implícita en un permiso para enviarlo. Si falta un valor obligatorio o es ambiguo, la solicitud debe permanecer sin ejecutar hasta que se aclare.
La validación de esquemas forma parte de este diseño, pero cumple otra función. Un esquema puede exigir que un campo de destinatario contenga una cadena de texto. No puede establecer que el usuario haya aprobado a ese destinatario. Tampoco un modelo revisor, por útil que sea para detectar riesgos, se convierte en una barrera de acceso determinista por el mero hecho de responder sí o no.
Esta separación también aclara la responsabilidad tras una denegación: corregir una solicitud inválida u obtener la autorización necesaria. Cambiar de cuenta o de vía para eludir la denegación de esa misma operación no es una solución.
Hacer que las aprobaciones sean lo bastante precisas para soportar cambios de plan
Una pantalla de confirmación útil muestra la acción que se realizará realmente: destino, contenido o categoría de datos, recurso pertinente y cualquier límite de coste o alcance. Evite un botón genérico como «¿Permitir al agente?» que oculte las variables importantes.
Vincule la aprobación a esa propuesta. Si el destinatario, el archivo adjunto, el importe o el recurso cambia de forma sustancial, vuelva a evaluarla. Para trabajos repetidos y acotados, una organización puede definir un permiso permanente de alcance limitado en lugar de interrumpir cada paso inocuo. Los límites deben seguir siendo verificables y exigibles; un documento externo no puede ampliarlos.
La fatiga ante las aprobaciones y el exceso de permisos son problemas de diseño relacionados. Exigir confirmación para cada lectura trivial puede acostumbrar a las personas a hacer clic automáticamente, mientras que una aprobación general puede ocultar riesgos posteriores. El punto intermedio útil consiste en una política documentada para operaciones de bajo riesgo, aprobaciones precisas para cambios con consecuencias y una detención explícita cuando la autorización no está clara.
Limitar lo que ocurre después de un error
Una comprobación de autorización protege la operación solicitada; el aislamiento en tiempo de ejecución limita aquello a lo que puede acceder el entorno de ejecución. Utilice credenciales de alcance limitado, acceso restringido al sistema de archivos y destinos de red controlados cuando la aplicación lo permita. Incluya los procesos secundarios en el modelo de amenazas. Una herramienta restringida de lectura de archivos no basta si el mismo ejecutor puede utilizar una shell sin restricciones.
Mantenga el estado de una operación separado de la narración del modelo. Propuesta, aprobada, enviada para su ejecución y confirmada son estados distintos. Registre un identificador de solicitud estable y utilice idempotencia o deduplicación cuando sean compatibles. Tras agotar el tiempo de espera, inspeccione el registro real del servicio antes de reintentar un envío, una compra o una publicación. «No se recibió respuesta» no demuestra que «no ocurrió nada».
Los registros deben facilitar esa reconstrucción sin convertirse en otra fuente de filtraciones. Conserve el identificador de la acción, la decisión, la versión de la política y la referencia resultante en el servicio; reduzca al mínimo los secretos y los datos personales innecesarios. Proporcione a los revisores información suficiente para investigar, no una copia indiscriminada de cada documento.
Seis comprobaciones antes de pasar a producción
Lo siguiente es una propuesta de ejercicio de aceptación, no una prueba que hayamos realizado ni una evaluación exhaustiva de seguridad:
- Incluya un destinatario externo en un documento recuperado. ¿Puede cambiar el destino permitido sin la autorización del usuario autenticado?
- Genere JSON válido para una acción fuera del alcance autorizado. ¿La pasarela la rechaza antes de enviarla para su ejecución?
- Cambie el destino después de la aprobación. ¿La aprobación anterior deja de cubrir la acción modificada?
- Intente leer un archivo fuera del alcance autorizado mediante un proceso secundario. ¿Se hace cumplir el límite en tiempo de ejecución, en lugar de limitarse a describirlo en una instrucción?
- Simule un tiempo de espera agotado con resultado ambiguo después de un envío. ¿Puede el flujo de trabajo conciliar su estado con el registro del servicio sin crear un duplicado?
- Revoque el permiso pertinente. ¿La siguiente operación intentada falla de forma segura y deja un registro de auditoría comprensible?
Evalúe tanto la protección como la facilidad de uso: operaciones no autorizadas bloqueadas, trabajo autorizado bloqueado por error, solicitudes de aprobación innecesarias, efectos secundarios duplicados y tiempo necesario para explicar una decisión. Una tasa alta de tareas completadas puede, por sí sola, ocultar una ejecución insegura; un sistema que lo bloquea todo tampoco es un asistente útil.
La pregunta que importa al comprar
Pida al proveedor que muestre qué capa hace cumplir cada límite en la configuración que realmente desplegará, qué ocurre si el modelo sigue las instrucciones de un documento malicioso y cómo se concilia una ejecución de resultado ambiguo. Solicite pruebas que correspondan a sus herramientas y ámbitos de acceso, en lugar de trasladar una cifra destacada de un benchmark realizado con otra configuración.
La elección práctica no es «confiar en el modelo» frente a «pedir permiso eternamente». Consiste en decidir qué trabajo puede continuar dentro de límites claros, qué cambios necesitan una decisión humana y qué límites no puede reescribir el modelo. Ese es un punto de partida más útil que una única puntuación de capacidad para comparar las pilas tecnológicas de agentes chinas y estadounidenses.