Cuando conecta un cliente de IA a Atlas mediante el acceso delegado por el usuario, el cliente de IA actúa en su nombre utilizando su propia identidad de Atlas. Esta página explica cómo funciona esa autorización, a qué puede y no puede acceder el cliente de IA y cómo se mantienen protegidas sus credenciales.
Para aprender cómo un Organization Owner habilita el acceso, configura los modos de acceso y audita la actividad del cliente de IA, consulte Administrar el acceso del cliente de IA a su organización.
El servidor MCP remoto implementa la versión 2025-11-25 de la especificación del protocolo de contexto del modelo. Como parte del protocolo, el acceso delegado por el usuario utiliza el OAuth 2.1 Flujo de código de autorización con clave de prueba para intercambio de código (PKCE).
Identidad y permisos
El cliente de IA actúa bajo tu identidad de Atlas, utilizando tu rol de Atlas existente. El cliente de IA no puede exceder los permisos que ya tienes. Si tu rol no permite realizar una acción, el cliente de IA no podrá llevarla a cabo en tu nombre.
No puede delegar un subconjunto de sus permisos. Cuando autoriza a un cliente de IA, este actúa con sus permisos existentes completos, sujeto a la moda de acceso que configure su Organization Owner. Para obtener información sobre las moda de acceso, consulte moda de acceso de cliente de IA.
Atlas atribuye todas las acciones que un cliente de IA realiza a usted en el registro de auditoría. Los eventos del registro de auditoría de la organización registran tanto su ID de usuario como el ID del cliente de IA que realizó la solicitud. Para saber cómo Atlas registra la actividad del cliente de IA en su registro de auditoría, consulte Administrar el acceso del cliente de IA a su organización.
Aislamiento de credenciales
Atlas nunca comparte sus credenciales con el cliente de IA. Durante el flujo de conexión, se autentica directamente con Atlas en su navegador. El cliente de IA nunca recibe su contraseña de Atlas ni credenciales de larga duración.
Después de autorizar la conexión, Atlas gestiona los tokens que utiliza la conexión. La actualización de tokens es automática. No gestiona una cadena de conexión ni un secreto.
Aislamiento de la conexión del plano de datos
Para conectarse a tus datos, Atlas utiliza credenciales de corta duración que llevan tu identidad individual. Atlas crea estas credenciales solo para la conexión del plano de datos.
Los detalles de la conexión de la base de datos nunca se exponen al cliente de IA. El cliente de IA interactúa con sus datos solo a través de las herramientas disponibles en su moda de acceso configurado.
La capacidad de un cliente de IA para conectarse a sus clústeres depende de sus propios permisos de Atlas. Para saber qué roles de Atlas reciben acceso a la base de datos a través de un cliente de IA, consulte Roles de usuario y acceso a la base de datos.
La revocación del acceso también finaliza el acceso al plano de datos en la misma línea de tiempo. El cliente de IA debe presentar un token de acceso válido para llamar a cualquier herramienta. Cuando el token de acceso caduca y el token de actualización ya no funciona, el cliente de IA no puede acceder a tus datos, incluso si sus credenciales de base de datos aún no han caducado.
Vida útil y revocación del acceso
El acceso de un cliente de IA en su nombre finaliza después de 7 días de inactividad o 30 días desde que concedió el acceso, independientemente de la actividad. Cuando finaliza el acceso, debe autenticarse de nuevo para volver a conectar el cliente de IA. Los Organization Owners pueden reducir la vida útil máxima del token para la organización.
Puedes revocar el acceso de un cliente de IA en cualquier momento desde la interfaz de usuario de Atlas. Revocar el acceso invalida el token de actualización del cliente de IA, pero el token de acceso actual del cliente sigue siendo válido hasta que caduque, hasta 10 minutos después. Cuando el Organization Owner de una organización desactiva el acceso del cliente de IA para la organización, el acceso al plano de control finaliza inmediatamente, ya que Atlas comprueba si el acceso está habilitado en cada llamada a la API de administración.
Anotaciones de herramientas y operaciones destructivas
Cada herramienta de servidor MCP de MongoDB contiene anotaciones que describen lo que hace la herramienta. Los clientes de IA pueden utilizar estas anotaciones para decidir cómo presentarle una herramienta, por ejemplo, si deben preguntar antes de ejecutarla.
Las dos anotaciones relevantes para la seguridad son:
readOnlyHint: cuandotrue, indica que la herramienta no cambia ningún dato ni configuración.destructiveHint: cuandotrue, indica que la herramienta puede remover o sobrescribir datos o configuraciones existentes.
El servidor MCP deriva ambas anotaciones del tipo de operación de la herramienta:
Tipo de operación | readOnlyHint | destructiveHint | Herramientas de ejemplo |
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
Advertencia
Las anotaciones de herramientas no son un límite de seguridad
Las anotaciones de herramientas como destructiveHint y readOnlyHint son metadatos consultivos que el servidor MCP envía al cliente de IA. No autorizan, restringen ni bloquean ninguna operación, y un cliente de IA puede ignorarlas. No confíe en las anotaciones para evitar cambios no deseados.
Para limitar lo que un cliente de IA puede hacer en su nombre, conceda solo los permisos de Atlas que requiere la tarea del cliente de IA. Para obtener información sobre los roles de Atlas, consulte Atlas User Roles.
Herramientas no destructivas y sensibles a la seguridad
create las herramientas informan destructiveHint como false porque dichas herramientas agregan recursos en lugar de remover o sobrescribir recursos. Sin embargo, algunas herramientas create aún cambian su postura de seguridad. Por ejemplo:
atlas-create-access-listaumenta la exposición de su clúster al agregar entradas a la lista de acceso IP de un proyecto. Una entrada como0.0.0.0/0expone el clúster a todas las direcciones IP.atlas-create-db-usercrea un usuario de base de datos que puede leer o guardar datos, según los roles que se le otorguen.
Evalúa una herramienta en función de lo que cambia, no del valor de destructiveHint.
Confirmación de la intención
Para algunas herramientas, el servidor MCP te pide que confirmes la operación antes de que se ejecute la herramienta. MongoDB llama a este proceso elicitation. El cliente de IA muestra el mensaje de confirmación y, si lo rechazas, el servidor MCP devuelve un error y no realiza la operación.
La confirmación depende de que el cliente de IA admita la capacidad de obtención de MCP. Si el cliente de IA no admite la obtención, el servidor MCP ejecuta la herramienta sin pedirle que confirme. No asuma que aparece un mensaje de confirmación antes de que se ejecute una operación arriesgada.
Qué límites tiene una herramienta
Los permisos, no las anotaciones, determinan lo que un cliente de IA puede cambiar con sus herramientas. Los permisos se determinan mediante:
su rol de Atlas
nivel de acceso de cliente de IA de su organización
Una herramienta falla si no tiene los privilegios que requiere la operación, independientemente de las anotaciones de la herramienta o de las solicitudes de confirmación.
Dado que no puede delegar un subconjunto de sus permisos, un cliente de IA que actúe en su nombre puede acceder a cualquier cosa que su rol permita. Tenga esto en cuenta cuando tenga un rol con amplios privilegios, como Project Database Access Admin o Project IP Access List Admin. Estos roles permiten las herramientas descritas en la sección anterior.
Para obtener información sobre los roles de Atlas, consulta Atlas User Roles.
Si conecta un agente automatizado con acceso programático, el agente actúa como una cuenta de servicio en lugar de como usted. Limite cada configuración de MCP solo a los roles que requiere el flujo de trabajo del agente y mantenga la configuración de solo lectura a menos que el agente deba guardar. Una configuración de solo lectura evita que los agentes de IA vean las herramientas de escritura, lo que la convierte en un control de acceso eficaz.
Herramientas con etiquetas de lectura que pueden realizar guardados
Advertencia
Algunas herramientas con etiquetas de lectura pueden guardar
aggregate, aggregate-db y export son herramientas read que informan readOnlyHint: true. Estas herramientas ejecutan pipeline de agregación que pueden incluir una etapa $out o $merge, las cuales escriben los resultados del pipeline en una colección. operationType: "read" no garantiza que una herramienta deje sus datos sin cambios.
Alcance del riesgo
La etapa $merge de un pipeline de agregación puede guardar en una base de datos o colección diferente de la que lee el pipeline. La opción into de la etapa $merge acepta {db: <database>, coll: <collection>}. La escritura puede dirigirse a cualquier base de datos o colección a la que pueda acceder la identidad de Atlas del cliente de IA, más allá de lo que el cliente de IA parece estar consultando.
Una etapa $out sobrescribe por completo el contenido de la colección de destino si la colección de destino ya existe.
Mitigaciones
No todas las pipeline de agregación dan como resultado una guardar. La ejecución de una pipeline de agregación que produce guardar requiere:
Una sesión autenticada: su propia sesión bajo acceso delegado por el usuario o las credenciales de una cuenta de servicio bajo acceso programático.
Acceso al proyecto: la identidad de Atlas del cliente de IA debe concederle acceso de escritura al proyecto de destino. Para el acceso delegado por el usuario, este es su propio rol de Atlas. Para el acceso programático, estos son los roles de Atlas asignados a la cuenta de servicio.
Estas condiciones reducen el riesgo, pero no lo remueven. Una política que concede acceso a aggregate, aggregate-db o export basándose únicamente en la etiqueta read puede conceder involuntariamente acceso de guardar al cliente de IA.
aggregate permanece disponible incluso cuando el modo de acceso de un cliente de IA o el rol de una cuenta de servicio es de solo lectura. Sin embargo, la escritura sigue fallando: si el rol de una cuenta de servicio es de solo lectura, o el modo de acceso de su organización está configurado en solo lectura para el acceso delegado por el usuario, una etapa $out o $merge en el pipeline no puede completarse porque la conexión no tiene permiso de guardar.
El servidor MCP también activa un mensaje de confirmación cuando un pipeline de agregación contiene una etapa $out o $merge. El cliente de IA muestra el mensaje y te pide que confirmes que se guarde antes de que se ejecute el pipeline. Esta confirmación depende de que el cliente de IA admita la obtención. Si el cliente de IA no admite la obtención, el servidor MCP ejecuta el pipeline sin pedirte que confirmes.
Reducción del riesgo
Conceda a los clientes de IA y a las cuentas de servicio solo los roles de Atlas que requiera su flujo de trabajo. Un rol de solo lectura evita que
aggregateescriba a través de una etapa$outo$merge.Utilice un cliente de IA que admita la obtención, de modo que el servidor MCP pueda solicitar su consentimiento antes de ejecutar una pipeline de agregación que produzca guardar.
Para el acceso delegado por el usuario, un Organization Owner puede establecer el modo de acceso de su organización en solo lectura en lugar de lectura y escritura. Esto evita guardar a través de
aggregatepara cada cliente de IA de su organización.Para el acceso programático, mantenga la configuración de MCP de la cuenta de servicio de solo lectura a menos que el flujo de trabajo del agente requiera guardar. Esto evita guardar a través de
aggregatede la misma manera.
Obtén más información
Para obtener información sobre los artefactos de seguridad retenidos y la orientación para usuarios federados, consulta Descripción general de las conexiones de aplicaciones de Atlas.