Proteger un servidor MCP de empresa se reduce a tres preguntas, respondidas en orden. ¿Quién puede siquiera conectarse? Eso es OAuth. ¿A qué puede llegar un cliente conectado? Eso es el aislamiento por espacio de trabajo. Y de lo que es alcanzable, ¿quién ve qué parte? Eso es el alcance: privado frente a público, y los puestos. Acierta con las tres y «hemos expuesto el conocimiento de la empresa a clientes de IA» deja de ser una frase que asusta. Falla en una, y las otras dos no te salvan.

Esto es lo que significa cada capa en la práctica, y qué comprobar en cualquier plataforma que aloje un servidor MCP por ti.

Capa 1: OAuth 2.1, según la especificación vigente

MCP adoptó OAuth 2.1 para la autorización, y la palabra vigente hace trabajo de verdad en esa frase. La especificación se ha movido, y las revisiones recientes han cerrado agujeros reales. Hay dos elementos que merece la pena conocer por su nombre aunque nunca los implementes tú mismo.

La validación del emisor (iss) significa que el cliente verifica que una respuesta de autorización procede realmente del servidor de autorización con el que empezó. Sin ella, un servidor malicioso puede jugar a ser intermediario —los llamados ataques de confusión o mix-up— y llevarse un código destinado a otro. Aburrido, esencial y fácil de saltarse si lo implementas a mano.

Los Client ID Metadata Documents (CIMD) son la forma en que los clientes se identifican ante tu servidor. En lugar de que cada cliente MCP se preregistre en cada servidor MCP —algo que no escala más allá de una demo—, el cliente presenta una URL que lo describe, y el servidor obtiene y verifica esos metadatos. Es la pieza que permite que tu servidor funcione con Claude y con clientes MCP de los que aún no has oído hablar, sin un registro abierto sin control.

SuperCognit implementa ambos, según la especificación vigente, en todos los servidores publicados. Si estás evaluando cualquier producto MCP alojado, pregunta específicamente por estos dos. «Soportamos OAuth» es una respuesta de 2023 a una pregunta de 2026.

Capa 2: aislamiento por espacio de trabajo

La autorización decide quién entra por la puerta. El aislamiento decide qué hay detrás de la puerta. Cada servidor MCP de SuperCognit está acotado a su espacio de trabajo: sus bases de conocimiento, sus herramientas, sus suscriptores. Un token del servidor de un espacio de trabajo no vale nada en el de otro, y no existe consulta, por creativa que sea, que recupere los documentos de un vecino: la frontera es estructural, no un filtro aplicado en el momento de responder.

Esto importa más de lo que parece. Los sistemas de recuperación responden desde cualquier corpus en el que puedan buscar. Si la frontera del corpus es blanda —un ID de tenant en un filtro de consulta, por ejemplo—, la seguridad de cada respuesta descansa en que nadie escriba jamás una consulta mala. Una frontera dura por espacio de trabajo significa que el fallo interesante no es posible, en lugar de meramente improbable.

Capa 3: quién ve qué

Con el perímetro y los muros en su sitio, las decisiones que quedan son tuyas, y son de política, no de ingeniería:

  • Privado: el servidor es un cerebro interno de la empresa —procedimientos, políticas, datos de producto—, accesible solo para tu propio equipo. El valor por defecto correcto para todo lo que no pondrías en tu web.
  • Público: cualquiera puede conectarse. Adecuado para documentación, datos de producto y todo aquello sobre lo que quieres activamente que los clientes de IA respondan correctamente en tu nombre.
  • De pago: público, pero detrás de una suscripción por puesto. Las suscripciones de Stripe, las facturas y los pagos vienen integrados, con SuperCognit como merchant of record. Un puesto es una primitiva de control de acceso con un precio: revoca el puesto y el acceso se va con él.

La disciplina útil es decidir primero el nivel y después el contenido. Un servidor que mezcla datos públicos de producto con contactos internos de escalado en una sola base de conocimiento ya ha cometido su peor error, tenga el OAuth que tenga.

Qué te aporta esto en el día a día

Un empleado conecta el servidor de la empresa en Claude, autoriza una vez y pregunta cómo funciona el proceso de excepciones de reembolso. Un cliente en el servidor público pregunta qué incluye cada plan, y no puede llegar a los procedimientos internos, porque los procedimientos viven en otro servidor con otro alcance, no detrás de un prompt que dice «por favor, no los menciones». El control de acceso por arquitectura gana al control de acceso por instrucción. Los modelos siguen bien las instrucciones, pero «bien» no es una frontera de seguridad.

Nada de esto ha requerido que tu equipo opere un servidor de autorización, rote claves o lea el registro de cambios de la especificación. Ese es el argumento honesto: las capas de seguridad de un MCP de empresa son exactamente la parte que quieres que sea aburrida, estándar y el trabajo a tiempo completo de otro.