AIR capta 50 millones: los plugins de agentes ya necesitan un filtro
AIR salió del modo sigiloso el 1 de septiembre de 2026 tras captar 50 millones de dólares para desarrollar una plataforma de seguridad para agentes de inteligencia artificial. La información de TechCrunch desglosa dos rondas semilla —10 millones liderados por Sequoia y 40 millones por Greenoaks— y recoge que el sistema filtra cerca del 27% de los complementos y skills que encuentra en internet.
El producto presentado ese mismo 1 de septiembre intenta impedir que contenido no fiable llegue al contexto con el que un agente decide su siguiente acción. En el anuncio oficial de AIR, la compañía identifica tres clases de entrada: complementos no evaluados, sitios web no confiables y datos empresariales dinámicos; su cobertura abarca endpoints, nube y aplicaciones SaaS.
La nueva cadena de suministro está dentro del contexto
Un agente no depende únicamente del modelo que lo ejecuta. También puede cargar instrucciones, instalar capacidades, consultar páginas, conectarse a herramientas mediante MCP y combinar información externa con archivos o bases de datos de la empresa. Cada elemento que interviene en esa secuencia puede alterar lo que el agente interpreta y hace.
Por eso la analogía con una cadena de suministro resulta útil: las dependencias ya no son solo bibliotecas incorporadas durante el desarrollo. Algunas se seleccionan durante una tarea y pueden cambiar después de su aprobación. El riesgo incluye tanto un componente malicioso desde el principio como otro legítimo cuyo mantenedor, paquete descargado o fuente de instrucciones sea comprometido más tarde.
- Skill: aporta instrucciones o procedimientos al agente; el riesgo está en las órdenes incluidas y en los recursos externos de los que dependa.
- Plugin o complemento: amplía funciones y puede solicitar acceso a sistemas que convierten una instrucción manipulada en una acción con consecuencias.
- Servidor MCP: conecta herramientas y fuentes de datos con el agente; importan su identidad, configuración, permisos y dependencias.
- Fuente web: puede contener texto manipulado que el agente confunda con una instrucción válida.
- Dato interno: puede ser auténtico, pero inadecuado para ese agente por su sensibilidad, procedencia o nivel de acceso.
Este mapa explica el alcance del filtro prometido en el título: no se trata de declarar inseguros todos los plugins, sino de comprobar los componentes que pueden condicionar una decisión antes de incorporarlos al contexto.
El control de acceso no comprueba lo que una herramienta contiene
La gestión de identidad responde quién puede usar un sistema y qué operaciones tiene autorizadas. No determina si una instrucción recién obtenida de una página, una skill o un servidor MCP es fiable. Un agente correctamente autenticado todavía puede actuar sobre contenido contaminado dentro de los permisos que recibió legítimamente.
La propuesta de AIR añade tres funciones alrededor de ese límite: descubrir los agentes activos en una organización, interceptar acciones como cargar una skill o recuperar contenido de internet y contrastar herramientas con un catálogo evaluado. La descripción técnica de SecurityWeek añade que la evaluación ocurre antes y después del despliegue, busca instrucciones externas, comportamientos ocultos y paquetes que imitan herramientas legítimas, y permite revocar un complemento en los flujos que dependen de él.
La reevaluación es la diferencia operativa central. Una revisión puntual solo refleja el estado observado en ese momento; una integración aprobada puede descargar después un paquete modificado o quedar comprometida. El planteamiento de AIR consiste en retirar la confianza cuando cambia el componente, no en tratar la aprobación inicial como permanente.
Ese filtro tampoco sustituye los demás controles. La separación efectiva de agentes limita el alcance de una ejecución, mientras la verificación del contexto intenta evitar que una entrada peligrosa llegue a influirla. Permisos mínimos, aislamiento y revisión de componentes actúan sobre momentos distintos del riesgo.
El 27% mide decisiones del filtro, no eficacia probada
El porcentaje comunicado significa que los criterios actuales de AIR rechazan aproximadamente 27 de cada 100 complementos y skills localizados en internet. No permite concluir que todos los elementos descartados sean maliciosos ni que los aceptados estén libres de riesgo.
Para convertir esa tasa de rechazo en una medida de eficacia harían falta datos que no se han publicado con suficiente detalle: tamaño y composición de la muestra, periodo de observación, definición de rechazo, distribución por categoría y resultados de falsos positivos y falsos negativos. Tampoco son equivalentes un paquete malicioso, una vulnerabilidad, permisos excesivos y la ausencia de aprobación, aunque una empresa pueda decidir bloquear cualquiera de esos casos.
La cifra describe, por tanto, cuánto excluye el producto bajo sus propias reglas. La calidad de la protección dependerá de si esas reglas identifican amenazas reales, explican por qué se revoca una integración y detectan cambios relevantes antes de que afecten a un agente. Por ahora no hay una evaluación independiente citada que demuestre ese rendimiento.
Los 50 millones financian una apuesta todavía por validar
Las dos rondas muestran una apuesta inversora por una capa de seguridad transversal a distintos modelos y plataformas. Si los agentes eligen herramientas durante la ejecución, una empresa necesita inventariar no solo qué agentes tiene, sino también qué componentes consultan, de qué fuentes reciben instrucciones y qué flujos quedarían expuestos si una integración pierde la confianza.
El capital captado no demuestra que AIR vaya a convertirse en el estándar de esa capa ni que su catálogo cubra todo el ecosistema. Tampoco prueba la precisión del filtro. Sí respalda el desarrollo comercial de una tesis concreta: el control tradicional de acceso deja sin resolver la fiabilidad del contenido y del software que entra dinámicamente en el contexto.
Tras el lanzamiento están confirmados la financiación total, las dos rondas y el enfoque preventivo y continuo del producto. Quedan por conocer su cobertura entre diferentes agentes, la latencia que introduce, la trazabilidad de cada bloqueo y su desempeño frente a evaluaciones externas. Hasta que esos datos estén disponibles, el 27% debe leerse como una tasa operativa de AIR, no como una eficacia de seguridad demostrada.
Lee también:
Suscríbete a nuestro boletín
Reciba las últimas noticias sobre Web3, IA y criptomonedas directamente en su bandeja de entrada.