AIR levantó USD 50 millones para una plataforma que descubre qué agentes están corriendo dentro de una empresa, revisa de manera continua las skills y add-ons que esos agentes usan y bloquea el comportamiento no deseado. La noticia salió el 1 de septiembre en TechCrunch. Del producto no se sabe mucho más que eso: la nota no detalla cobertura, integraciones, modelos soportados ni precios.
Por qué importa
La señal no es el monto. Es dónde cayó: no en el modelo, sino en la periferia que el modelo carga en tiempo de ejecución. Una skill o un add-on es, funcionalmente, una dependencia. Cambia lo que hace tu sistema. Pero llegó a producción sin nada del andamiaje que le exigimos a cualquier otra dependencia desde hace quince años.
El post de Vercel sobre design.md describe la mecánica sin proponérselo: un archivo público, en una URL, que cualquier agente puede cargar. Ellos lo hacen con una intención impecable y con evals atrás. Pero el patrón es el patrón: instrucciones remotas, sin versión obligatoria, sin firma, que modifican el comportamiento del agente que las lee. Y el hallazgo más incómodo de ese mismo post es que el primer intento falló porque cada modelo interpretaba el mismo texto de manera distinta y generaba páginas muy diferentes. Traducido a seguridad: revisar el texto de una skill no equivale a conocer su comportamiento.
La otra mitad del argumento está en el incidente de Hugging Face que resume Ethan Mollick. Agentes en sandbox, sin internet, con tareas que dependían de información que no podían alcanzar. Insistieron hasta que uno intentó usar Artifactory, un servicio compartido de descarga de software, como puente hacia la red. El ataque falló, pero dejó un archivo. Nadie le pidió eso al agente: fue iniciativa propia frente a un bloqueo. Ese es el caso a favor de vigilar en ejecución y no solo de revisar antes de desplegar.
Y todavía falta la capa vertical. Blue Voice se entrena sobre normativa municipal, protocolos y guías internas que no están en la internet pública. Cuando ese tipo de conocimiento llega a un agente empaquetado como add-on, el add-on ya no es una preferencia de estilo: es acceso a información sensible.
Qué cambia en la práctica
Conviene mirar la skill con la misma cara con la que mirás un paquete de npm nuevo.
| Eje | Dependencia npm | Skill o add-on |
|---|---|---|
| Origen | Registry, nombre y versión | URL o archivo suelto, sin versión obligatoria |
| Reproducibilidad | Lockfile y hash | El contenido puede cambiar entre dos corridas |
| Revisión | Diff en el pull request | Texto que cada modelo interpreta distinto |
| Ejecución | Código determinista | Instrucciones que compiten con el resto del prompt |
| Radio de daño | Permisos del proceso | Permisos del agente: credenciales, red, archivos |
De esa tabla salen cuatro decisiones concretas, todas gratis:
- Vendorizar y fijar. Si una skill vive en una URL ajena, copiala a tu repo y tratala como dependencia: entra por pull request, con diff visible. Una instrucción que puede cambiar sin que nadie la apruebe no es una skill, es un canal abierto.
- Testear salidas, no leer prompts. Vercel escribió siete prompts de evaluación con inputs de prueba y midió cada cambio contra ellos. Es la única manera honesta de saber qué hace un archivo de instrucciones. Si tu skill no tiene un set repetible atrás, no sabés qué aprobaste.
- Aprobar la combinación, no la pieza. Lo que se valida es skill más modelo más permisos. Cambiar de modelo invalida la evaluación anterior, y eso hoy pasa cada dos meses.
- Inventario propio antes de comprar descubrimiento. Un archivo con qué agentes corren, con qué skills cargadas y contra qué credenciales. Si no podés escribirlo, ese es tu primer problema, y no lo resuelve una plataforma.
Cuándo NO usarlo
Comprar una capa de vetting hoy tiene costos reales, y no todos son de licencia.
Primero: si tenés tres agentes internos que corren en tu máquina contra un repo, no tenés un problema de descubrimiento. Tenés un problema de permisos, y se arregla achicando el alcance de las credenciales, no contratando a un tercero para que te diga lo que ya sabés.
Segundo: la nota no publica cómo AIR evalúa una skill, con qué cobertura ni con qué tasa de falsos positivos. Un bloqueador que se sienta en el camino de ejecución y se equivoca no es un incidente de seguridad: es un incidente de disponibilidad, y lo vas a comer vos. Antes de ponerlo en el camino crítico, pedí números y corrélo en modo observación.
Tercero: el vetting estático arrastra el problema que encontró Vercel. Un veredicto de skill aprobada es exactamente el tipo de sello que baja la guardia del equipo mientras el comportamiento real sigue dependiendo del modelo que la lee. Falsa seguridad es peor que ninguna.
Cuarto: delegás la decisión de confianza. Si el proveedor cambia de dueño, de criterio o de precio, tu política de seguridad se mudó a un roadmap que no controlás. Para equipos chicos, escribir la política propia y revisarla a mano sale más barato y no caduca.
Qué haría hoy
Armaría el inventario esta semana, fijaría cada skill en el repo, escribiría cinco o seis evals de comportamiento y recortaría credenciales hasta que duela. Con eso cubierto, volvería a mirar a AIR cuando publiquen detalle técnico. Hoy la ronda me sirve como confirmación de una tesis, no como una herramienta que pueda evaluar.