Oracle explica cómo controlar el acceso a servidores MCP con OCI IAM

Oracle ha publicado en su blog corporativo una guía titulada Managing Access to MCP Servers with OCI IAM. Explica cómo usar el servicio de identidad de Oracle Cloud Infrastructure para decidir quién se conecta a un servidor MCP y qué puede hacer en él. Salió a finales de esta semana y nos llegó porque seguimos de cerca las noticias sobre Model Context Protocol.

El punto de partida es sencillo. Un servidor MCP local, declarado en `claude_desktop_config.json` o añadido desde Claude Code, corre con los permisos del usuario que lo arranca. Un servidor MCP remoto, en cambio, ofrece sus herramientas por red a cualquier cliente que sepa llegar a él. En ese caso la pregunta ya no es qué hace una herramienta, sino quién tiene permiso para usarla.

Qué plantea Oracle

A juzgar por el título y el contexto, la idea es apoyarse en OCI IAM, el sistema de identidades y accesos de Oracle Cloud, para controlar el acceso a los servidores MCP desplegados en su nube. OCI IAM ya gestiona dominios de identidad, grupos, políticas y federación con proveedores externos. Tiene sentido reutilizar esa capa en vez de que cada servidor MCP monte su propio sistema de usuarios. Para el detalle de la configuración, lo mejor es leer la guía original. Aquí nos interesa más lo que dice este paso de Oracle.

Por qué importa

Desde 2025, la especificación de MCP incluye un sistema de autorización basado en OAuth, pensado precisamente para servidores remotos. En teoría, eso permite que un cliente como Claude consiga un token y lo presente al servidor. En la práctica, a muchas empresas les falta la pieza clave: el proveedor de identidad que emite esos tokens, fija los permisos y guarda un registro para auditoría. Ahí entran los grandes proveedores cloud.

Que Oracle publique guías así apunta a dos cosas. La primera, que hay clientes corporativos desplegando servidores MCP en su infraestructura y preguntando cómo protegerlos. La segunda, que MCP ya no es solo cosa de desarrolladores sueltos y está entrando en los procesos de seguridad de las empresas. Allí las preguntas son otras: quién aprobó un acceso, cómo se retira y qué queda registrado.

A quién le sirve

A los equipos que ya trabajan en OCI y quieren dar a los agentes acceso a herramientas internas sin crear un sistema de autenticación aparte.
A los responsables de seguridad, que necesitan que los accesos de los agentes pasen por las mismas políticas que cualquier otra aplicación.
A los integradores que desarrollan servidores MCP para clientes con obligaciones de cumplimiento normativo.

Si trabajas con otra nube, la idea vale igual: la identidad del agente debe gestionarse en el mismo sitio que el resto de identidades de la organización.

Qué conviene revisar

Sea cual sea el proveedor, en los proyectos MCP que montamos comprobamos siempre unos mínimos:

Que el servidor remoto no acepte peticiones anónimas, ni siquiera en entornos de pruebas abiertos a internet.
Que los tokens den acceso solo a las herramientas necesarias y caduquen pronto.
Que cada uso de una herramienta quede registrado junto a la identidad que lo hizo.
Que haya un procedimiento claro para retirar el acceso a un cliente o a un agente concreto.
Que las herramientas que escriben datos estén separadas de las de solo lectura, cada una con sus propios permisos.

Ninguna de estas medidas es exclusiva de MCP. Son prácticas de seguridad de siempre aplicadas a un cliente nuevo. La diferencia es que ese cliente es un modelo que elige por su cuenta qué herramienta usar, y eso hace más fácil aprovechar un permiso demasiado amplio, aunque sea por accidente.

En ElephantPink creemos que MCP necesitaba documentación así: menos demos y más integración con los sistemas de identidad que las empresas ya auditan. Que la publiquen los proveedores cloud es buena señal de que el protocolo está madurando.