Un artículo afilado de API7.ai (el equipo detrás de Apache APISIX) plantea algo que todo equipo que construye agentes debería interiorizar: cuando un agente de IA accede a un servidor MCP, no gana solo una fuente de datos de solo lectura. Puede ganar la capacidad de crear tickets, cambiar infraestructura, consultar registros de clientes o disparar flujos de negocio. Tratar esa conexión como un permiso binario «conectado / desconectado» es un control de acceso demasiado grueso para producción.
La idea central: mínimo privilegio en la capa MCP. Expón solo las herramientas que el agente necesita para su rol, impide que descubra las que no puede usar, revalida el permiso en cada invocación y asegúrate de que añadir un servidor nuevo nunca amplíe el acceso existente de forma silenciosa.
Hay que gobernar dos cosas, no una:
- Descubrimiento (
tools/list). Una lista de herramientas sin restricciones filtra nombres de sistemas internos, flujos y acciones de alto riesgo, aunque luego se denieguen las llamadas. Filtrar la lista también mejora el comportamiento del agente: el modelo elige de un conjunto menor y relevante en vez de razonar sobre herramientas que nunca podrá usar. - Invocación (
tools/call). Filtrar no es autorizar. Un cliente puede construir una petición directamente sin elegir de la lista, así que cada llamada debe revalidarse contra el permiso efectivo del solicitante. Si no está permitida, el gateway devuelve un error neutro y nunca contacta con el upstream — sin revelar siquiera si la herramienta existe.
Principios de diseño que merece la pena copiar:
- Identidades de herramienta con espacio de nombres (p. ej.
github__create_issue), para no confundir unsearchde un servidor con el de otro. - Fail closed: sin permisos, sin acceso a herramientas, por defecto.
- Nombres exactos para operaciones sensibles; los comodines (
github__*) son cómodos pero también otorgan herramientas *futuras* bajo ese patrón. - El deny siempre gana, y una clave puede acotar un permiso heredado, nunca ampliarlo.
- Gobierna qué servidores pueden publicarse — separa proponer un servidor de aprobarlo, con eventos de auditoría en cada cambio.
Por qué importa. Es el problema del *confused deputy* a escala empresarial. A medida que los agentes encadenan herramientas y generan subagentes, «conectado» no es control de acceso, es solo conectividad. Filtrado del descubrimiento, autorización por llamada, espacios de nombres y un deny que nadie puede sobrescribir son lo que convierte MCP de una integración cómoda en una gobernada.
Cómo ayuda CloudAPPi. Nuestras prácticas de MCP Governance y Agent Governance ponen exactamente estos controles delante de tus agentes: acceso a herramientas acotado y de mínimo privilegio; autorización por llamada en el gateway; identidades con espacio de nombres; flujos de revisión de servidores; y trazas de auditoría de cada permiso e invocación — para que tus agentes hagan solo lo que su rol permite.
¿Desplegando MCP en producción? Contacta con CloudAPPi — hagamos que el mínimo privilegio sea lo normal.
