Los servidores MCP conectan agentes con herramientas reales: tickets, nubes, bases de datos, código. Sin gobierno, eso es privilegio persistente con un chat por delante.
El riesgo no es el modelo, es la tool
Un agente bien alineado todavía puede:
- Llamar una tool con más alcance del que el humano tenía.
- Encadenar lecturas y escrituras que nadie revisó.
- Dejar secretos en el contexto de la conversación.
El control tiene que vivir en el servidor MCP y en el gateway, no en el prompt.
Tres controles que pedimos en cada MCP
- Identidad de la organización en cada llamada (tenant, no un API key global).
- Allowlist de tools por agente y por entorno (staging no es producción).
- Trazas de quién pidió qué, con qué argumentos y qué respondió el sistema.
Si no puedes reconstruir una sesión, no puedes auditarla. Y si no puedes auditarla, no pasa un due diligence.
Patrón que funciona en equipos pequeños
Empieza estrecho:
- Un servidor MCP por dominio (tickets, cloud, repo), no un “super-MCP”.
- Credenciales de corta vida, nunca en el system prompt.
- Un humano aprueba escrituras de alto impacto (borrar, pagar, cambiar IAM).
Cuando eso está estable, recién aíslas agentes por equipo. Ver el directorio de MCP servers ayuda a no reinventar conectores que ya existen.
Señal de que el gobierno está fallando
El agente puede listar y también ejecutar.
Nadie sabe qué tools están habilitadas en prod.
Las trazas viven solo en el proveedor del modelo.
Si reconoces dos de tres, el siguiente incidente no va a ser un jailbreak creativo: va a ser una tool con más permiso del necesario.
El gobierno de MCP no es un overlay de marketing. Es el mismo problema de identidad y evidencia que ya conoces en cloud, aplicado a agentes.