Los agentes de IA están pasando de las demos a producción. Llaman APIs, acceden a bases de datos, ejecutan código y toman decisiones sobre flujos operativos. Muchos todavía funcionan sin controles específicos para esa forma de ejecución.
Estoy construyendo Oktsec porque el mismo patrón aparece una y otra vez: la superficie de ataque de los agentes crece más rápido que la infraestructura disponible para gobernarla.
¿Qué aparece al revisar MCP servers y configuraciones de agentes?
Las descripciones de herramientas pueden incluir instrucciones que alteran el comportamiento del agente. Muchos servers no autentican al caller. Los agentes conectados a múltiples herramientas forman cadenas implícitas de confianza, y una dependencia comprometida puede aprovechar las capacidades que el agente tiene sobre las demás.
También es frecuente que información sensible pase de una herramienta a otra sin filtros ni límites de procedencia. El problema no es solamente una vulnerabilidad aislada. Es la composición de decisiones que parecían seguras por separado.
¿Por qué la seguridad agéntica no es AppSec tradicional?
Porque la superficie es dinámica, los límites de confianza suelen ser implícitos y la supply chain todavía carece de mecanismos básicos de revisión.
La superficie cambia con el contexto. El comportamiento de un agente depende del prompt, las herramientas disponibles, la conversación y el estado del entorno. La misma implementación puede ser razonable en una configuración y peligrosa en otra.
Conectar equivale a confiar. Cuando un agente se conecta a un MCP server, suele heredar todas las herramientas expuestas. Sin capacidades granulares ni restricciones sobre parámetros, el principio de mínimo privilegio queda fuera del diseño.
Las dependencias no se auditan de forma continua. Los equipos agregan servers y skills como agregaban paquetes, pero sin un equivalente maduro de lockfiles, advisories y monitoreo de cambios. Una revisión al instalar no detecta lo que cambia una semana después.
¿Por qué este es el momento de construir los controles?
La seguridad web necesitó años de incidentes antes de que OWASP, CSP y los defaults seguros fueran práctica habitual. El despliegue de agentes avanza en una curva mucho más rápida. Si los controles no se construyen junto con la infraestructura, después habrá que agregarlos sobre sistemas que ya dependen de permisos amplios y confianza implícita.
Por eso pienso la seguridad de agentes como infraestructura de producto. No como una función que se activa al final de un proyecto.
¿Qué debería hacer hoy un equipo que despliega agentes?
Revisar cada MCP server, skill y configuración antes de habilitarla. Asignar identidad y credenciales separadas. Limitar herramientas y parámetros. Aplicar políticas antes de las acciones sensibles. Registrar evidencia por invocación y monitorear cambios en las dependencias.
El análisis estático es necesario, pero no suficiente. Un agente puede respetar todas las reglas durante el deploy y desviarse cuando una herramienta, un prompt o un resultado externo cambia en runtime.
La decisión de seguridad más importante es de producto: qué autoridad recibe el agente, bajo qué condiciones puede usarla y qué evidencia queda cuando actúa.