Agentes IA: por qué el gateway no puede ser tu primer control

Por qué los gateways no pueden ser la primera línea de defensa de tus agentes IA

En junio de 2026, CISA añadió la falla CVE-2026-42271 de LiteLLM — uno de los gateways de modelos de lenguaje más usados del ecosistema — a su catálogo de vulnerabilidades explotadas activamente. El bug permitía ejecutar comandos en el host a través del propio gateway, y encadenado con un segundo defecto, no requería credenciales. Fue una de las siete CVEs publicadas en un solo mes para ese mismo componente, según recapitula el ingeniero principal Nik Kale en VentureBeat. El dato no es anómalo: en marzo de 2026, una versión troyanizada de LiteLLM permaneció tres horas en PyPI y acumuló cerca de 47.000 descargas, propagando un bot autónomo llamado hackerbot-claw que después atacó los pipelines de GitHub Actions de repos open source (Help Net Security).

LiteLLM actúa como puerta de entrada para frameworks como CrewAI, DSPy y Microsoft GraphRAG. Cuando el gateway mismo se convierte en el vector, el «control que primero desplegaste» deja de protegerte. Esa es exactamente la paradoja que describe Kale: los gateways son el primer control al que las empresas acuden y el menos preparado para operar, porque se apoyan en capas de identidad y atribución que, en la mayoría de despliegues, todavía no existen.

La cadena de dependencia: seis controles que deben construirse en orden

Kale propone un marco bautizado dependency-gated deployment: cada control solo está operativo cuando los que están por encima en la cadena ya están en producción. El orden importa.

🤖 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

Gate 1 — Inventario de agentes y propiedad. Cada agente en producción necesita un dueño nombrado, un propósito, herramientas aprobadas y un estado de ciclo de vida. Saltarse este paso significa perder la primera hora de respuesta a incidentes averiguando lo obvio.

Gate 2 — Identidad propia del agente y contexto de delegación. El agente no puede estar enterrado en un token de desarrollador o una cuenta de servicio compartida. El plano de control necesita saber quién delegó, qué tarea específica ejecuta y qué recursos debe tocar. Si esta conexión se rompe, los logs atribuyen cada acción del agente a un empleado que nunca inició la operación.

Gate 3 — Credenciales de corta duración y scoped a la tarea. Aquí entra el principio de delegación monótona: cada transferencia de responsabilidad debe preservar o reducir la autoridad, jamás aumentarla. Un agente que ve un ledger no puede heredar el acceso del empleado a todos los sistemas.

Gate 4 — Telemetría atribuible. Para cada tarea completada se debe poder reconstruir el inicio, el agente, la autoridad delegada, las herramientas y el resultado. En entornos regulados, una trazabilidad no atribuible no se puede justificar ante un auditor.

Gate 5 — Enforcement de runtime en el gateway. Recién aquí el gateway cumple su función real: con identidad, delegación, credenciales y telemetría ya en su sitio, puede decidir si la acción es coherente con el propósito. Los controles más duros se aplican en fronteras irreversibles: pagos, cambios de política de acceso, borrados, exportaciones de datos.

Gate 6 — Baselines conductuales y kill path cross-system. Contención no es solo desactivar un objeto en el directorio. Implica revocar la identidad del agente, invalidar credenciales activas y derivadas, bloquear activación de herramientas, terminar tareas en curso y aislar el workload.

El error sistemático, según Kale, es desplegar enforcement antes de tener el contexto que lo hace funcionar. El gateway, en otras palabras, debería ser el quinto control, no el primero.

Las cifras que presionan al CIO: sobreprivilegio, bremas y 90 identidades por persona

El argumento teórico tiene correlato empírico. El informe 2026 de Teleport sobre IA en seguridad empresarial, basado en 205 líderes de seguridad, encontró que las organizaciones con IA sobreprivilegiada reportaron una tasa de incidentes del 76%, frente a 17% en las que aplicaron principio de mínimo privilegio. El alcance del acceso pesa más que cualquier enforcement contextual en tiempo de ejecución.

El lado de la demanda confirma la tendencia. Tras presentar resultados del Q2 FY27 el 27 de agosto de 2026, las acciones de CrowdStrike (CRWD) subieron 20% y las de Okta (OKTA), entre 29% y 30% (247 Wall St). El CEO de CrowdStrike, George Kurtz, describió el momento como una «carrera armamentística» y estimó que cada persona tendrá cerca de 90 agentes desplegados, cada uno una identidad nueva, un set de permisos nuevo y una superficie de monitoreo nueva. Okta elevó su guía fiscal 2027 a aproximadamente USD 3.220-3.226 millones en ingresos, apoyada en parte por decenas de contratos vinculados a seguridad de agentes (Yahoo Finance).

La brecha de adopción es visible: en un único cliente, Okta detectó 50 instancias de un agente Claude y, semanas después, la cifra había crecido a 1.500. La encuesta de Okta 2026 sobre la fuerza laboral agéntica muestra que solo el 34% de los ejecutivos dice aplicar siempre el mismo rigor de seguridad a los agentes que a los empleados humanos. Y según datos de IBM citados por OWASP, apenas el 37% de las organizaciones tiene una política para detectar shadow AI dentro de su perímetro (Help Net Security).

El panorama de CVEs lo ratifica: en lo que va de 2026, CISA también añadió al KEV la falla CVE-2026-55255 de Langflow, un framework visual para construir agentes, explotada desde el 25 de junio para ejecución de código y entrega de implants (Bleeping Computer). El repositorio con más advisories de seguridad en el relevamiento de OWASP es n8n, con 57, seguido por Claude Code (22), AutoGPT (15), Dify (13) y Roo-Code (11).

¿Qué significa esto para tu startup?

Si estás desplegando agentes — sea para automatizar finanzas, soporte, código o ventas — el orden en que construyas la seguridad importa tanto como el hecho de construirla. Las empresas que primero compran un gateway de IA suelen descubrir, en producción, que tienen un control caro aplicado a una porción mínima del problema.

Acciones concretas para los próximos 30 días:

Levanta un registro mínimo de 10 agentes en producción. Por cada uno anota: dueño, propósito, herramientas aprobadas, dominios de datos y fuentes de credenciales. Este inventario es el activo que gobierna todo lo demás; sin él, tu gateway opera a ciegas.
Prueba la atribución hoy mismo. Pregúntale a tu IAM y a tu stack de logging si puede distinguir al agente del humano o servicio que delegó la tarea. Si la respuesta es no, cualquier control de runtime posterior funcionará sin visibilidad.
Reconstruye una tarea completa de agente de extremo a extremo. Desde el inicio hasta los efectos downstream: si la cadena se rompe en algún punto, ese es exactamente el hueco que un atacante — o un prompt injection — va a aprovechar.
Limita la autoridad antes de monitorear conducta. Credenciales de corta duración scoped a la tarea, basadas en lo que tu IAM ya soporta (workload identity, token exchange, conditional access, entitlements con expiración). La sobreprivilegüedad es el predictor más fuerte de incidentes según el estudio de Teleport.
Diseña el kill path antes de necesitarlo. Identidad del agente, credenciales activas y derivadas, herramientas, tareas en curso y workload: cada uno necesita su botón de paro, no basta con revocar un objeto en el directorio.

El mensaje de fondo para founders es claro: la madurez en seguridad de agentes no es un destino, es una secuencia. Saltarse pasos — por la urgencia de lanzar — convierte al gateway en un gasto que no protege lo que importa y deja abiertas exactamente las puertas que un incidente real va a forzar.