Modelo de seguridad de MCP
Cómo los servidores MCP de Plur-e gestionan identidad, roles MCP, auditoría y datos — sesiones de Entra ID por usuario, entidades y acciones concedidas por rol, deny-by-absence, registro completo, sin entrenamiento con datos del cliente.
Respuesta rápida
Cada llamada a herramienta se ejecuta con el usuario autenticado (Microsoft Entra ID), así que los permisos de Business Central y Dataverse se aplican sin cambios. Además, cada herramienta queda sujeta a los roles MCP del usuario: sin un rol que conceda la entidad/área y la acción, la llamada deniega al instante — nada queda en cola de aprobación. Todas las llamadas se registran. Los datos del cliente no se usan para entrenar modelos.
Identidad
- Los usuarios inician sesión con Microsoft Entra ID (la misma app registration que el Admin Center). Solo pueden conectarse cuentas que ya existen como usuarios del tenant en el Admin Center; el servidor nunca crea usuarios.
- El tenant se resuelve a partir del token — el tenant de Entra de un usuario debe coincidir con el cliente de Plur-e — nunca a partir de un argumento de la herramienta. El personal de Plur-e y los partners eligen el tenant con
select_tenant. - El servidor llama a Business Central con las credenciales de aplicación de Plur-e, limitadas al environment y compañía que el administrador del tenant configura en el Admin Center (AI & MCP → Settings). Los environments on-premise quedan excluidos salvo que el administrador lo permita.
- El acceso delegado por usuario (que Business Central vea al usuario real) está en la hoja de ruta.
Autenticación de conectores (OAuth 2.1)
mcp.plur-e.com es su propio servidor de autorización OAuth 2.1
(/.well-known/oauth-authorization-server), delante de Microsoft Entra ID, de modo que los
clientes MCP (una plataforma de IA web, un cliente de IA para IDE, un cliente de escritorio de IA, el plugin de Plur-e) pueden conectarse sin
que nadie configure un client id o secret:
- El registro dinámico de clientes (RFC 7591,
POST /oauth/register) está abierto: cualquier cliente puede registrarse y recibir unclient_id. Los clientes registrados son públicos (sin client secret) y deben usar PKCE con S256 en cada petición de autorización. Las redirect URIs deben serhttps://, salvo direcciones loopback (http://localhost/127.0.0.1) para clientes de escritorio y CLI. - El inicio de sesión ocurre contra Microsoft Entra ID con la aplicación propia de Plur-e; el
usuario nunca ve ni maneja el client secret de Plur-e. El servidor de autorización resuelve la
cuenta con la que se inicia sesión a un usuario de Plur-e y emite la conexión bajo el tenant de
ese usuario (o pide al personal y a los partners que llamen a
select_tenant); las cuentas que no existen en el tenant reciben un error claro deaccess_denieden lugar de un token. - Tokens: los tokens de acceso son de vida corta (1 hora); los refresh tokens son opacos, rotan en cada uso (la reutilización se detecta y revoca toda la cadena) y caducan a los 30 días de inactividad o cuando un administrador revoca la conexión.
- Auditoría: el registro, la autorización, la renovación de tokens y la revocación quedan
registrados en el log de auditoría de MCP (acciones
oauth.*); los valores de los tokens nunca se guardan ni se registran. - Los tokens de Entra ID directos emitidos a integraciones ya existentes se siguen aceptando, así que nada de lo que ya se autentica de ese modo necesita cambiar.
Los administradores gestionan los clientes conectados por tenant en AI & MCP → AI connections ("Conexiones de IA") en el Admin Center (ver Conecta tu cliente de IA).
Roles
Cada herramienta declara la entidad (tabla de CRM) o el área (sección de Business Central) que toca y la acción que realiza — Read, New, Update, Delete para CRM; Read, Write, Post para Business Central. Los roles MCP del usuario, asignados en AI & MCP → Roles, deciden si una llamada se ejecuta:
| Destino | Concede | Por defecto |
|---|---|---|
| Business Central | Área × Read / Write / Post | Rol Default access (solo lectura) creado al habilitar Business Central en el tenant |
| Dynamics 365 CRM | Entidad × Read / New / Update / Delete | Rol Default access (solo lectura) creado al verificar una conexión |
Un rol pertenece a un destino — Business Central, o una conexión concreta de CRM — y se
asigna a usuarios concretos; el rol Default access aplica a todos los usuarios del tenant
además de cualquier otro rol que tengan asignado. Sin un rol que conceda la entidad/área y
la acción, la herramienta deniega al instante con un mensaje claro (scope_denied) que
indica qué falta y dónde pedirlo — no hay estado pendiente, ni cola de aprobación, ni
confirmación al usuario. Ver Roles MCP para el modelo completo, las
entidades por defecto y los mensajes exactos de denegación.
Auditoría
Cada llamada registra usuario, herramienta, argumentos (secretos ocultos), resumen del resultado, duración y desenlace. Los registros están disponibles para los administradores del cliente.
Tratamiento de datos
- Los datos fluyen del servidor MCP al cliente (tu asistente de IA) solo para la petición actual.
- el proveedor de IA no entrena con datos de la API por defecto.
El periodo de retención de registros y la lista de subencargados están disponibles bajo petición.
Relacionado: Roles MCP · Seguridad del sitio · Página de producto
Last updated on
Edit on GitHubDocs MCP
Un servidor Model Context Protocol público de solo lectura sobre la documentación de Plur-e con search_docs, get_page y list_sections. Disponible en plur-e.com/api/mcp/docs.
Roles MCP
Cómo los roles MCP controlan lo que tu asistente de IA puede hacer en los servidores de Business Central y Dynamics 365 CRM de Plur-e — entidades, acciones, el rol por defecto y los mensajes exactos de denegación.