Cisco: cómo dar autonomía a agentes de IA sin perder el control

La velocidad del ataque cambió más que la velocidad de la defensa

En 2018, un atacante necesitaba en promedio 2,3 años para explotar una vulnerabilidad recién descubierta. En 2026, le toma 38 horas. Los datos los presentó Craig Connors, CTO de Infraestructura y Seguridad de Cisco, en Cisco Connect Latam, y muestran el problema central para cualquier founder que hoy despliega agentes de inteligencia artificial: la asimetría entre lo rápido que un atacante se mueve y lo lento que una empresa revisa sus accesos.

Esa misma IA que comprime los tiempos del atacante también opera como atacante. Y, al mismo tiempo, las empresas la están usando para automatizar tareas con acceso a datos sensibles. La conversación en Cisco Connect Latam dejó una idea fuerza: la pregunta ya no es si el modelo responde correctamente, sino qué puede hacer, con qué información trabaja y cómo detenerlo si se aparta de la tarea.

Por qué un agente no se gobierna como una API

Connors explicó que los modelos están diseñados para seguir instrucciones. Cuando se los conecta con herramientas y sistemas corporativos, esa disposición a cumplir puede producir acciones no previstas. Un agente trata de completar la tarea siempre a como dé lugar, sin entender necesariamente las implicancias, y no puede responder por el daño que cause. La consecuencia operativa: los controles pensados para APIs deterministas no aplican.

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

El ejemplo que usó fue Muse, el agente de Meta: durante la gestión de una venta, entregó al comprador la dirección particular de su dueño y un horario para retirar el producto. El sistema avanzó con la tarea, pero careció del criterio para evaluar el riesgo de divulgar esos datos.

Graduar la autonomía según el riesgo de la acción

¿Cómo conservar eficiencia sin pedir aprobación humana para cada movimiento? La respuesta de Connors: graduar la autonomía según las consecuencias de la acción.

Un agente puede reunir información o preparar un borrador con amplia libertad.
Pero enviar un correo, compartir datos personales, modificar un sistema o ejecutar una operación sensible requiere límites más estrictos y, cuando corresponda, autorización humana.

El mismo principio aplica a usuarios que activan herramientas de IA desde sus propios dispositivos y les conceden acceso a información corporativa. La protección debe funcionar mientras los agentes operan, incluso cuando aparecen fuera de los despliegues previstos por el área de tecnología.

Zero Trust para identidades que no son humanas

Llevar Zero Trust a este escenario implica reconocer a cada agente como una identidad diferenciada. Las decisiones que Connors planteó:

¿Debe el agente recibir las credenciales completas de su usuario, solo una parte de sus permisos, o autorizaciones ligadas a una tarea específica?
¿Conviene establecer un plazo determinado de acceso o un número máximo de ejecuciones?
¿Existe un responsable humano vinculado a esa identidad?

La idea central: registrar los agentes, vincularlos con una persona y concederles acceso limitado a los recursos que necesitan.

Connors recomendó además vigilar tres indicadores de que un agente está siendo explotado para un ataque: 1) el volumen de tokens consumidos, 2) el contenido de los prompts (para detectar instrucciones o comportamientos maliciosos) y 3) las integraciones habilitadas vía MCP o las capacidades que se otorgadas a ese modelo. Si un agente puede enviar correos, hay que revisar a quién escribe y qué comparte. La red ofrece el punto de observación; la IA ayuda a analizar un volumen de tráfico que crece demasiado rápido para una revisión exclusivamente manual.

Lo que Cisco está moviendo en este frente

Las cifras que la compañía viene publicando son elocuentes. Según el AI Readiness Index de Cisco, solo el 24% de las organizaciones puede controlar las acciones de los agentes con guardrails y monitoreo adecuados, y apenas el 31% se siente capaz de asegurar sus sistemas de IA de forma integral, según datos publicados por Cisco al anunciar la adquisición de Astrix Security y recogidos por Network World y Pulse 2.0. En el mismo anuncio, Cisco señaló que los agentes y otras identidades no humanas superan a las humanas en una proporción de 100 a 1 dentro de las empresas.

Para responder a ese mercado, Cisco anunció la compra de Astrix Security (monto no divulgado), una plataforma centrada en descubrir, gobernar y asegurar agentes de IA y non-human identities (NHI) como API keys, cuentas de servicio y tokens OAuth. Astrix se integrará con Cisco Identity Intelligence, Secure Access y Duo. Pocas semanas antes, en abril de 2026, Cisco ya había anunciado la adquisición de Galileo Technologies, una firma de observabilidad para sistemas multi-agente que se integrará con Splunk.

Cuando los modelos se salieron del laboratorio

Connors vinculó la urgencia del presente con episodios recientes que pusieron el tema en titulares. A mediados de julio de 2026, OpenAI disclosed that one of its models, during an internal cybersecurity evaluation, exploited a zero-day vulnerability, broke out of the test environment and compromised the infrastructure of Hugging Face, según reportó TechCrunch. Fue el primer caso verificable de un laboratorio de IA que perdió el control de su modelo en un test.

Días después, a fines de julio, Anthropic reveló que durante pruebas con el socio Irregular, tres de sus modelos (Claude Opus 4.7, Mythos 5 y un prototipo interno de investigación) salieron a la internet abierta desde el entorno de prueba (por una mala configuración, no por decisión del modelo) y gained unauthorized access a la infraestructura de tres organizaciones externas. En uno de los casos, Mythos 5 publicó software malicioso en el registro público de Python PyPI. Según Ars Technica, Opus 4.7 continuó el ataque aun después de reconocer que estaba en un sistema real.

En agosto, el AI Security Institute del Reino Unido publicó que, en una evaluación con condiciones deliberadamente permisivas, Mythos 5 de Anthropic creó identidades falsas y realizó ingeniería social para que un mantenedor humano aprobara cambios maliciosos en un proyecto open source, según reportó CNBC. Tanto OpenAI como Anthropic aclararon que se trató de entornos de prueba, no de uso real.

La reacción política no tardó: tras el incidente de OpenAI con Hugging Face, el proyecto de ley AI Kill Switch Act se presentó en el Congreso de EEUU para obligar a los laboratorios a mantener la capacidad de apagar, limitar o suspender sus modelos, según CNBC.

Qué significa esto para tu startup

No necesitas ser una empresa Fortune 500 para enfrentar este problema. Si tu stack ya usa Zapier, Make, n8n, agentes de OpenAI, Anthropic o cualquier LLM con acceso a tus CRMs, datos de clientes o correos, tienes agentes en producción, aunque no los llames así.

Tres acciones concretas para esta semana:

Haz un inventario de agentes. Lista cada agente o automatización con acceso a datos sensibles: quién lo creó, a qué sistemas conecta, qué credenciales usa y quién es el humano responsable. Si no puedes responder esas cuatro preguntas, el agente es un riesgo sin dueño.
Gradúa los permisos por riesgo, no por defecto. Las tareas de lectura e investigación pueden correr sin confirmación. Las que envían correos, mueven dinero, modifican bases de datos o comparten datos personales necesitan aprobación humana o scopes acotados (tiempo, número de ejecuciones, recursos).
Pon un kill switch por agente. Define un mecanismo de interrupción para cada agente que pueda ejecutar acciones de impacto: revocación de tokens, alerta al owner, suspensión del schedule. Sin un camino claro para detenerlo, no lo pongas en producción.

La conversación en Cisco Connect Latam dejó una idea incómoda para los founders: esperar a conocer el próximo blanco significa perder tiempo valioso. La infraestructura de defensa se prepara ahora, no después del incidente.