← Todos los articulos

Lo que le dije a NIST sobre la seguridad de agentes de IA

11 min de lectura

Doce veces en 60 días, mi agente de IA dejó de trabajar en la tarea asignada y comenzó a hacer otra cosa. Cada vez, el agente continuó produciendo resultados verosímiles. Ninguna vulnerabilidad de seguridad jugó un papel. El agente decidió en tiempo de ejecución trabajar en un problema diferente.1

El 24 de febrero de 2026, esos 12 incidentes y docenas de fallos relacionados se convirtieron en un comentario público de 2.500 palabras dirigido al National Institute of Standards and Technology. El expediente NIST NIST-2025-0035 solicita aportes públicos sobre consideraciones de seguridad para agentes de IA.2 El período de comentarios cierra alrededor del 9 de marzo de 2026. Mi comentario argumenta una tesis central: las amenazas de los agentes son conductuales, y ningún marco existente de NIST aborda los modos de fallo conductuales.

Resumen

Opero un sistema de orquestación de agentes de IA en producción diaria: 15.000 líneas de código que interceptan 15 tipos de eventos de hooks en cada acción del agente. A lo largo de 60 sesiones, identifiqué siete modos de fallo conductuales recurrentes sin análogo en el software tradicional. El agente se desvió de la tarea, afirmó que las pruebas pasaron sin ejecutarlas y generó sub-agentes recursivos que perdían contexto en cada salto. Construí una defensa en tres capas (pipeline de hooks, sandbox del sistema operativo, puerta de evidencia) y mapeé el sistema contra CSF 2.0, SP 800-53 y el AI Risk Management Framework. Existen brechas significativas en los tres. El comentario incluye seis recomendaciones priorizadas, comenzando con un propuesto NIST Internal Report sobre taxonomía de amenazas conductuales de agentes. El período de comentarios permanece abierto.

Por qué un profesional presentó un comentario público federal

NIST rara vez solicita aportes públicos sobre seguridad de IA. Cuando la agencia publicó su solicitud de información sobre seguridad de agentes de IA, las cinco áreas temáticas se correspondían directamente con problemas para los que ya había construido soluciones en producción:2

  1. Amenazas de seguridad únicas que afectan a los sistemas de agentes de IA
  2. Métodos para mejorar la seguridad durante el desarrollo y la implementación
  3. Cómo se desempeñan los marcos establecidos cuando se aplican a agentes
  4. Métodos para medir la seguridad y anticipar riesgos
  5. Salvaguardas de implementación para restringir y monitorear el acceso de los agentes

La mayoría de los comentarios públicos sobre RFI federales provienen de corporaciones, grupos comerciales y laboratorios de investigación. Los profesionales individuales rara vez los presentan. Pero los profesionales operan estos sistemas a diario. Un desarrollador que ejecuta un agente de IA a través de más de 60 sesiones acumula evidencia que los experimentos controlados no producen. Presenté mi comentario porque la evidencia existía y nadie más iba a presentarla.

El comentario pasó por tres rondas de revisión, un proceso de deliberación con 10 agentes y dos rondas de evaluación competitiva (Claude Code vs. Codex CLI) antes de la presentación final.1

Lo que construí

El sistema de orquestación envuelve el Claude Code CLI de Anthropic en aproximadamente 15.000 líneas de código shell y Python. Cada acción que realiza el agente (lecturas de archivos, escrituras de archivos, comandos bash, solicitudes web, generación de sub-agentes) pasa por un pipeline de hooks antes de su ejecución. Ocho hooks despachadores enrutan las llamadas a hooks manejadores según el tipo de herramienta. El sistema registra cada decisión, rastrea costos, monitorea desviaciones e impone límites estrictos que el agente no puede anular.1

No me propuse construir el sistema. El sistema creció a partir de fallos. El detector de desviaciones existe porque un agente pasó 45 minutos reorganizando el directorio de mi proyecto cuando la tarea era “arreglar el endpoint de inicio de sesión”. El sandbox existe porque detecté a un agente intentando escribir en ~/.ssh/. La puerta de evidencia existe porque un agente reportó “todas las pruebas pasan” sin ejecutar pytest. Cada componente se remonta a un incidente específico en producción.

Amenazas conductuales: el argumento central

La seguridad tradicional defiende contra la explotación: SQL injection, desbordamientos de búfer, robo de credenciales. La seguridad de agentes agrega una categoría sin precedentes en el software: el agente decide en tiempo de ejecución en qué trabajar, y puede decidir mal.

Desviación de sesión

Un agente se aleja gradualmente de la tarea asignada mientras produce resultados de apariencia verosímil. Mi motor de detección de desviaciones calcula la similitud coseno entre el embedding del prompt original del usuario y una ventana deslizante de las 25 llamadas de herramientas más recientes del agente.1 Cuando la puntuación cae por debajo de 0,30, el sistema inyecta una advertencia que contiene el prompt original.

Establecí el umbral de 0,30 basándome en una revisión manual de 60 sesiones. El sistema disparó 12 advertencias por debajo del umbral. En los 12 casos, el agente había perdido verificablemente el seguimiento de la tarea original. Por encima del umbral, ninguna sesión requirió intervención manual por desviación. Optimicé el umbral para precisión; no he medido formalmente la tasa de falsos negativos.1

Verificación fantasma

Un agente afirma que el trabajo está completo y las pruebas pasan sin haber ejecutado las pruebas. La señal de detección es específica: el informe de finalización carece de salida de pruebas pegada. “Las pruebas deberían pasar según la estructura del código” sustituye creencia por evidencia. Describí la variante de fabricación del mismo patrón de fallo: un agente que publica afirmaciones seguras pero incorrectas porque nada valida los autorreportes contra la realidad externa.1

Generación recursiva

Los agentes que generan sub-agentes pueden entrar en recursión descontrolada, consumiendo presupuesto de cómputo y perdiendo coherencia. Mi protección contra recursión impone una profundidad máxima de dos y un máximo de cinco hijos por agente padre, rastreando el árbol completo de linaje mediante un archivo JSON protegido por bloqueo.1

Los siete modos de fallo

Catalogué siete patrones conductuales recurrentes a lo largo de 60 sesiones. Cada modo tiene una señal de detección específica que los hooks o la revisión humana pueden verificar:

Modo de fallo Definición Señal de detección
Espiral de atajos Omitir pasos de revisión para reportar finalización más rápido Informe de finalización sin evidencia de pasos
Espejismo de confianza Sustituir “estoy seguro” por verificación real Lenguaje evasivo sin salida de pruebas
Meseta de lo suficientemente bueno Aceptar trabajo funcional pero no probado Sin cobertura de pruebas ni documentación citada
Visión de túnel Pulir un componente mientras se ignoran fallos de integración Pruebas de integración no ejecutadas
Verificación fantasma Afirmar que las pruebas pasan sin ejecutarlas Informe sin salida de pruebas pegada
Deuda diferida Dejar marcadores TODO/FIXME en código confirmado TODO/FIXME en el diff confirmado
Informe vacío Reportar “listo” sin evidencia para cada criterio Criterios no abordados individualmente

Ninguno de estos modos requiere una vulnerabilidad. El agente no necesita explotar un CVE. El agente falla al hacer mal su trabajo y reportar que lo hizo bien.

Defensa en profundidad

El sistema de orquestación utiliza tres capas independientes. Un fallo en una capa no compromete las demás.

Capa 1: Pipeline de hooks. Cada llamada de herramienta pasa por un hook PreToolUse antes de su ejecución. Los manejadores pueden bloquear la ejecución, modificar el comando o inyectar contexto informativo. La arquitectura despachador-manejador significa que agregar una nueva verificación de seguridad requiere escribir un archivo manejador, no modificar el pipeline de enrutamiento. Ocho despachadores enrutan a 99 hooks manejadores.1

Capa 2: Sandbox del sistema operativo. Un perfil Seatbelt de macOS define ocho reglas explícitas de denegación que bloquean escrituras a .ssh, .gnupg, .aws, archivos de entorno, autenticación de GitHub CLI y el Keychain de macOS. El kernel aplica estas reglas independientemente del comando que el agente construya. Intentar touch ~/.ssh/test bajo el perfil devuelve “Operation not permitted”.1

Capa 3: Puerta de evidencia. Antes de marcar como completa cualquier tarea no trivial, el agente debe satisfacer seis criterios de evidencia con pruebas citadas: sigue los patrones del código base (nombrar el patrón), solución funcional más simple (explicar alternativas descartadas), casos límite manejados (listar cada uno), pruebas aprobadas (pegar salida), sin regresiones (nombrar archivos verificados) y resuelve el problema real (indicar la necesidad del usuario). La puerta señala el lenguaje evasivo (“debería funcionar”, “probablemente correcto”) como evidencia insuficiente, activando una reverificación obligatoria.1

La independencia de capas es la propiedad de diseño crítica. Un agente que elude el pipeline de hooks aún se enfrenta al sandbox del sistema operativo. Un agente que encuentra una brecha en el sandbox aún enfrenta la puerta de evidencia. Ningún fallo individual compromete el sistema.

Análisis de brechas en los marcos regulatorios

El comentario mapea los controles de producción contra tres marcos de NIST. Algunos mapeos funcionan bien. Otros revelan brechas que ningún marco existente cubre.

Lo que se mapea correctamente

Los hooks PreToolUse abarcan dos funciones de CSF 2.0: Proteger (PR.PS-05, prevención de acciones no autorizadas) y Detectar (DE.CM, monitoreo continuo de llamadas de herramientas).3 El sandbox del sistema operativo implementa los controles SP 800-53 AC-3 (Aplicación de acceso) y AC-6 (Privilegio mínimo).4 El pipeline de hooks se mapea a AC-25 (Monitor de referencia): siempre invocado, no se puede eludir y lo suficientemente pequeño para verificar. La función Map del AI RMF (MAP 3) se alinea con la detección de desviaciones: comprender qué hace el agente frente a lo que el operador le pidió que hiciera.5

Lo que falta

Marco Controles aplicables Brecha específica de agentes Extensión sugerida
CSF 2.0 DE.CM, DE.AE Sin categoría de detección de desviación conductual Extender los ejemplos de DE.AE para incluir anomalías conductuales de agentes
SP 800-53 Rev. 5 AC-3, AC-6, AC-25 Sin controles de profundidad de delegación de agentes Nuevo mejoramiento de control para gobernanza de delegación de agentes
AI RMF 1.0 MAP 3 Sin métrica de fidelidad de tarea en tiempo de ejecución Agregar similitud de desviación de agente a la función MEASURE

El OWASP Top 10 for Agentic Applications (2026) aborda Agent Goal Hijacking (ASI01) y Human-Agent Trust Exploitation (ASI09), pero no cubre fallos de autogobernanza como la verificación fantasma ni el informe vacío.6 NIST AI 600-1 (Generative AI Profile) aborda los riesgos de IA generativa de forma amplia, pero es anterior a los patrones de implementación de agentes.7

Riesgos de la cadena de delegación

Cuando un agente genera un sub-agente, que a su vez genera otro sub-agente, las propiedades de seguridad no se suman. Cada salto introduce tres riesgos acumulativos:

  • Compresión semántica. El contexto completo de razonamiento del padre se comprime en una cadena de prompt, perdiendo matices sobre qué archivos son sensibles o qué enfoques el padre ya descartó.
  • Amplificación de autoridad. El hijo hereda permisos de lectura/escritura de archivos, pero no la comprensión del padre sobre qué archivos tienen sensibilidad de seguridad.
  • Difusión de responsabilidad. Cuando un sub-agente produce resultados incorrectos, la pista de auditoría muestra qué agente tomó cada decisión, pero el agente raíz tiene la responsabilidad operativa del resultado final.

Mi protección contra recursión aborda las cadenas de delegación rastreando el linaje de agentes e imponiendo límites estrictos de profundidad. Ningún marco publicado aborda los riesgos acumulativos de la delegación multinivel de agentes.

Seis recomendaciones

El comentario cierra con seis recomendaciones, listadas de lo fundacional a lo operativo:

  1. Publicar un NIST Internal Report que establezca una taxonomía de amenazas conductuales de agentes. Los modelos de amenazas tradicionales (STRIDE, OWASP Top 10) no capturan los modos de fallo específicos de agentes. Una taxonomía compartida es el prerrequisito para todas las demás recomendaciones. NIST también podría extender CSF 2.0 con subcategorías específicas para agentes y publicar un perfil del AI RMF para sistemas de agentes.

  2. Establecer requisitos de contención a nivel del sistema operativo. Los agentes que improvisan patrones de comandos novedosos pueden eludir el sandboxing a nivel de aplicación. La aplicación a nivel del sistema operativo (Linux seccomp-bpf, macOS Seatbelt, aislamiento por contenedores) proporciona un límite que el agente no puede razonar para evadir.

  3. Requerir verificación independiente de los autorreportes del agente. Los agentes no pueden ser la única autoridad sobre si su propio trabajo es correcto. Un proceso separado debería verificar evidencia externa (salida de pruebas, respuestas de API, sumas de verificación) antes de aprobar la finalización de la tarea.

  4. Establecer una clasificación del radio de impacto para las llamadas de herramientas del agente. Etiquetar cada acción del agente como local, compartida o externa, con requisitos de autorización escalados para cada nivel. Describí el sistema de clasificación en detalle anteriormente.

  5. Definir métricas cuantitativas de desviación. La postura de seguridad del agente necesita una “puntuación de alineación con la tarea” medible que refleje qué tan estrechamente la actividad actual del agente se alinea con la tarea asignada, calculada a intervalos regulares.

  6. Estandarizar el registro de auditoría para acciones de agentes. Registrar cada llamada de herramienta, cada decisión de hook y cada acción bloqueada en un formato que permita la reconstrucción posterior al incidente.

Presente su propio comentario

El período de comentarios para NIST-2025-0035 cierra alrededor del 9 de marzo de 2026. Los RFI de NIST tienen peso real: los comentarios informan directamente los marcos publicados, estándares y guías. Si opera agentes de IA en producción, su evidencia importa.

Cómo presentar un comentario:

  1. Visite la página del expediente NIST-2025-0035
  2. Haga clic en “Comment” en el documento del RFI
  3. Escriba su comentario abordando cualquiera de las cinco áreas temáticas
  4. Incluya evidencia específica: código, métricas, informes de incidentes
  5. Presente con su información de contacto

No necesita abordar los cinco temas. Un comentario enfocado y respaldado por evidencia sobre un solo tema tiene más valor que un comentario amplio sin especificaciones. El personal de NIST lee cada presentación.

Conclusiones clave

Para profesionales de seguridad: Mapee sus controles de agentes existentes contra CSF 2.0 y SP 800-53. El mapeo del pipeline de hooks a AC-25 Reference Monitor proporciona un marco concreto para describir el control de acceso a nivel de agente a los equipos de cumplimiento.

Para desarrolladores de IA: Construya detección conductual junto con la seguridad tradicional. La desviación de sesión, la verificación fantasma y la generación recursiva son realidades de producción, no riesgos teóricos. Comience con la puerta de evidencia: requiera pruebas citadas antes de marcar tareas como completadas.

Para legisladores: La brecha entre los marcos de seguridad tradicionales y las amenazas específicas de agentes es estructural, no incremental. Los agentes fallan de maneras que STRIDE, OWASP y los catálogos existentes de NIST no clasifican. Una taxonomía de amenazas conductuales es el prerrequisito para todo lo demás.

Para autores de marcos regulatorios: Agreguen gobernanza de cadenas de delegación. Cuando los agentes generan agentes, el contexto se degrada, la autoridad se amplifica y la responsabilidad se difumina en cada salto. Los riesgos acumulativos a profundidad tres y más allá no tienen precedente en ningún marco.

Fuentes

  1. Telemetría de producción del autor y comentario público presentado sobre NIST-2025-0035. Número de seguimiento mm1-hgn6-spl7. Motor de similitud de desviación a lo largo de 60 sesiones diarias de Claude Code, febrero de 2026. Texto completo del comentario disponible bajo solicitud. ↩↩↩↩↩↩↩↩↩↩

  2. NIST-2025-0035: Request for Information Regarding Security Considerations for Artificial Intelligence Agents. National Institute of Standards and Technology. ↩↩

  3. NIST Cybersecurity Framework 2.0. National Institute of Standards and Technology, 2024. ↩

  4. NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations. National Institute of Standards and Technology, 2020. ↩

  5. NIST AI Risk Management Framework 1.0. National Institute of Standards and Technology, 2023. ↩

  6. OWASP Top 10 for Agentic Applications. OWASP Foundation, 2026. ↩

  7. NIST AI 600-1: Artificial Intelligence Risk Management Framework: Generative AI Profile. National Institute of Standards and Technology, 2024. ↩