Los complementos de agentes de IA necesitan el equivalente a controladores firmados
Los equipos de IA empresariales están pasando de preguntarse si un agente es seguro a una cuestión más urgente: ¿qué instaló, a qué se conectó o qué aprendió el agente antes de actuar?
Ese cambio es importante porque el agente útil rara vez es una aplicación cerrada. Es un sistema que se extiende hacia afuera. Llama a un servidor MCP, carga una habilidad, recupera un documento, usa un conector, sigue instrucciones en una página web y actúa en sistemas que contienen datos reales de la empresa. El agente no es solo software. Es una cadena de suministro en movimiento.
Esta semana, la startup de seguridad de agentes AIR se presentó públicamente con 50 millones de dólares en financiación semilla centrada en esa cadena de suministro. Su premisa declarada es sencilla: las habilidades de agentes, plugins, servidores MCP, subagentes, sitios web y datos internos pueden convertirse en entradas para el contexto de un agente, y cada entrada puede cambiar lo que el agente hace. Eso no es un problema de seguridad marginal. Es el modelo operativo que las empresas están adoptando rápidamente.
La analogía más útil no es otro chatbot de IA. Es el controlador firmado.
Por qué una extensión de agente es más como un controlador que una aplicación
Una aplicación tradicional suele revisarse como un software independiente. Una extensión de agente se comporta de forma diferente. Puede exponer herramientas, inyectar instrucciones, solicitar credenciales, dirigir recuperaciones y moldear acciones posteriores. Un conector aparentemente inofensivo puede convertirse en un acceso a datos sensibles o en un vehículo para un ataque de inyección de instrucciones.
El CEO de AIR, Yair Saban, hizo la comparación claramente al informar sobre el lanzamiento: los sistemas operativos modernos esperan que los controladores estén firmados porque cargan código en una parte sensible de la máquina. Las habilidades y plugins de agentes pueden alterar una parte igualmente sensible de un agente: su contexto de trabajo y las acciones permitidas. Sin embargo, las empresas a menudo los instalan con mucha menos evidencia de procedencia, alcance o control de cambios.
Esa brecha es mayor de lo que puede resolver un escaneo de vulnerabilidades. Un paquete puede estar libre de malware conocido y aun así ser inseguro para un agente en particular. Una habilidad puede ser legítima pero solicitar más herramientas de las que su función requiere. Un servidor MCP puede ser confiable hoy y recibir instrucciones diferentes mañana. Un conector puede tener un propósito comercial válido pero ser inapropiado para un agente que maneja contratos, registros de clientes o flujos financieros.
La pregunta de gobernanza no es simplemente «¿Es este complemento malicioso?» sino «¿Debe permitirse que este agente consuma este componente, con esta identidad, estos datos y esta autoridad, en este momento?».
El problema oculto: la adquisición ocurre dentro de los flujos de trabajo
La mayoría de los programas de seguridad empresarial ya tienen un proceso para aprobar proveedores SaaS. Pueden tener análisis de composición de software para dependencias de desarrolladores. Pero los complementos de agentes a menudo se adquieren de forma mucho menos visible.
Un empleado crea un flujo de trabajo. El flujo necesita una nueva capacidad. El creador del agente selecciona un servidor MCP o una habilidad de un catálogo, un repositorio Git, un mercado o la recomendación de un colega. Aparece un aviso de permisos. El trabajo continúa.
Eso es adquisición, integración y despliegue en producción comprimidos en unos pocos clics.
También produce IA en la sombra en una nueva forma. El problema ya no es solo que los empleados peguen datos sensibles en un modelo no aprobado. Son componentes de agentes no aprobados que obtienen acceso a sistemas empresariales, a menudo por equipos bien intencionados que intentan avanzar más rápido. El equipo de seguridad no puede gobernar lo que no puede descubrir, y no puede tomar buenas decisiones a partir de una hoja de cálculo que queda obsoleta al día siguiente.
Construye un proceso de confianza para complementos de agentes, no una revisión única
La respuesta no es prohibir todos los conectores. Eso empujaría la adopción fuera de la vista. La respuesta es hacer que el camino seguro sea más rápido que el invisible.
Comienza con cuatro controles prácticos.
1. Crea un inventario de componentes de IA
Rastrea agentes, habilidades, servidores MCP, plugins, conectores, modelos, fuentes de datos, propietarios y los sistemas a los que puede acceder cada componente. Incluye componentes tanto sancionados como descubiertos. Un inventario que solo lista herramientas aprobadas es un registro de políticas, no un registro de riesgos.
El [marco AI-BOM de Aona](/blog/ai-bom-shadow-ai-enterprise-security-inventory) es un buen punto de partida: trata las dependencias e integraciones del agente como objetos de gobernanza de primera clase, no como detalles de implementación.
2. Exige procedencia y propósito antes de la conexión
Para cada componente externo, registra quién lo mantiene, su origen, qué hace, a qué datos puede acceder, qué herramientas puede invocar y qué flujo de trabajo empresarial soporta. Esto debe ser proporcional. Una búsqueda de conocimiento solo lectura no es lo mismo que un conector que puede enviar correos, modificar un registro CRM o activar un flujo de pagos.
La clave es la evidencia. «Es popular» y «el equipo lo necesitaba» no son decisiones basadas en riesgos.
3. Vincula la autoridad a la tarea y luego déjala expirar
Un agente debe recibir la autoridad mínima necesaria para una tarea específica, no un conjunto permanente de permisos amplios. Usa identidades distintas cuando sea posible. Limita el alcance de las herramientas. Establece límites temporales. Requiere aprobación humana para acciones de alto impacto.
Este enfoque se basa en un principio que cubrimos en [permisos de agentes de IA](/blog/ai-agent-expiring-permissions-enterprise-governance): la revocación debe diseñarse antes de un incidente, no improvisarse después. También evita que un complemento comprometido o modificado herede más poder del que su función justifica.
4. Verifica continuamente los cambios y el comportamiento en tiempo real
Firmar o revisar un componente una vez no es suficiente. Los complementos de agentes cambian. Sus dependencias cambian. Sus instrucciones y puntos finales externos pueden cambiar. Monitoriza la desviación de configuración, nuevas solicitudes de permisos, llamadas alteradas a herramientas, acceso inesperado a datos y acciones fuera del propósito aprobado del agente.
Aquí es donde la gobernanza se vuelve operativa. Las alertas necesitan un responsable y un camino de decisión: permitir, restringir, poner en cuarentena o investigar. La observabilidad sin capacidad de intervención es un mejor informe de incidentes, no un control.
Lo que los CISOs deben preguntar este trimestre
Una revisión ejecutiva útil es breve y específica:
- ¿Qué agentes y complementos de IA están actualmente conectados a nuestros sistemas?
- ¿Cuáles de esos componentes fueron descubiertos en lugar de aprobados formalmente?
- ¿Podemos identificar los datos, herramientas, identidades y propietarios asociados a cada uno?
- ¿Qué sucede cuando un componente cambia después de la aprobación?
- ¿Qué acciones requieren la aprobación de una persona antes de ejecutarse?
Si las respuestas requieren arqueología manual entre varios equipos, la empresa ya ha llegado al punto en que la adopción de agentes supera a la gobernanza.
El lanzamiento de AIR es una señal oportuna, no porque un nuevo proveedor cambie el mercado, sino porque nombra un cambio arquitectónico real. La superficie de ataque ahora es la cadena de contexto, herramientas y componentes en los que un agente confía. Los controles de seguridad diseñados para aplicaciones estáticas no detectarán ese movimiento.
Las empresas no necesitan ralentizar sus programas de IA. Necesitan tratar los complementos de un agente como componentes de computación confiables: descubrirlos, verificarlos, restringirlos y seguir verificándolos después del despliegue.
Si intentas mapear la IA en la sombra y las conexiones de agentes que ya operan en tu entorno, [habla con Aona](/contact-us?utm_source=blog&utm_medium=organic&utm_campaign=agent-add-on-governance). Ayudamos a los equipos de seguridad a convertir el descubrimiento de IA en políticas, evidencias y acciones.
