Las solicitudes de aprobación de agentes de IA no son autorización

El Agents SDK de OpenAI ahora trata la aprobación humana como estado del entorno de ejecución: una llamada a una herramienta sensible puede pausar la ejecución, mostrar una interrupción, guardar la decisión en RunState y reanudar la misma ejecución después de una aprobación o un rechazo.¹

Esa forma de producto acierta en algo importante. La aprobación pertenece al entorno de ejecución, no solo a una transcripción de chat.

La pregunta más difícil viene después: ¿qué autorizó realmente la persona?

Una solicitud de aprobación que dice “¿Permitir comando de shell?” o “¿Aprobar llamada a herramienta?” le pide al usuario que confíe en un momento. Un registro real de autorización delimita una acción, nombra el riesgo, captura evidencia, vence y crea una traza revisable. Los agentes de IA necesitan esta segunda forma porque planifican a lo largo de varios pasos, llaman herramientas anidadas, vuelven a intentar después de un rechazo y llevan explicaciones fluidas a decisiones donde una persona puede sentirse presionada a hacer clic en sí.

Resumen rápido

Las solicitudes de aprobación de agentes de IA no son autorización. Una solicitud puede pausar el trabajo, pero la autorización tiene que definir quién concede la autoridad, qué agente la recibe, qué herramienta puede ejecutarse, qué recurso puede tocar, qué categoría de riesgo aplica, cuánto dura la concesión, qué evidencia respaldó la decisión y cómo puede revocarla el operador. Los equipos deberían diseñar las aprobaciones como objetos de autoridad delimitada, no como interrupciones de chat. La pregunta correcta no es “¿alguien hizo clic en aprobar?”. La pregunta correcta es “¿qué acción concreta autorizó una persona responsable y bajo qué restricciones?”.

Ideas clave

Para equipos de producto: - Muestra la aprobación como un objeto de decisión tipado: acción, recurso, riesgo, evidencia, vencimiento y reversión. - Separa la confirmación de bajo riesgo de la autorización de alto riesgo.

Para equipos de seguridad: - Trata las solicitudes repetidas de aprobación como una superficie de ataque, no solo como un problema de UX. - Registra cada permiso, denegación, permiso automático, denegación automática, vencimiento y revocación.

Para quienes construyen agentes: - Pausa antes de una acción irreversible, no después de que el agente ya haya moldeado el resultado. - Devuelve el rechazo al modelo como una instrucción con restricciones, no como una falla vaga.

Para operadores: - Nunca apruebes una llamada a herramienta si no puedes ver el recurso de destino, el alcance de autoridad y el camino de reversión. - Prefiere concesiones delimitadas y de corta duración antes que hábitos persistentes de “aprobar siempre”.

¿Por qué fallan las solicitudes de aprobación?

Las solicitudes de aprobación fallan cuando comprimen una decisión con mucho contexto en un clic con poco contexto.

Un agente tiene más contexto del que muestra la solicitud. Puede haber leído archivos, resumido un hilo, planificado una secuencia, elegido una herramienta, completado argumentos y seleccionado un momento de ejecución. La solicitud de aprobación suele mostrar solo el último paso. El usuario ve un comando, una llamada a API, una acción en el navegador o una frase escrita por el mismo agente que pide permiso.

Esa interfaz crea cuatro fallas:

El Agentic Top 10 de OWASP nombra directamente la falla de persuasión. La publicación de lanzamiento dice que las explicaciones confiadas pueden inducir a operadores humanos a aprobar acciones dañinas bajo ASI09, Human-Agent Trust Exploitation.² El riesgo no requiere un modelo malicioso. Un agente servicial aun así puede vender de más un plan débil, minimizar la incertidumbre o esconder una llamada riesgosa a una herramienta dentro de una secuencia de acciones inofensivas.

Por eso, la aprobación necesita una forma mejor. Una persona debería aprobar un registro de acción, no una burbuja de solicitud.

¿Qué debería autorizar una aprobación?

Una aprobación seria debería autorizar una acción concreta bajo condiciones acotadas.

El artículo “Authenticated Delegation and Authorized AI Agents” plantea el problema más amplio como autoridad delegada: los usuarios necesitan una forma de restringir los permisos de los agentes y mantener cadenas claras de responsabilidad mediante credenciales específicas para agentes, metadatos y configuraciones auditables de control de acceso.³

Ese marco encaja con claridad en el diseño de producto. Una aprobación debería contener:

Sin esos campos, la aprobación se vuelve una corazonada con un botón. Un modelo puede pedir permiso con cortesía. Una persona puede hacer clic con rapidez. Ninguno de esos eventos prueba que la acción correspondiera.

¿Cómo debería funcionar el estado de aprobación?

El estado de aprobación debería sobrevivir a la pausa, pero mantenerse estrecho.

La documentación del Agents SDK de OpenAI describe un patrón útil del entorno de ejecución. Las herramientas pueden declarar needs_approval; el ejecutor evalúa la regla de aprobación antes de ejecutar; las aprobaciones sin resolver aparecen como interrupciones; el desarrollador puede aprobar o rechazar cada elemento pendiente; y la ejecución se reanuda desde RunState.¹ La documentación también describe decisiones persistentes como always_approve y always_reject para llamadas posteriores dentro de la misma ejecución.¹

La máquina de estados importa porque una ejecución pausada de un agente no debería reiniciarse desde la memoria, recrear la intención ni perder el contexto de aprobación. Debería reanudarse desde el punto interrumpido con la decisión adjunta.

La opción de decisión persistente crea el siguiente requisito de diseño: toda aprobación persistente necesita alcance y vencimiento.

La aprobación persistente puede reducir la fatiga. Una aprobación persistente demasiado amplia puede convertir un clic cansado en todo el alcance de impacto de una ejecución.

¿Dónde debería ubicarse la aprobación en el entorno de ejecución?

La aprobación debería ubicarse antes del punto de confirmación.

Un punto de confirmación es el momento en que un agente cruza de trabajo reversible a efecto secundario: modificar un recurso de producción, enviar un mensaje, gastar dinero, publicar contenido, eliminar datos, rotar una clave, cambiar permisos o desplegar código. La aprobación humana después del punto de confirmación se vuelve respuesta a incidentes, no autorización.

La literatura sobre supervisión humana respalda esa distinción. Un artículo de 2026 en AI and Ethics separa la agencia operativa, donde la IA genera o actúa, de la agencia evaluativa, donde la persona puede evaluar, disputar y anular.⁴ La supervisión eficaz no puede depender de que una persona observe cada token. La interfaz tiene que reservar el juicio humano para puntos donde ese juicio todavía pueda cambiar el resultado.

Eso les da a los productos de agentes una regla simple:

Una solicitud que aparece después de que el agente ya ejecutó la parte riesgosa solo crea teatro. La persona no puede ejercer agencia evaluativa si el sistema ya gastó la autoridad.

¿Cómo se previene la fatiga de aprobación?

La fatiga de aprobación es un bug de seguridad porque cambia la decisión.

Si una ejecución pide 40 aprobaciones, probablemente el producto ya falló antes de que el usuario haga clic. El operador deja de juzgar cada elemento y empieza a administrar la molestia. Los atacantes pueden explotar ese patrón generando solicitudes repetidas, escondiendo acciones riesgosas dentro de lotes o usando lenguaje que haga parecer rutinaria una llamada peligrosa.

El Agentic Top 10 de OWASP trata la explotación de confianza humano-agente como una categoría de riesgo de primer nivel.² La investigación de seguridad en agentes llega a la misma forma desde el lado del sistema. Una sistematización de marzo de 2026 sobre seguridad de IA agéntica mapea límites de confianza entre inyección de prompts, envenenamiento de RAG, exploits de herramientas y plugins, y amenazas entre múltiples agentes; también pide controles de monitoreo en tiempo de ejecución y respuesta a incidentes.⁵ Un artículo de mayo de 2026 sobre agentes auditables en seguridad sostiene que las listas estáticas de materiales y los registros en tiempo de ejecución ofrecen evidencia fragmentada a menos que el sistema pueda conectar capacidades, memoria, objetivos, trayectorias de razonamiento y acciones en rutas de auditoría consultables.⁶

El diseño de aprobación debería reducir la fatiga eliminando solicitudes de bajo valor y elevando la calidad de las solicitudes de alto valor:

El objetivo no es tener menos controles. El objetivo es tener menos controles sin significado.

¿Qué debería mostrar la UI de aprobación?

La UI de aprobación debería mostrar la decisión, no la personalidad del agente.

Empieza con una tarjeta compacta de decisión:

Esa tarjeta ayuda al usuario a responder una pregunta: ¿la acción solicitada coincide con la evidencia y el alcance?

La tarjeta no debería esconder los argumentos exactos. No debería ocultar la denegación. No debería convertir “aprobar” en el único camino diseñado mientras “rechazar” se comporta como una excepción. Una buena superficie de aprobación trata el rechazo como una señal de control normal. El agente debería recibir un mensaje preciso: “Denegado porque las URL de origen no se verificaron” o “Denegado porque el comando toca archivos fuera del alcance del lanzamiento”.

¿Qué deberían construir primero los equipos?

Construyan un registro de aprobaciones antes de crear una solicitud más bonita.

Campos mínimos del registro:

1. ID de ejecución.
2. ID de agente.
3. ID de operador.
4. Nombre de la herramienta.
5. Argumentos de la herramienta.
6. Recurso de destino.
7. Categoría de riesgo.
8. Regla de aprobación que se activó.
9. Punteros de evidencia.
10. Decisión: aprobado, rechazado, aprobado automáticamente, rechazado automáticamente, vencido o revocado.
11. Hora de la decisión.
12. Condición de vencimiento.
13. Resultado después de la ejecución.
14. Puntero de reversión o contención.

El registro convierte una aprobación de un evento de UI en un registro de responsabilidad. También permite que los equipos hagan mejores preguntas más adelante:

• ¿Qué herramientas piden aprobación con demasiada frecuencia?
• ¿Qué operadores aprueban más rápido las acciones de alto riesgo?
• ¿Qué reglas de aprobación generan falsos positivos?
• ¿Qué acciones denegadas encontraron después alternativas seguras?
• ¿Qué acciones aprobadas exigieron rollback?
• ¿Qué concesiones persistentes permanecieron activas demasiado tiempo?

El artículo de mayo de 2026 sobre seguridad de sistemas operativos sostiene que los agentes enfrentan problemas familiares del estilo OS: aislamiento de recursos, separación de privilegios y comunicación mediada.⁷ La aprobación pertenece a esa misma familia. El entorno de ejecución debería mediar la autoridad como un sistema operativo media operaciones privilegiadas: de forma estrecha, consistente y con registros que sobrevivan a la solicitud.

Resumen breve

Las aprobaciones de agentes de IA tienen que convertirse en objetos de autorización. Una solicitud de pausa y clic puede detener una llamada a herramienta, pero por sí sola no puede cargar responsabilidad. Los sistemas útiles de aprobación definen actor, acción, recurso, riesgo, evidencia, duración, vencimiento, revocación y auditoría.

La lección de producto es directa: haz que el trabajo de bajo riesgo sea silencioso, haz explícito el trabajo de alto riesgo y nunca le pidas a una persona que apruebe una explicación fluida cuando el sistema puede mostrar un registro de acción delimitado.

Preguntas frecuentes

¿Cuál es la diferencia entre aprobación y autorización para agentes de IA?

La aprobación es un evento de decisión humana. La autorización es la autoridad delimitada que permite a un agente realizar una acción concreta bajo condiciones definidas. Los sistemas sólidos de agentes conectan ambas cosas: una aprobación humana crea un registro estrecho de autorización con campos de recurso, riesgo, vencimiento, evidencia y auditoría.

¿Cada llamada a herramienta de un agente de IA debería requerir aprobación?

No. Los equipos deberían enrutar las aprobaciones según el riesgo. Las lecturas de bajo riesgo dentro de un alcance conocido pueden ejecutarse en silencio con registros. Las acciones de riesgo medio pueden agruparse para revisión. Las acciones de alto riesgo, como enviar mensajes, publicar, eliminar, desplegar, gastar, exportar o cambiar permisos, deberían pausar antes de ejecutarse.

¿Son seguras las aprobaciones persistentes para agentes de IA?

Las aprobaciones persistentes pueden ayudar cuando el alcance se mantiene estrecho, visible y de corta duración. Una aprobación limitada a una ejecución para una herramienta de solo lectura puede tener sentido. Una aprobación persistente amplia para acciones de shell, despliegue, pago, envío de email o eliminación crea demasiada autoridad a partir de una sola decisión.

¿Qué debería incluir una solicitud de aprobación para un agente de IA?

Una solicitud de aprobación debería incluir la acción, el recurso, los argumentos de la herramienta, el actor, la categoría de riesgo, la evidencia, el vencimiento, el camino de reversión y el puntero de auditoría. La solicitud también debería ofrecer decisiones como rechazar, pedir evidencia y dividir el alcance, no solo aprobar.

¿Cómo pueden los equipos reducir la fatiga de aprobación en productos con agentes?

Los equipos pueden reducir la fatiga permitiendo automáticamente acciones de bajo riesgo dentro de la política, agrupando decisiones de riesgo medio, interrumpiendo solo en puntos de confirmación, mostrando evidencia estructurada, haciendo vencer las concesiones y registrando la denegación como una ruta de control normal. Las mejores aprobaciones hacen menos preguntas vagas y más preguntas precisas.

Referencias