Cómo auditar sus agentes de IA antes de una evaluación de seguridad empresarial

El software tradicional hace exactamente lo mismo cada vez que se ejecuta. Eso es lo que lo hace auditable. Un agente de IA, no. Razona, selecciona herramientas y toma medidas que varían con cada entrada. Eso es lo que lo hace útil. También es la razón por la que su proceso actual de revisión de seguridad no fue diseñado para ello.

En diciembre de 2025, OWASP publicó su primer Top 10 para Aplicaciones Agénticas, desarrollado por más de 100 expertos en seguridad, que cubre los riesgos específicos de los agentes de IA autónomos. El NIST lanzó una Iniciativa de Estándares de Agentes de IA en febrero de 2026. Microsoft lanzó un kit de herramientas de gobernanza de agentes de código abierto en abril de 2026 que aborda los 10 riesgos agénticos de OWASP con aplicación en tiempo de ejecución. Los marcos regulatorios ya existen. Sus agentes deben estar preparados para ellos.

Por qué las auditorías de agentes son diferentes de las auditorías de aplicaciones

Una auditoría de seguridad de aplicaciones estándar verifica las entradas, las salidas, los controles de acceso y los flujos de datos. La aplicación se comporta de la misma manera cada vez para la misma entrada, por lo que es posible probarla sistemáticamente.

Los agentes de IA rompen esa premisa. El comportamiento de un agente depende de la instrucción (prompt) que recibe, del contexto que recupera, de las herramientas de las que dispone y de la ruta de razonamiento que toma. La misma entrada puede producir diferentes llamadas a herramientas, diferentes patrones de acceso a datos y diferentes resultados en ejecuciones consecutivas. La "superficie de ataque" no es un conjunto fijo de endpoints. Es cada acción que el agente podría tomar, y eso crece con cada herramienta y permiso que se le concede.

Esto no es algo teórico. En junio de 2025, una inyección de instrucciones sin clics (zero-click) en Microsoft 365 Copilot (CVE-2025-32711, CVSS 9.3) permitió la filtración de datos sin interacción del usuario. El agente procesó un correo electrónico malicioso, siguió instrucciones ocultas y envió datos confidenciales a un endpoint externo. En 2026, una inyección de instrucciones oculta en las descripciones de las solicitudes de extracción (pull requests) de GitHub Copilot (CVE-2025-53773, CVSS 9.6) desencadenó la ejecución remota de código. En ambos casos, los agentes hacían aquello para lo que fueron diseñados (seguir instrucciones), salvo que las instrucciones procedían de un atacante.

El 88 % de las organizaciones que utilizan agentes de IA informaron de un incidente de seguridad confirmado o sospechoso en el último año. Solo el 6 % de los presupuestos de seguridad se dedica a la seguridad de los agentes de IA. Al 97 % de las organizaciones que sufrieron brechas les faltaban controles de acceso adecuados para la IA. Forrester predice que el despliegue de una IA agéntica provocará una brecha de seguridad de difusión pública en 2026, siendo la causa principal los fallos de gobernanza y no los atacantes sofisticados.

El Top 10 agéntico de OWASP y lo que cada uno significa para su auditoría

El OWASP Top 10 para Aplicaciones Agénticas se organiza en torno a las capacidades del agente, no a las clases de vulnerabilidad tradicionales. Las cinco categorías que más importan para una auditoría previa son:

Secuestro del objetivo del agente (Agent Goal Hijack - ASI-01). Un atacante redirige el objetivo del agente mediante la inyección de instrucciones o la manipulación del contexto. El ataque sin clics a Microsoft Copilot es el ejemplo de manual. Verificación de auditoría: ¿Puede el contenido externo (correos electrónicos, documentos, páginas web recuperadas por el agente) modificar los objetivos de este? ¿Existe validación de entradas entre el contexto recuperado y el conjunto de instrucciones del agente?

Agentes rebeldes (Rogue Agents - ASI-02). Un agente supera su alcance previsto debido a una desviación del objetivo o a una explotación. La ejecución remota de código (RCE) en GitHub Copilot demostró cómo se puede instrumentalizar un agente como arma a través de sus canales de entrada habituales. Verificación de auditoría: ¿Tiene cada agente un límite de alcance definido con aplicación en tiempo de ejecución? ¿Existe un botón de parada de emergencia (kill switch)?

Uso indebido de herramientas (Tool Misuse - ASI-03). Un agente utiliza sus herramientas de forma no deseada porque los permisos eran demasiado amplios. La crisis de OpenClaw expuso más de 21 000 instancias de agentes porque los permisos de las herramientas no se limitaron al acceso mínimo necesario. Verificación de auditoría: ¿Tiene cada herramienta una validación de entrada explícita y los permisos mínimos requeridos?

Explotación de la confianza delegada (Delegated Trust Exploitation - ASI-04). En sistemas multiagente, un agente delega en otro, creando cadenas de confianza. El ataque a la cadena de suministro de Drift/Salesforce demostró que el robo de tokens OAuth de una integración se propagó a más de 700 entornos de clientes. Verificación de auditoría: ¿Verifica cada agente los resultados de los demás agentes? ¿Se imponen límites de confianza en cada punto de delegación?

Vulnerabilidades de la cadena de suministro (Supply Chain Vulnerabilities - ASI-05). Las herramientas de terceros, los complementos (plugins) y los agentes de mercados externos introducen riesgos que la organización que realiza el despliegue no controla. Verificación de auditoría: ¿Existe una lista verificada de herramientas y complementos aprobados? ¿Se tratan los resultados de agentes de terceros como entradas no confiables?

La lista de verificación previa a la auditoría en 8 puntos

Los marcos de OWASP, NIST, el marco MAESTRO de Cloud Security Alliance y el marco AEGIS de Forrester convergen en los mismos controles. Revise estas ocho verificaciones antes de su próxima auditoría.

1. Identidad y acceso de los agentes

Cada agente obtiene una identidad única, no credenciales compartidas. Cada llamada a una herramienta se autentica. Se aplica el principio de mínimo privilegio por agente, no por despliegue. Solo el 22 % de las empresas tratan hoy a los agentes como identidades independientes. El otro 78 % utiliza credenciales compartidas, lo que significa que un agente comprometido compromete todo lo que esté bajo esa misma credencial.

2. Límites de alcance con aplicación en tiempo de ejecución

Cada agente tiene una lista documentada de acciones permitidas. La aplicación en tiempo de ejecución, y no solo la documentación de políticas, evita comportamientos fuera de alcance. Si un agente está diseñado para resumir documentos, no debería poder enviar correos electrónicos, acceder a bases de datos o llamar a API que estén fuera de su cometido.

3. Validación de entradas contra la inyección de instrucciones

Todas las entradas externas, incluidos los mensajes de usuario, los documentos recuperados y las respuestas de API, se validan antes de que el agente las procese. Este es el control que habría evitado el ataque sin clics a Microsoft Copilot. La inyección de instrucciones sigue siendo el riesgo número uno de LLM para OWASP por una buena razón.

4. Controles de salida y filtros de datos

Los resultados del agente se verifican frente a la política de seguridad antes de llegar a los usuarios o a los sistemas externos. Los filtros de datos confidenciales e información de identificación personal (PII) están activos. La validación de salida detecta tanto fugas de datos como contenido alucinado que podría desencadenar acciones no deseadas en flujos de trabajo multiagente.

5. Registro de auditoría inmutable

Cada acción del agente, llamada a herramienta y decisión se registra con marcas de tiempo inmutables. Los registros incluyen la cadena de razonamiento, no solo el resultado final. Cuando un auditor de SOC 2 pregunte "qué hizo este agente y por qué", necesitará una respuesta completa. Los registros tradicionales de llamadas a API no son suficientes para sistemas que razonan.

6. Activadores de supervisión humana

Las acciones de alto riesgo requieren la aprobación de una persona. Las rutas de escalado están definidas y probadas. Los umbrales de lo que se considera "alto riesgo" están documentados y son configurables, no están preestablecidos de forma fija en una instrucción del sistema que nadie revisa tras el despliegue.

7. Gobernanza de herramientas

Cada herramienta tiene permisos, esquemas de entrada y esquemas de salida documentados. No se permite el acceso generalizado (wildcard) a las herramientas. El 90 % de los agentes tienen demasiados permisos, con privilegios 10 veces superiores a los que requiere su tarea. La auditoría debe identificar cada herramienta que un agente puede llamar y verificar que cada una esté justificada.

8. Límites de confianza multiagente

La comunicación entre agentes valida la identidad del origen. Verificación de salidas en cada punto de delegación. No se permiten cadenas de confianza implícitas. Si el Agente A delega en el Agente B, el Agente A verifica la salida de B antes de actuar en consecuencia. La brecha de Drift/Salesforce demostró lo que ocurre cuando la confianza se propaga de forma descontrolada.

El cronograma de cumplimiento normativo se está acelerando

Las obligaciones de alto riesgo de la Ley de IA de la UE entrarán en vigor el 2 de agosto de 2026. La Ley de IA de Colorado será de obligado cumplimiento en junio de 2026. Los auditores de SOC 2 ya están incorporando controles de agentes de IA en sus revisiones. El cumplimiento de SOC 2 para la infraestructura de agentes de IA cuesta de 35 000 a más de 250 000 dólares en el primer año y requiere entre 6 y 18 meses para la certificación de Tipo II. Ese calendario implica que las organizaciones que despliegan agentes hoy deben empezar a trabajar en el cumplimiento normativo ahora, no después de recibir la primera solicitud de auditoría.

Gartner proyecta que el gasto en gobernanza de IA alcanzará los 492 millones de dólares en 2026 y superará los 1000 millones de dólares para 2030. Sin embargo, en la actualidad, las empresas gastan 17 veces más en herramientas de seguridad impulsadas por IA que en proteger la propia IA. En ese desequilibrio es donde se producen las brechas de seguridad.

La plataforma de Beam incluye control de acceso basado en roles (RBAC) nativo, acceso a herramientas con alcance OAuth y registros de auditoría inmutables para cada acción del agente. Estos controles se incluyen en cada despliegue, no como un añadido de cumplimiento posterior una vez que el equipo de seguridad da la voz de alarma.

La auditoría se acerca. Prepárese para ella hoy mismo.

OWASP, NIST, CSA, Forrester y Microsoft publicaron marcos de seguridad para agentes de IA con solo seis meses de diferencia. Esa convergencia significa que las expectativas de referencia para las revisiones de seguridad corporativa están cambiando rápidamente. Los ocho controles anteriores son el mínimo, no el límite máximo, pero cubren los vectores de ataque que produjeron vulnerabilidades CVSS 9.3 y 9.6 en los propios productos de Microsoft y GitHub.

Las organizaciones que integran hoy la preparación para auditorías en sus despliegues de agentes evitan las prisas de última hora que afectaron a la adopción de la nube hace una década. Quienes decidan esperar tendrán que adaptar controles a posteriori bajo la presión de los plazos, a un coste mayor y con menor cobertura. Los marcos de trabajo existen. Los incidentes están documentados. La lista de verificación está lista. La única variable es cuándo decide empezar.