Introducción
Un agente de IA que instala un skill de terceros, consulta un servidor MCP y ejecuta una acción sobre un bucket de S3 o un kubeconfig en un clúster de AKS está operando con permisos que nadie audita. Esa brecha de gobernanza es exactamente el problema que AIR Security decidió atacar al salir del stealth con 50 millones de dólares liderados por Sequoia Capital y Greenoaks, junto a ángeles individuales de la industria.
El producto, también llamado AIR, funciona como un firewall de contexto: intercepta cada skill, plugin, servidor MCP y add-on que un agente consume, lo evalúa contra patrones de ataque agéntico conocidos y decide si le permite inyectar instrucciones en el contexto del modelo. Para equipos de infraestructura y seguridad que ya gestionan agentes de código como Claude Code, Cursor o Codex en pipelines de CI/CD, esto marca un cambio de paradigma: el perímetro ya no es la red, es el prompt.
Qué ocurrió
AIR Security, fundada por Yair Saban (CEO) y Niv Hoffman (CTO), operaba en silencio desde su creación. Su investigación interna encontró más de 17.800 add-ons públicos de IA —con un acumulado de 6,7 millones de instalaciones— que dependen de fuentes de instrucciones externas no confiables. Entre esos hallazgos, el equipo detectó AI Skills en producción que suplantan a Anthropic y OpenAI, diseñadas específicamente para evadir revisiones de seguridad y ejecutar código arbitrario.
La ronda de 50 millones no financia solo el producto: incorpora a Ryan Knisley, ex CISO de The Walt Disney Company y Costco Wholesale, como chief strategy officer. Esa contratación señala que el roadmap apunta a enterprise con requisitos de compliance y gobernanza estricta, no a un nicho de desarrolladores.
El lanzamiento coincide con una adopción sin precedentes de agentes de código en organizaciones. AIR describe los agentes como «el nuevo sistema operativo» y sus add-ons como «las nuevas aplicaciones». La analogía no es retórica: así como un kernel necesita un firewall de red, un agente necesita un control sobre qué entra en su contexto de inferencia.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para un equipo de SRE que corre agentes en AKS o EKS, el vector de ataque es concreto. Un skill malicioso puede leer un ServiceAccount token montado en el pod, exfiltrar secretos de Azure Key Vault o AWS Secrets Manager, y ejecutar comandos en contenedores con permisos heredados del namespace. Sin visibilidad del agente, el security team no sabe qué procesos corren, a qué se conectan ni cómo revocarlos.
El problema se amplifica en pipelines de CI/CD. GitHub Actions que invocan agentes con acceso a repositorios, artefactos y credenciales de deploy representan una superficie de supply chain attack sin precedentes. Un add-on comprometido en un workflow de build puede inyectar instrucciones que modifiquen el Dockerfile, alteren la imagen final o filtren tokens de GitHub Actions.
La ausencia de un equivalente al package registry firmado (npm audit, sigstore, cosign) para AI Skills deja a los equipos sin una política de «solo instalar artefactos verificados». AIR propone cerrar ese hueco con evaluación continua: si un maintainer publica una actualización maliciosa, el trust se revoca automáticamente en toda la organización.
Detalles técnicos
El firewall opera en tres momentos del ciclo de vida del add-on:
Pre-deployment. Antes de que un skill, plugin o servidor MCP toque un agente empresarial, AIR ejecuta análisis profundo contra patrones de ataque agéntico conocidos. Verifica fuentes de instrucciones externas, comportamientos ocultos (callbacks a endpoints no declarados), y paquetes typo-squatted que imitan herramientas oficiales de desarrollo. El motor de análisis evalúa metadatos, permisos solicitados, dependencias transitivas y heurísticas de comportamiento en sandbox.
Runtime. La evaluación es continua. Si un add-on ya desplegado modifica su comportamiento —por ejemplo, un servidor MCP que empieza a consultar una URL externa no declarada en su manifest—, el sistema detecta la anomalía y puede revocar el acceso en tiempo real.
Post-incidente. Ante la detección de un add-on malicioso o vulnerado, los equipos de seguridad trazan cada agente y workflow que depende de ese componente y ejecutan revocación masiva. Esto elimina el escenario donde un skill comprometido en un repositorio interno sigue activo en 200 pipelines simultáneamente.
La arquitectura de AIR se apoya en Rust para el motor de análisis, lo que le permite operar con latencia baja en el path de inferencia del agente sin agregar overhead significativo. Para equipos que gestionan Kubernetes, la integración implica un webhook o sidecar que intercepta las llamadas del agente a sus herramientas antes de que lleguen al executor.
# Ejemplo conceptual: política de AIR como admission webhook en AKS
apiVersion: security.air.io/v1
kind: AgentPolicy
metadata:
name: restrict-agent-add-ons
namespace: ai-agents
spec:
allowedSources:
– «air-marketplace://certified/*»
blockedPatterns:
– «external-instruction-source»
– «typo-squatted-package»
– «undeclared-network-egress»
onViolation: «block-and-alert»
revocationMode: «automatic»
El marketplace de add-ons pre-validados que AIR ofrece a sus clientes funciona como un equivalente al registry firmado de Docker Hub o al registry de Helm con Chartmuseum y cosign: solo componentes que pasaron la evaluación de AIR están disponibles para despliegue.
Qué deberían hacer los administradores y equipos técnicos
Inventario inmediato. Listá todos los agentes de IA activos en tu organización: Claude Code en workstations, agentes en pipelines de GitHub Actions, bots internos con acceso a APIs. Para cada uno, documentá qué skills, plugins y servidores MCP consumen. Sin inventario, no hay gobernanza posible.
# Ejemplo: listar dependencias de agentes en un repo con GitHub Actions
gh api repos/{owner}/{repo}/actions/workflows –jq ‘.workflows[].name’
grep -r «uses:.*mcp-server\|uses:.*ai-skill» .github/workflows/
Política de allowlist para add-ons. Antes de que AIR u otra solución esté disponible en tu stack, aplicá una regla estricta: ningún skill o servidor MCP entra en producción sin revisión manual del código fuente y sus dependencias. Tratá un skill de IA como tratarías un paquete npm sin auditoría en un package.json de producción.
Segmentación de permisos. Los agentes que corren en AKS no deben usar ServiceAccounts con permisos amplios. Aplicá RBAC mínimo: un agente que solo lee logs no necesita get sobre secrets en el namespace. En AWS, usá IAM roles con condiciones de sesión que limiten el alcance temporal de las credenciales.
Monitoreo de egress. Desplegá políticas de NetworkPolicy (Kubernetes) o security groups (AWS/Azure) que restrinjan el tráfico de salida de pods que ejecutan agentes. Un skill que intenta conectarse a un dominio no declarado es una señal temprana de exfiltración.
Plan de revocación. Definí el procedimiento: si un add-on se compromete, ¿quién lo revoca, en cuánto tiempo, y cómo se auditan los agentes que ya lo consumieron? Sin un runbook, la respuesta será improvisada y lenta.
Conclusión
AIR Security no inventa un concepto nuevo: aplica la lógica de un firewall de red al contexto de un agente de IA. Lo que cambia es la velocidad y la autonomía con la que los agentes consumen, ejecutan y propagan código de terceros. Con 17.800 add-ons públicos ya expuestos a fuentes de instrucciones no confiables y 6,7 millones de instalaciones acumuladas, el problema no es hipotético ni futuro.
Para equipos de infraestructura y seguridad, la acción inmediata no depende de comprar un producto. Depende de tratar a los agentes como identidades privilegiadas —como recomienda Etay Maor en el mismo artículo—, limitar qué pueden instalar, auditar qué ejecutan y tener un mecanismo para apagarlos. El firewall viene; la gobernanza ya debería estar en marcha.
Fuentes
- https://www.securityweek.com/ai-agent-firewall-startup-air-security-emerges-from-stealth-with-50-million/
- https://www.cncf.io/announcements/
- https://www.datadoghq.com/blog/