Gobierno de agentes de IA: permisos, identidad y auditoría
Gobernar agentes de IA es decidir, antes de que actúen, quién puede usar qué herramienta, con qué identidad y con qué límites, y dejar constancia de todo lo que hacen. Hoy cada servidor MCP lo resuelve a su manera, o no lo resuelve. Conviene llevarlo a un único punto antes de que alguien te pida cuentas.
¿Qué cambia cuando un agente de IA usa herramientas reales?
Un asistente que solo conversa puede equivocarse en lo que dice. Un agente con herramientas puede equivocarse en lo que hace: consultar una base de datos que no debía, abrir cien tickets, cambiar una configuración o borrar un registro.
En una operación crítica se ve claro: un agente que consulta el estado de la red te ahorra tiempo; uno que además puede cambiar una consigna o cerrar una válvula necesita otra conversación.
Esas herramientas llegan cada vez más por MCP (Model Context Protocol), un estándar abierto con el que los asistentes y agentes de IA usan herramientas externas: consultar una base de datos, abrir un ticket, leer un documento. MCP estandariza cómo se conecta un agente a una herramienta. Quién debería poder usar cada una, y con qué límites, queda en manos de cada servidor.
El riesgo se desplaza de lo que el modelo dice a lo que el agente hace. Y lo que hace ocurre en tus sistemas.
¿Dónde están los riesgos de los agentes con MCP?
Cada servidor gestiona los permisos a su manera
Cada herramienta que usa un agente lee datos o ejecuta acciones. Y cada servidor MCP gestiona los permisos a su manera, o no los gestiona. Con tres servidores es manejable; con treinta, ya nadie sabe qué agente puede hacer qué. Las credenciales acaban repartidas por ficheros de configuración, y los permisos, en la memoria de quien los configuró.
Una herramienta puede cambiar después de aprobarla
El agente decide qué hacer con una herramienta leyendo su descripción. Si esa descripción cambia después de que la hayas aprobado, el agente cambia lo que hace con ella, sin que nadie lo revise. Es lo que se conoce como «rug pull» de herramientas: lo que aprobaste ya no es lo que se ejecuta.
Te van a pedir cuentas
Cuando algo salga mal, alguien preguntará quién hizo qué, con qué permiso y cuándo. «Lo hizo el agente» no es una respuesta. Necesitas un registro en el que se pueda confiar, y que nadie haya podido retocar después.
¿Qué principios debe cumplir el gobierno de agentes de IA?
Estos siete principios resumen lo que hace falta para que un agente trabaje con sistemas reales sin convertirse en una caja negra:
| Principio | Qué significa | Qué evita |
|---|---|---|
| Un único punto de entrada | Todos los servidores MCP se registran, se descubren y se enrutan en un solo sitio | Agentes conectados a herramientas que nadie ha inventariado |
| Identidad sin atajos | Cada agente y cada usuario se identifican con tu proveedor (OIDC), sin reenviar sus credenciales | Credenciales copiadas en configuraciones y agentes que actúan como cualquiera |
| Permisos por herramienta | Qué rol puede usar qué herramienta y con qué límites de uso | Un agente de consulta que también puede escribir |
| Herramientas fijadas | Cualquier cambio en la definición de una herramienta se detecta, se compara y espera aprobación | El «rug pull» silencioso |
| Auditoría que no se puede alterar | Un registro de quién hizo qué, con qué permiso y cuándo | Reconstruir un incidente a base de recuerdos |
| Aislamiento estricto | Separación entre clientes y funcionamiento en redes aisladas | Que un error en un entorno alcance a otro |
| Aprobación humana donde importa | Las acciones sensibles esperan a que una persona las apruebe | Un borrado irreversible decidido solo por el modelo |
Ninguno de estos principios es nuevo. Son los que ya aplicas a las personas que entran en tus sistemas: identidad, mínimo privilegio, cambios aprobados y registro. Lo nuevo es aplicarlos a un actor que trabaja a velocidad de máquina, no se cansa y hace exactamente lo que le sugiere la descripción de la herramienta.
El último principio no tiene que esperar a ninguna herramienta nueva. Ya lo aplicamos en nuestros productos: cuando un asistente de IA opera NovaeOps por MCP, las operaciones que borran algo piden confirmación expresa. La IA propone; una persona aprueba.
¿Qué piden el ENS, DORA y el AI Act?
Ninguna de las tres normas habla de MCP, pero todas empujan en la misma dirección: control de accesos, trazabilidad y capacidad de reconstruir lo que ha pasado. Si tus agentes van a tocar sistemas de una entidad pública o de una entidad financiera, o van a formar parte de un sistema de IA de alto riesgo, te lo van a pedir.
El calendario da margen, y conviene usarlo bien:
- Las obligaciones del AI Act para los sistemas de alto riesgo se han retrasado a diciembre de 2027 y agosto de 2028.
- España todavía no ha transpuesto NIS2, y la Comisión Europea la ha llevado al Tribunal de Justicia de la UE (julio de 2026).
- El ENS alcanza también a los proveedores que desarrollan u operan sistemas que tratan información de una entidad pública (RD 311/2022, art. 2).
No es un argumento de urgencia, sino de preparación. Añadir trazabilidad a un sistema que ya está en producción cuesta más que diseñarla desde el principio, y un registro de auditoría solo sirve si existía antes del incidente.
¿Qué es Praesidix y en qué estado está?
Praesidix, la puerta de control de tus agentes de IA, es la pasarela de gobierno que estamos diseñando para agentes que usan herramientas por MCP. Está en laboratorio y todavía no tiene software: hemos terminado el estudio de mercado y de normativa, y el siguiente paso es un prototipo.
Cuando exista, Praesidix se sentará delante de tus servidores MCP y decidirá quién puede usar qué herramienta, con qué identidad y con qué límites. Validará la identidad con tu proveedor (OIDC) sin reenviar credenciales, fijará la definición de cada herramienta y retendrá cualquier cambio hasta que lo apruebes. Dejará un registro de auditoría que no se podrá alterar, pensado para lo que piden el ENS, DORA y el AI Act, y funcionará también en redes aisladas.
Tendrá tres perfiles de seguridad: local, empresa y alta seguridad. Y conviene decir lo que no será: ni un proveedor de identidad, ni una malla de servicios, ni un API gateway genérico, ni un proxy de modelos de lenguaje. Se apoyará en tu proveedor de identidad y convivirá con tu gateway.
Buscamos organizaciones que vayan a poner agentes a trabajar con sistemas reales para diseñarlo con ellas, sobre todo en sectores regulados: banca y seguros, infraestructuras y entornos de alta seguridad.
¿Qué puedes hacer hoy para gobernar tus agentes?
No hace falta esperar a ninguna herramienta para empezar:
- Haz inventario. Qué agentes tienes, qué servidores MCP usan y qué herramientas exponen.
- Separa leer de escribir. Un agente de consulta no necesita herramientas que modifican.
- Guarda lo que apruebas. Anota la definición de cada herramienta el día que la apruebas y revísala cuando cambie.
- Saca las credenciales de los ficheros de configuración. Cada agente, con su identidad y los permisos mínimos.
- Pide aprobación humana para lo que no tiene vuelta atrás.
- Centraliza los registros antes de necesitarlos.
Si los agentes van a usar también tus propias herramientas, en IA y experiencia de desarrollador contamos cómo diseñar tu CLI y tu API para ellos sin perder el control humano de lo sensible.
¿Por dónde empiezas?
Por el inventario, y por decidir qué acciones no debe tomar nunca un agente sin una persona delante. Si tu organización va a poner agentes a trabajar con sistemas reales, diseñemos Praesidix juntos.