La base de seguridad de agentes: 35 controles, pero ¿por dónde empezar?

Hace dos semanas, publicamos la Agent Baseline junto con Docker y Keycard. En ella describimos seis resultados de seguridad, 35 controles y una arquitectura de referencia abierta para ejecutar agentes de IA a escala empresarial. La semana pasada la pusimos a prueba: la llevamos a un panel en Black Hat y pasamos cerca de una hora respondiendo preguntas difíciles al respecto.

Play Video: Snyk x Docker x Keycard | Agent Baseline Panel @ Black Hat 2026

La pregunta más útil vino de alguien que ya la había leído. Dijo, más o menos: Esto está bien, pero todavía no sé qué hacer el lunes.

Y es una pregunta válida; además, merece una respuesta adecuada, porque apunta a algo que decidimos no incluir en el documento. También es el tipo de brecha que esperamos que los lectores encuentren mientras la Baseline siga abierta a comentarios.

La incertidumbre es real, y estamos en medio de ella

Si buscas ayuda para proteger agentes de IA, muy pronto te encontrarás con un muro de afirmaciones, porque todos los proveedores del mercado (incluido Snyk) te dirán que resuelven la seguridad de los agentes. Todos describen algo real, pero casi nunca queda claro qué parte del problema están abordando ni cómo se conecta con las otras partes que aún necesitas.

Pero no se trata de deshonestidad. Es un síntoma de un mercado que se formó más rápido que su vocabulario. Hoy, "gobernanza de agentes" puede significar al menos cinco cosas distintas, según quién la ofrezca. Y quienes compran no tienen una forma confiable de saber si dos productos se superponen, se complementan o dejan una brecha que nadie ha mencionado (o siquiera identificado, lo cual es aún más preocupante).

Esto funciona en ambos sentidos. Los proveedores quieren explicar con claridad dónde aportan valor y cómo encaja su solución en el resto de la arquitectura de un cliente, pero, sin un vocabulario común, terminan haciendo la misma afirmación genérica que todos los demás.

Y los profesionales necesitan más que una guía para descifrar a los proveedores: comparar sus capacidades con los seis resultados permite ver dónde deben buscar soluciones externas y dónde ya tienen fortalezas internas. Esa es la conversación sobre comprar o desarrollar internamente, y es mucho más fácil cuando las brechas tienen nombre.

Tomemos dos productos que se venden como soluciones de gobernanza de agentes y cuyas descripciones son correctas.

El primero se ubica en el perímetro de la red. Observa todas las llamadas que un agente hace al exterior, puede inspeccionar su contenido y bloquearlas según las políticas. Te dirá si una solicitud con registros de clientes llegó a un destino indebido. Pero no puede decirte qué archivo de habilidades puso esa instrucción en la cabeza proverbial del agente, porque nada de eso pasa por su perímetro.

El segundo es una capa de identidad. Gestiona credenciales de corta duración y con alcance limitado en el momento de uso, para que cada acción permita verificar quién la inició y con qué autoridad. Te dirá con precisión que el agente tenía permiso para hacer lo que hizo. Pero no puede decirte si hacerlo fue una buena idea.

Ahora comparemos ambos con los seis resultados: el primero cubre partes de Constrain y Observe; el segundo cubre Authorize. Ninguno exagera ni se superpone con el otro, y entre los dos dejan sin cubrir Validate. Nadie ha probado si el agente se comporta de forma segura bajo ataque ni ha revisado lo que produjo. Quien compra ambos, creyendo razonablemente que ya resolvió la gobernanza de agentes, nunca ha tenido esa conversación, porque no surgió en ninguno de los ciclos de venta.

La Baseline se escribió precisamente para hacer posible esa comparación, ya que define el problema según los resultados de seguridad que una organización debe alcanzar, no según las categorías de productos: Discover, Constrain, Authorize, Observe, Validate y Respond. Compara cualquier plataforma, producto o desarrollo interno con esos seis resultados y entenderás rápidamente dónde destaca, pero también dónde podría necesitar soluciones complementarias.

No dimos suficiente importancia a la secuencia, porque seis resultados y 35 controles sirven para evaluar la cobertura, pero evaluar la cobertura no equivale a tener un plan. (Perdón por sonar un poco como Yoda, pero este juego de palabras también muestra lo importante que es la secuencia: cubrimos el significado y se entiende, pero el orden equivocado hace que tardes un segundo más en comprenderlo.)

Si ahora lees el documento como una lista de tareas, no empezarás, porque parecerá un programa de dos años. Así que esto es lo que te debíamos: el orden.

La mayoría de las organizaciones aún no opera una fábrica de software

Algo que considerábamos cierto y que el panel de Black Hat confirmó: hoy muy pocas empresas operan fábricas de software, y muchas ni siquiera están avanzando hacia una a escala significativa. Vale la pena decirlo claramente, porque una arquitectura de referencia puede parecer una crítica si aún no llegaste a ese punto. No lo es. Si estás a las puertas (y la mayoría lo está), esta es la estructura sobre la que debes construir; además, le da a seguridad un papel en la preparación para esa automatización y productividad, en lugar de limitarse a reaccionar después.

El eje que falta es el caso de uso

El documento recorre la curva de autonomía: desde un agente de programación en una laptop hasta un servicio desatendido que actualiza dependencias a las 3 a. m. Aunque ese es el enfoque adecuado para explicar por qué existen los controles, no es el indicado para decidir cuáles necesitas primero, porque la mayoría de las organizaciones no avanza por una sola curva: ejecuta varias cosas distintas al mismo tiempo y las llama a todas "agentes".

Hay tres patrones que cubren la mayoría de lo que vemos:

1. Agentes de programación para desarrolladores. Alguien de la organización descarga un agente de programación y lo ejecuta en un repositorio real.
2. Agentes internos compartidos. Hay un solo agente que usan muchos empleados, como un asistente de RR. HH., un aprobador de finanzas o un copiloto de operaciones.
3. Agentes de producción. Estos agentes actúan sobre clientes, transacciones y sistemas de registro, a menudo con muy poca "intervención humana".

Así que tienes 35 controles, pero el orden en que se "activan" cambia radicalmente. El problema empieza cuando los tratas como un solo programa, porque el control más importante para el primer caso es casi irrelevante para el tercero, y viceversa. Si te equivocas de secuencia, pasarás meses creando un registro de agentes mientras tu verdadera exposición está en otra parte.

Agentes de programación para desarrolladores: empieza con Constrain y calibra con Discover

En este caso, el instinto sería empezar con el descubrimiento: crees que debes encontrar todos los agentes y luego decidir qué hacer. Pero para este caso de uso, ese es el primer paso equivocado. El documento explica por qué en una sola frase: un registro y un flujo de aprobación no sirven de nada si el agente se ejecuta en un host que no aplica ninguna de las dos cosas.

Esto es lo que realmente pasa: un desarrollador instala un agente de programación y este empieza a pedir permiso cada vez que necesita leer una carpeta o ejecutar un comando. Las solicitudes constantes se vuelven molestas, así que el desarrollador permite los comandos habituales, amplía el acceso al sistema de archivos o incluso desactiva el sandbox. En ese momento, el agente se convierte en un proceso común que se ejecuta como ese desarrollador y puede acceder a todo lo que esté al alcance de su shell.

El acceso se amplía conexión por conexión: GitHub abre un flujo de OAuth, una herramienta en la nube encuentra una sesión iniciada, un servidor MCP solicita un token, SSH usa la clave que ya está cargada en la máquina, y así sucesivamente. Ya te haces una idea.

Cada paso parece razonable por sí solo, pero el resultado es un agente con amplias facultades distribuidas entre sistemas que no comparten una visión de los demás, y registros que dicen que fue el desarrollador quien hizo todo.

Empieza por el perímetro. La ejecución aislada y los perfiles de capacidades definidos según el caso de uso (CON-03, CON-04) le dan al agente solo lo que necesita para su tipo de trabajo. Se definen de forma centralizada, tienen control de versiones y el agente no puede modificarlos. Luego viene el registro de componentes (DIS-04): servidores MCP, habilidades, complementos, modelos y herramientas, junto con su origen y versión. Después, las pruebas antes de la publicación (VAL-03), porque el código generado por agentes debe pasar por las mismas puertas de lanzamiento que todo lo demás.

Lo que más sorprende a la gente es que esto mejora el día del desarrollador, en lugar de empeorarlo. Cuando las credenciales llegan mediante un intermediario justo en el momento de uso y con el alcance limitado a la tarea, el agente deja de pedir aprobación para cada comando "inofensivo", porque esos comandos ya no pueden causar daño. El mismo control reduce las solicitudes y refuerza el perímetro, una combinación poco común que vale la pena destacar.

Así es como el descubrimiento vuelve a entrar en juego: no como primer paso, sino como lo que permite que ese primer paso sea lo mejor posible.

Un perfil de capacidades solo es tan bueno como la información en la que se basa. Si lo escribes haciendo suposiciones, obtendrás uno de dos resultados: si es demasiado amplio, el agente empezará a planificar contando con accesos que nunca necesitó para la tarea; si es demasiado limitado, alguien irá quitando el perímetro con un "Permitir siempre" tras otro. En ambos casos, la causa es la misma: se creó un perfil sin investigar.

Así que más vale investigar. El mapeo de accesos efectivos (DIS-06) te indica a qué identidades y credenciales puede acceder realmente un agente, y qué permiten. El registro de componentes muestra qué servidores MCP, habilidades y modelos están realmente en uso, en lugar de los que supones que lo están.

Y no termina el primer día: la conciliación (DIS-07) te indica si el perfil se ha desviado, por ejemplo, porque se agregó un servidor MCP o cambió un trabajo. El documento lo deja claro: el descubrimiento no es un registro estático, sino una vista operativa que se concilia continuamente.

Constrain es donde empiezas a aplicar controles, y Discover es donde averiguas qué debes controlar. Aplica ambos en esa secuencia, pero no los separes, porque Discover es un insumo fundamental para determinar cómo definir las restricciones y debe abordarse desde el inicio.

Agentes internos compartidos: empieza con Authorize

El aislamiento casi no sirve aquí, porque el riesgo no es el radio de impacto en un host, sino el "delegado confundido". (Es un problema de autoridad. El concepto viene de Norm Hardy, en 1988: un programa con autoridad legítima es engañado para ejercerla en nombre de quien no corresponde. No hay nada comprometido, nada escapa del aislamiento ni se explota ninguna vulnerabilidad, pero el delegado simplemente no puede saber en nombre de quién está actuando.)

La integración más rápida le da al agente una cuenta de servicio y hace que todas las solicitudes de los usuarios pasen por ella. Funciona de inmediato... y ese es el problema. Todas las solicitudes terminan en el mismo conjunto de accesos. Cuando una solicitud llega a la API interna, ya no se ve quién la hizo, y una instrucción basada en los datos de Alice puede terminar ejerciendo una autoridad pensada para Bob. Pedirle al modelo que mantenga el trabajo de cada persona por separado es una solicitud, no un límite de seguridad.

En este caso de uso, la autoridad debe estar integrada en la estructura: cada parte de una acción necesita una identidad distinta y verificable, atribuible a la persona que la inició o a un propósito autónomo aprobado (AUT-01). La autoridad debe limitarse según la tarea, en lugar de heredarse de la cuenta (AUT-02): el mínimo privilegio limita cuánto acceso existe; la delegación limita por qué, para qué y durante cuánto tiempo. Y debe reducirse a lo largo de la cadena (AUT-03), para que un agente posterior nunca reciba más autoridad que quien lo invocó.

Luego viene la correlación (OBS-02), porque con un agente multiusuario, la pregunta de auditoría no es "¿Ocurrió algo?", sino "¿En nombre de quién ocurrió?". Sin un identificador de ejecución que vincule la solicitud con la acción, no podrás responder después; y será después cuando te lo pregunten.

Agentes de producción: empieza con Respond y Validate

En el caso de los agentes que interactúan con clientes y realizan transacciones, los controles que importan son los que nadie implementa hasta que los necesita. Así que empieza con esta pregunta: si tuvieras que detener este agente ahora mismo, ¿qué pasaría con el trabajo?

El problema es que la mayoría de los equipos no pueden responder esa pregunta, y ahí es donde detectamos la brecha. RES-01 establece que detener un agente significa bloquear el trabajo nuevo, detener las ejecuciones en curso y revocar las credenciales, los permisos, las autorizaciones delegadas y las sesiones que esas ejecuciones crearon, siguiendo la cadena de delegación, no el proceso visible. Elimina el contenedor, pero deja activo el token, y no habrás detenido nada. RES-02 agrega algo verdaderamente nuevo: la unidad de aislamiento suele ser un componente, no un host. Un archivo de habilidades contaminado o un servidor MCP comprometido se pueden compartir entre decenas de agentes y, como poner un archivo en un directorio puede bastar para que esté disponible, eliminar una copia no elimina el problema.

Luego está RES-04, el control que creemos que falta en casi todas partes: una alternativa que no dependa de un agente para el trabajo que no puede esperar. Una vez que un flujo de trabajo depende de un agente, el agente, y no la plataforma, es quien puede realizar el trabajo. Si lo detienes, el trabajo queda varado. Qué flujos de trabajo necesitan una ruta manual documentada y en qué consiste esa ruta son decisiones que debes tomar antes del incidente.

Y, en la parte de Validación, está VAL04: un agente puede completar una acción correctamente y aun así obtener un resultado equivocado, porque tener permiso no significa actuar correctamente. Sobre todo en el caso de las acciones irreversibles, valida el resultado propuesto antes de confirmarlo, no después.

Esta es la parte de la arquitectura en la que nos enfocamos en Snyk. No solo nos importa que el código y las dependencias de un agente sean seguros, sino también que su comportamiento se mantenga dentro de los límites de su autoridad durante la ejecución: qué puede hacer, en nombre de quién y qué sucede cuando se excede. Gran parte del Baseline queda fuera de nuestro ámbito, y ese es precisamente el objetivo de un modelo independiente de los proveedores.

El equilibrio es una decisión de diseño, no necesariamente una concesión

Cuando la situación empieza a dar miedo, la reacción instintiva es bloquearlo todo: prohibir las herramientas, esperar a que se calme el mercado y decir «volvamos a hablar el próximo año».

Pero eso no funciona, y no por la razón que suele darse. No se trata solo de que la adopción en la sombra continúe (porque continúa), sino de que bloquearla te quita visibilidad sobre aquello que te preocupa, mientras la empresa lo adopta de todos modos. Así, terminas asumiendo el mismo riesgo, pero con menos información.

Pero la reacción opuesta es aún peor: aprobarlo todo, agregar un poco de monitoreo y llamarlo «gobernanza». Vigilar a un agente no es lo mismo que ponerle límites.

Lo que realmente funciona se parece menos a una decisión y más a una arquitectura. Los controles del Baseline están diseñados para ubicarse fuera del modelo, porque no pueden depender de que el agente siga instrucciones. Así, la conversación sobre productividad se vuelve manejable: no se trata de decidir cuánta confianza depositar en el agente, sino cuánta autoridad requiere el trabajo, y luego establecer ese límite en un lugar que el agente no pueda cuestionar. Mientras se mantenga por debajo de ese límite, déjalo funcionar.

Los niveles también importan. Una denegación que solo dice «No» invita a reintentar y buscar atajos. En cambio, una denegación que explica el motivo y ofrece una vía gobernada para avanzar —registrar el componente, solicitar una elevación de permisos limitada con una justificación, obtener aprobación independiente y volver a encaminar la ejecución dentro de sus límites sin terminarla— permite reducir la autoridad de la ejecución mientras una persona decide. Si recurres primero a detenerlo por completo, cualquier anomalía se convierte en una interrupción del servicio.

Lo que el documento aún no incluye

Hay dos cosas que faltan en el Agent Baseline, y preferimos decirlo claramente en lugar de dejar que las descubras por tu cuenta.

Primero, no hay un modelo de madurez. Los controles te indican cómo se ve una buena práctica, pero no distinguen entre una «buena práctica de nivel uno» y una «buena práctica de nivel tres». Cada organización que lee esto está en una etapa distinta, y una evaluación de cobertura que trate igual a una empresa Serie B y a un banco global no les sirve demasiado a ninguna de las dos. Definir la secuencia por caso de uso, como se describe arriba, es apenas el comienzo de ese trabajo, no el final.

Además, la perspectiva de los casos de uso no está incluida en la versión 1.0. La encontraste aquí porque surgió de conversaciones como la que tuvimos en Black Hat. Eso es un buen indicio de que el proceso de revisión está funcionando, y un indicio aún mejor de que probablemente deberíamos haberlo detectado antes.

Léelo y luego contribuye

Estamos muy conformes con este punto de partida. También sabemos que hay personas que llevan más tiempo gestionando y midiendo este trabajo que el propio Baseline, y que tienen opiniones firmes y pruebas que las respaldan. Precisamente a esas personas queremos escuchar, y el momento es ahora: el Baseline está abierto a comentarios hasta el 30 de septiembre y, de cualquier manera, seguirá siendo de código abierto.

El Baseline es un borrador abierto a comentarios hasta el 30 de septiembre. Los controles tienen identificadores permanentes, así que puedes citarlos en un hallazgo de auditoría, un documento de políticas o una respuesta a una solicitud de propuestas (RFP), y la referencia seguirá funcionando en el futuro.

Crear un issue es una forma duradera de expresar tu desacuerdo. Si un control no es eficaz en la práctica, si omitimos alguno o si implementarlo cuesta más que el riesgo que elimina, ese es exactamente el tipo de comentarios que buscamos durante el período de revisión. El objetivo es contar con un único modelo independiente de los proveedores que todos podamos empezar a implementar y usar para medir nuestro progreso.

Explora el Agent Baseline, lee el whitepaper y comenta en GitHub para contribuir.