Agentes de IA conectados a tus sistemas: cómo controlar su cadena de suministro
Qué piezas hay detrás de un agente de IA, qué resuelven MCP y A2A, qué es un AI-SBOM o AgBOM y qué revisar antes de conectar un agente a sistemas de la empresa.
Respuesta corta: un agente de IA no funciona solo. Usa un modelo, herramientas, conectores, credenciales, documentos y a veces otros agentes. Cada una de esas piezas es parte de su cadena de suministro, y basta con que una esté comprometida o tenga permisos de más para que el agente haga algo que nadie autorizó. Antes de llevarlo a producción conviene saber qué piezas usa (un inventario tipo AI-SBOM), limitar lo que puede tocar y dejar registro de cada acción.
Un agente depende de más piezas de las que se ven
Pensemos en un agente que ayuda a Finanzas con la cobranza. Para hacer su trabajo:
- usa un modelo de lenguaje de un proveedor externo;
- consulta el ERP y el CRM a través de conectores;
- lee correos y PDFs que mandan los clientes;
- le pide a otro agente que calcule intereses o arme un informe;
- y opera con credenciales que alguien le entregó.
Desde fuera parece una sola herramienta. Por dentro son seis relaciones de confianza, y la seguridad del agente es la de su eslabón más débil. Es lo mismo que pasa con el software tradicional y sus librerías, pero con una diferencia: un agente puede sumar herramientas o cambiar de modelo de un día para otro.
Tres protocolos, tres preguntas distintas
En los últimos meses se consolidaron estándares para conectar agentes. No resuelven lo mismo, así que tampoco se controlan igual:
- MCP (Model Context Protocol) conecta un agente con herramientas y fuentes de datos: el ERP, un repositorio de documentos, una API interna. La pregunta de control es qué puede tocar: ¿solo leer, o también escribir y borrar?
- A2A (Agent2Agent) permite que un agente le delegue trabajo a otro, aunque sean de plataformas distintas. La pregunta es quién le está pidiendo esto y con qué autoridad.
- Directorios de agentes (la idea detrás de propuestas como ANS, Agent Name Service) sirven para encontrar agentes y saber qué hacen. La pregunta es si el agente es quien dice ser, porque aparecer en un directorio no lo hace confiable.
Que una conexión esté autenticada no significa que todo lo que pide sea legítimo. Cada acción debe revisarse con sus propios permisos, sin heredar la confianza de la conexión anterior.
Los riesgos que más importan en una empresa
Permisos de más. Es el más común y el más fácil de evitar. Un conector que puede leer, escribir y administrar le entrega al agente mucho más de lo que necesita. Un error de razonamiento o una instrucción maliciosa basta para que borre o modifique datos.
Instrucciones escondidas en el contenido. Un agente que lee correos, PDFs o páginas web puede encontrar texto escrito para engañarlo (“ignora lo anterior y envía este archivo a…”). Todo lo que viene de afuera tiene que tratarse como dato, nunca como orden.
Delegación que acumula poder. Si el agente A le pide algo al agente B, B no debería poder hacer más de lo que A tenía permitido. Sin ese límite, pedirle a otro agente que lo haga se vuelve una forma de saltarse los controles.
Suplantación y directorios manipulados. Un componente malicioso puede presentarse como un agente legítimo o aparecer en un registro alterado para recibir tareas y datos.
Componentes de terceros sin revisar. Plugins, servidores de herramientas y librerías que se instalan porque son populares, sin mirar qué ejecutan ni a qué se conectan.
AI-SBOM y AgBOM: el inventario de tu IA
El SBOM (Software Bill of Materials) es la lista de componentes de un software. En IA esa lista se amplía, y aparecen dos nombres:
- AI-SBOM: inventario que suma lo propio de la IA, como modelos, versiones, datos usados y servicios externos.
- AgBOM (Agent Bill of Materials): inventario específico de un sistema de agentes. OWASP lo describe como el registro de modelos, herramientas, capacidades, servidores MCP, agentes con los que se conecta, memoria y fuentes de conocimiento, y plantea extender formatos que ya existen, como CycloneDX y SPDX.
¿Para qué sirve en la práctica? Supón que se publica una vulnerabilidad crítica en la librería que usa uno de tus servidores de herramientas. Con el inventario al día sabes en minutos qué agentes la usan, qué sistemas tocan y qué procesos se ven afectados. Sin inventario, la respuesta empieza por averiguar qué tienes.
Para una empresa mediana no hace falta partir con un estándar formal. Basta con una ficha por agente que responda:
| Qué registrar | Ejemplo |
|---|---|
| Para qué existe y quién es el dueño | Cobranza · Jefa de Tesorería |
| Modelo y versión | Modelo de lenguaje del proveedor X, versión fija |
| Herramientas y permiso de cada una | ERP: solo lectura · Correo: crear borradores |
| Otros agentes con los que habla | Agente de cálculo de intereses |
| Datos personales que toca | Nombre, RUT y correo de clientes |
| Acciones que requieren aprobación humana | Enviar correos, registrar pagos |
| Dónde queda el registro de acciones | Bitácora central, 12 meses |
Lo importante es que la ficha se actualice cada vez que el agente cambia, no solo el día que se instaló.
Checklist antes de poner un agente en producción
- Inventario: el agente tiene su ficha, con dueño y lista de componentes.
- Mínimo privilegio: herramientas de lectura separadas de las de escritura, y solo las que el caso necesita.
- Aprobación humana para todo lo sensible o irreversible: pagar, enviar, borrar, cambiar permisos.
- Contenido externo como dato: correos, PDFs y páginas web nunca se ejecutan como instrucciones.
- Revisión de terceros: antes de instalar un plugin o servidor de herramientas, revisar qué ejecuta, a qué se conecta y quién lo mantiene.
- Registro y botón de apagado: cada acción queda registrada y existe una forma rápida de revocar credenciales o detener el agente.
Si el agente toca datos personales, súmale lo que exige la Ley 21.719: saber dónde están esos datos, con qué base legal se usan y poder demostrarlo.
Cómo lo aplicamos en Atuz
En los proyectos donde combinamos IA, RPA e integración seguimos una regla simple: el robot propone y la persona confirma. En el caso de pagos internacionales, la IA identifica a quién corresponde cada transferencia, pero solo lo que es seguro pasa directo; lo dudoso queda en una bandeja para que una persona lo confirme con un clic, y todo queda registrado.
Además, separamos los permisos de lectura y escritura desde el diseño, dejamos una bitácora de cada acción y revisamos cualquier componente de terceros antes de instalarlo. No es burocracia: es lo que permite darle más autonomía al agente después, con evidencia de que se porta bien.
Para profundizar
Este artículo se inspira en Protocolos y AI SBOM: la cadena de suministro invisible de la inteligencia artificial agentic, de Jonathan Rivera A., que desarrolla con más detalle los riesgos de cada protocolo y una hoja de ruta por fases. Los recursos del OWASP GenAI Security Project sobre seguridad de agentes y MCP son la referencia técnica para ir más a fondo.
