Gobernanza
Cómo evitamos que Claude filtren datos de clientes: un gateway MCP para MongoDB
· 5 min read · Fabián Almenara
Conectar el MCP oficial de MongoDB a Claude o ChatGPT permite que el modelo devuelva el domicilio y la facturación de cualquier cliente. En Cubicup, una empresa B2C, lo resolvimos con un gateway propio entre el cliente MCP y la base de datos: todo está denegado por defecto y solo se expone lo que un caso de uso necesita. La idea central: el control de acceso a datos no se delega en el modelo ni en un tercero, se decide en una capa que conocemos y mantenemos nosotros.
El problema: un MCP que ve toda la base de datos
El conector oficial de MongoDB convierte a Claude o ChatGPT en un cliente más de tu base de datos. Si conectas una cuenta con acceso a todas las colecciones, el modelo puede responder a "¿dónde vive este cliente?" o "¿cuánto le hemos facturado?" con los datos reales. Para una empresa B2C, eso es dar a cualquier empleado con acceso al MCP una ventana a los datos personales de los clientes.
La propia documentación de MongoDB deja varias cosas claras sobre el servidor MCP (MongoDB, buenas prácticas de seguridad):
El modo de solo lectura no viene activado por defecto: el servidor permite escrituras en el clúster salvo que lo configures.
El servidor no incluye autenticación ni autorización de entrada. Debes añadirlas tú, normalmente con un proxy delante.
Si el agente se autentica con una credencial propia, solo se identifica al agente, no a la persona. No hay forma de auditar quién hizo qué.
El análisis de Strac añade tres matices técnicos que importan para datos de clientes:
Una consulta sin proyección devuelve el documento completo, con todos sus campos anidados. No hay filtro de campos en el camino.
El servidor llega también al plano de control de Atlas (usuarios, listas de IP, clústeres), no solo a los datos.
Una agregación con
$outo$mergeconvierte una lectura en una escritura, y un$lookuppuede traer datos de colecciones que no esperabas.
Ninguno de esos puntos se arregla con un buen prompt. Hay que resolverlos en la capa de acceso.
Construir en lugar de comprar
Existen gateways comerciales para esto, y varios hacen un buen trabajo. Aun así, como CTO no quiero dejar en manos de un tercero el punto exacto por el que pasan los datos de nuestros clientes si puedo tener el control.
Lo evaluamos y salió a favor de construirlo por dos motivos:
Es sencillo de crear. La infraestructura necesaria es pequeña.
El soporte es mínimo. Una vez en marcha, mantenerlo cuesta poco.
Además conocemos nuestra infraestructura y nuestros datos. Eso es justo lo que decide qué campos son seguros de exponer, y ningún producto genérico lo sabe por nosotros.
Arquitectura
El gateway se coloca entre el cliente de IA y la base de datos. Nadie consulta MongoDB directamente a través del MCP: cada consulta pasa por el gateway, que decide qué colecciones y qué propiedades de cada documento se pueden ver.
[embed: node/ddde9126-a2a8]
Las lecturas del cliente de IA pasan siempre por el gateway y solo llegan a MongoDB con los campos aprobados. Las escrituras no viajan por ese canal: se hacen a través de nuestra API, donde los permisos son mucho más granulares.
Principios de diseño
1. Todo denegado, se abre poco a poco. Partimos de cero: ninguna colección ni campo es visible. Cada propiedad se añade cuando un caso de uso real la necesita. Un campo nuevo en la base de datos no llega al modelo sin una decisión explícita.
2. La proyección también se aplica a filtros y pipelines. Ocultar un campo en el resultado no basta: si el modelo puede filtrar o agrupar por él, deduce su valor sin verlo (por ejemplo, preguntar por los clientes cuyo nombre sea "X"). Por eso las reglas de campos permitidos se aplican igual a las consultas y a las agregaciones, no solo a lo que se devuelve.
3. Exposición según el caso de uso, con IDs tokenizados. No existe una única vista de "cliente". Cada caso de uso recibe los campos que necesita. Cuando hace falta analizar o cruzar datos, el modelo trabaja con un ID tokenizado: puede contar, agrupar y comparar sin saber quién es el cliente.
4. Acceso por usuario. El MCP no está activo para toda la organización. Cada persona necesita permisos concretos para usarlo.
5. Solo lectura. Por este canal solo existen operaciones de lectura. Cuando un flujo con MCP necesita escribir, lo hace a través de nuestra API, donde controlamos los permisos con una granularidad mucho mayor.
Un caso real: la tarea programada en Claude Desktop
El enfoque de denegar por defecto se probó pronto con un caso real. Al programar una tarea en Claude Desktop para un caso de uso concreto, el equipo vio que le faltaban algunos datos. En lugar de abrir una colección entera, activamos solo los campos que esa tarea necesitaba.
Así funciona el modelo en la práctica: la necesidad aparece en un caso de uso, se evalúa qué datos exige de verdad y se habilita lo mínimo. El perímetro crece por demanda justificada, no por comodidad.
Límites y lo que sigue abierto
Un gateway reduce la superficie de exposición, no la elimina. Hay tres puntos que conviene vigilar:
Campos de texto libre. Una nota o un comentario puede contener datos personales aunque el campo no parezca sensible. Se habilitan con el mismo criterio que cualquier otro.
Logs y exportaciones. Según MongoDB, los registros del servidor MCP pueden incluir patrones de consulta y detalles de error, y las exportaciones pueden contener registros reales. Hay que protegerlos como datos sensibles.
Campos que se quedan abiertos. Un campo habilitado para un caso de uso puntual debe revisarse cuando ese caso deja de usarse.
[Añadir: qué registramos de cada consulta y cada cuánto revisamos los campos expuestos.]
Conclusiones
Tres ideas que me llevo de esta experiencia:
Deniega por defecto. Es más fácil justificar cada campo que abrirlo por comodidad y tener que cerrarlo después.
Aplica las reglas a las consultas, no solo a los resultados. Si el modelo puede filtrar o agrupar por un campo oculto, ese campo no está realmente oculto.
Controla la capa que decide. Con una infraestructura pequeña y soporte mínimo, tener esa capa en casa es asumible y deja la decisión sobre los datos de los clientes en manos de quien los conoce.
Este enfoque está alineado con los principios de minimización de datos (art. 5 del RGPD) y de protección de datos desde el diseño (art. 25): cada caso de uso recibe solo lo que necesita.
Referencias
Consultadas el 15 de octubre de 2026.
MongoDB, Security Best Practices del MongoDB MCP Server (documentación oficial).
Strac, MongoDB MCP Server: Secure Setup for Claude & AI Agents (análisis de riesgos; Strac comercializa una solución propia de gobierno de acceso).
mcp · ia · seguridad · gdpr