Asegurar el acceso a datos con permisos detallados en repositorios MCP

Locking down data in Model Context Protocol (MCP) isn’t optional anymore—it’s the backbone of any serious deployment.

Por qué los repositorios MCP necesitan permisos detallados

Los repositorios del Model Context Protocol actúan como puertas entre los modelos y los datos reales: bases de datos, almacenes de documentos, APIs internas, grafos de conocimiento y más. Ese poder corta en ambas direcciones:

Un repositorio demasiado abierto filtra datos sensibles al contexto del modelo.
Un repositorio demasiado estricto se vuelve inutilizable para flujos de trabajo reales.
Un repositorio de grano grueso te obliga a elegir entre “todo” o “nada”.

Los permisos finos son la respuesta: la capacidad de describir exactamente quién puede acceder a qué datos, a través de qué herramientas, bajo qué condiciones, y con qué visibilidad en el contexto del modelo.

En un despliegue MCP que sirve a varios equipos, tenants o productos, esto marca la diferencia entre:

Una interfaz segura y auditable, y
Un quebradero de cabeza de cumplimiento donde prompts muestran accidentalmente tablas de nóminas en un flujo de soporte.

Este artículo se centra en el diseño a nivel de repositorio: cómo incrustar permisos finos en la capa de acceso a datos que exponen las herramientas MCP.

Modelo de amenazas: contra qué te estás defendiendo realmente

Antes de definir cualquier sistema de permisos, vale la pena explicitar el modelo de amenazas. En el contexto MCP, piensa en las amenazas como:

Exposición excesiva de herramientas
- Herramientas que pueden consultar tablas o endpoints irrelevantes para el trabajo del usuario.
- Operaciones tipo “buscar todo” sin filtrado a nivel de fila.
Sobrecompartición en el contexto
- Incluso si se permite una consulta, el resultado puede contener:
  - PII (correos, teléfonos)
  - Datos financieros
  - Información sanitaria
  - Roadmaps internos
- Una vez que esto entra en el contexto del modelo, lo has divulgado efectivamente a todas las operaciones descendentes, incluidos logs y trazas.
Patrones de acceso indirecto
- Encadenamiento de prompts o herramientas donde:
  - La herramienta A devuelve un identificador
  - La herramienta B (menos restringida) usa ese identificador para obtener detalles sensibles
- Ejemplo: “Encuentra un empleado aleatorio” → “Obtener registro de RR. HH. de ese empleado.”
Contaminación entre tenants
- Un repositorio multi-tenant sin scoping por tenant:
  - Usuarios ven registros pertenecientes a otros clientes o unidades.
  - Los logs almacenan fragmentos multi-tenant sin límites.
Inyección de prompts y uso indebido
- El propio modelo intenta:
  - Llamar a herramientas más allá de lo que el usuario pretendía.
  - Ampliar las condiciones de consulta para eludir filtros (“select * from users”).
  - Enumerar la estructura interna del sistema.

Un diseño robusto de permisos finos para repositorios MCP aborda todo esto usando una mezcla de política, scoping de contexto, diseño de herramientas y validación en tiempo de ejecución.

Fundamentos: identidad, contexto y política

Los permisos detallados solo funcionan si puedes responder de forma consistente a tres preguntas:

¿Quién está llamando?
Identidad y atributos: usuario, app, tenant, equipo, rol.
¿Cuál es la intención?
Qué herramienta, qué operación, qué parámetros.
¿Cuál es la política?
Reglas que mapean identidades e intenciones a datos permitidos.

Identidad: la columna vertebral de cada comprobación

En un entorno MCP, la identidad debe llegar hasta la capa de repositorio:

Tipos de principal
- Usuarios humanos (operadores, analistas, agentes).
- Cuentas de servicio (automatizaciones, jobs programados).
- Identidades compuestas (usuario + id de workflow + app cliente).
Atributos
- Roles: “support_agent”, “sales_rep”, “data_admin”.
- Ámbito organizativo: “team:billing”, “region:EU”.
- Tenant: “tenant_id:12345”.
- Nivel de acceso: “confidential”, “internal”, “public”.

Para implementar permisos finos, pasa un objeto de identidad estructurado en cada llamada al repositorio, no solo un id de usuario plano. Tu servidor o adaptador MCP debería imponer esto para todas las herramientas.

Política: más allá del control de acceso basado en roles

El clásico RBAC (Role-Based Access Control) no basta por sí solo. Necesitas ABAC (Attribute-Based Access Control) y a veces ReBAC (Relationship-Based Access Control). En la práctica:

Estilo RBAC:
- “Los agentes de soporte pueden usar la herramienta billing_search.”
Estilo ABAC:
- “Los usuarios en la región EU solo pueden acceder a datos de clientes EU.”
- “Los contratistas no pueden ver campos marcados como sensitive:true.”
Estilo ReBAC:
- “El usuario puede acceder a registros de proyecto donde es miembro.”
- “Un manager puede ver registros de sus reportes directos.”

Diseña un lenguaje de políticas o una representación de políticas que pueda describir:

Operaciones: read, write, update, delete, search, export.
Recursos: tablas, colecciones, tipos de documento, APIs.
Filtros: condiciones sobre campos, etiquetas o relaciones.
Nivel de campo: visibilidad de columnas o atributos específicos.

Ejemplos incluyen:

Open Policy Agent (Rego) integrado en la capa de repositorio.
Políticas personalizadas en JSON/YAML interpretadas por un motor de políticas.
Tablas de políticas basadas en SQL que se unen en tiempo de consulta.

Dimensiones de permisos dentro de los repositorios MCP

En la práctica, los permisos finos en repositorios MCP suelen encajar en varias dimensiones clave.

1. Permisos a nivel de herramienta

Cada herramienta MCP es un límite de capacidad. Trata cada herramienta como un perímetro de seguridad.

Lista blanca de qué herramientas pueden llamarse por:
- Rol
- Tenant
- Aplicación cliente
Puedes modelarlo como:
- "allowed_tools": ["customer_search", "ticket_create"] por identidad.
- O como reglas de política: allow_tool(principal, tool_name) = true/false.

Consejos de diseño:

No expongas herramientas genéricas como sql_query sin restricciones fuertes.
Divide herramientas grandes en otras más pequeñas y específicas con huellas de permiso más estrechas.
Prefiere herramientas que incorporen plantillas de consulta seguras en lugar de exponer parámetros de consulta arbitrarios.

2. Permisos a nivel de recurso (datasets, colecciones, tablas)

Dentro de cada repositorio, define recursos lógicos:

Customers, tickets, invoices, documents, logs, etc.
Para cada recurso, adjunta:
- Una etiqueta de clasificación de datos (public, internal, confidential, restricted).
- Una dimensión de tenant (single-tenant vs multi-tenant).
- Un propietario de dominio (equipo, producto o data steward).

Los permisos a este nivel podrían decir:

“Los agentes de soporte pueden read customers dentro de su tenant, pero no invoices.”
“Los ingenieros pueden read logs para depuración pero no las tablas de billing.”

Tu implementación de repositorio debe mapear herramientas a estos recursos lógicos y forzar:

Allow/deny por tipo de recurso.
Filtrado automático por tenant u organización.
Aplicación de reglas basadas en clasificación.

3. Permisos a nivel de fila (scoping de registros y tenants)

Los permisos a nivel de fila son donde se encuentran la autoservicio y la lógica de negocio real.

Patrones típicos:

Aislamiento por tenant
- Cada registro tiene tenant_id.
- Tu repositorio adjunta WHERE tenant_id = principal.tenant_id a cada consulta.
- Las herramientas nunca permiten anular esto.
Basado en propiedad
- Los registros tienen owner_id o team_id.
- Solo los propietarios o sus managers pueden ver/editar.
Reglas específicas del dominio
- “Los agentes de soporte solo pueden ver tickets asignados a su equipo, a menos que sean managers de escalado.”
- “Los representantes de ventas pueden ver cuentas en su territorio.”

Estrategias de implementación:

Enganches del generador de consultas
- Envuelve todo acceso a datos en una capa de repositorio que:
  - Toma la consulta base.
  - Inyecta filtros obligatorios basados en identidad y política.
- Incluso si un modelo intenta ampliar las condiciones, no puede escapar de los filtros impuestos.
Seguridad a nivel de fila nativa de la base de datos (RLS)
- Postgres RLS, políticas de acceso de BigQuery, etc.
- Codifica políticas en el esquema y delega la aplicación en la base de datos.
- Aun así, mantén lógica aware-MCP encima para decisiones dependientes del contexto.

4. Permisos a nivel de columna y campo

A menudo quieres permitir acceso a un registro pero ocultar ciertos campos:

Ocultar PII: email, teléfono, direcciones.
Ocultar métricas financieras o sensibles.
Ocultar etiquetas internas o razones de decisión.

Patrones:

Lista blanca de columnas por rol
- “Los agentes de soporte ven nombre y plan del cliente; no los datos de tarjeta.”
- “Los analistas ven datos agregados de compra, pero no nombres ni emails.”
Enmascaramiento de datos
- Mostrar patrones parciales: ***-***-1234.
- Mostrar campos derivados o anonimizados.
Filtrado semántico
- Marca campos con metadata, p. ej.:
  - sensitivity: pii
  - security_level: high
- Política: “Usuarios con clearance < high no pueden ver campos etiquetados security_level: high.”

Tu repositorio debe:

Mapear campos lógicos a permisos.
Eliminar o enmascarar campos antes de serializarlos en las respuestas de las herramientas MCP.
Asegurar que los logs nunca almacenen valores sin enmascarar para campos restringidos.

5. Permisos a nivel de acción y mutaciones

Hasta ahora nos hemos centrado en lectura. Las escrituras requieren aún más cuidado:

¿Quién puede crear un registro?
¿Quién puede actualizar campos específicos?
¿Quién puede eliminar o archivar?

Ejemplos:

“Solo los admins de facturación pueden ajustar importes de facturas.”
“Los agentes de soporte pueden añadir notas pero no cambiar el plan de cuenta.”
“Las automatizaciones pueden abrir tickets pero no cerrarlos.”

Implementación:

Usa esquemas de mutación finos:
- En lugar de un update_customer genérico que acepta campos arbitrarios, define:
  - update_contact_details
  - update_support_status
  - update_billing_preferences (restringido)
- Cada operación tiene su propia política y validación.
Adjunta restricciones a nivel de campo:
- En escrituras, valida:
  - Campos permitidos para este principal.
  - Rangos de valores o transiciones permitidas (sin eludir las reglas de negocio).

Patrones de diseño para permisos finos en MCP

Con las dimensiones cubiertas, veamos patrones de diseño adaptados a repositorios MCP.

Patrón 1: Contratos de herramienta aplicados por política

Trata cada herramienta MCP como si tuviera un contrato:

Esquema de entrada: qué argumentos acepta.
Esquema de salida: qué devuelve.
Ganchos de política: validaciones y filtros.

Flujo:

El modelo llama a la herramienta con argumentos.
El servidor o middleware MCP resuelve identidad y contexto.
Motor de políticas:
- Valida el uso de la herramienta: permitido o no.
- Reescribe o restringe argumentos (p. ej., imponer filtros de tenant).
Capa de repositorio realiza acceso a datos bajo la política aplicada.
Post-procesado por política:
- Eliminar o enmascarar campos no permitidos.
- Redactar o agregar valores sensibles.

Esto asegura que incluso si el modelo intenta usar mal una herramienta, la pila repositorio+política la mantiene segura.

Patrón 2: Tokens de capacidad incrustados en el contexto

Para flujos más controlados, usa tokens de capacidad:

Antes de ejecutar un workflow, un sistema upstream emite una capacidad:
- “Esta ejecución puede acceder a tickets del tenant 123 en el proyecto A, solo lectura, sin exportación.”
Ese token se inyecta en:
- La sesión MCP.
- El entorno o contexto de identidad de las herramientas.

Tu repositorio:

Trata la capacidad como un límite superior de lo que el modelo puede hacer.
La combina con la identidad del usuario y la política:
- Permisos efectivos = intersección de (permisos del usuario) ∩ (capacidad).

Esto es útil para:

Experiencias LLM embebidas dentro de productos SaaS.
Workflows con alcance definido (p. ej., “ayuda solo con este ticket”).

Patrón 3: Abstracciones de repositorio conscientes de seguridad

Evita exponer clientes de base de datos o clientes HTTP crudos directamente al código de las herramientas. En su lugar, construye una abstracción de repositorio consciente de seguridad:

Métodos como:
- getCustomerById(identity, customerId)
- searchTickets(identity, query)
- listInvoices(identity, filters)

Estos métodos:

Toman identidad y contexto como argumentos obligatorios.
Internamente aplican:
- Scoping a nivel de fila.
- Filtrado a nivel de campo.
- Redacción basada en clasificación.
- Ganchos de auditoría.

Incluso si un desarrollador accidentalmente omite lógica de alto nivel, sigue pasando por este repositorio, que aplica la política.

Ejemplo práctico: repositorio MCP para atención al cliente

Para concretarlo, imagina un asistente MCP para atención al cliente.

Recursos del repositorio

customers
tickets
invoices
knowledge_articles

Roles:

support_agent
support_manager
billing_specialist
system_admin

Diseño de herramientas

Herramientas de ejemplo:

customer_search
ticket_lookup
ticket_update
invoice_summary
knowledge_search

Cada herramienta llama a una capa de repositorio estructurada.

Escenarios de política

customer_search
- support_agent:
  - Puede buscar por email o nombre.
  - Campos devueltos: name, plan, status, country.
  - Campos enmascarados: email parcialmente enmascarado.
  - Campos excluidos: métodos de pago, notas internas.
- billing_specialist:
  - Campos adicionales: billing_status, payment_method_last4.
  - No puede ver: datos completos de tarjeta, información sensible PCI.
ticket_lookup
- Scoping por tenant:
  - WHERE tenant_id = principal.tenant_id.
- A nivel de campo:
  - Redactar campos etiquetados internal_security_note para no-admins.
invoice_summary
- Solo billing_specialist y system_admin pueden llamar a esta herramienta.
- Vista agregada únicamente:
  - Totales de los últimos 12 meses por mes.
  - Sin partidas detalladas ni desglose por cliente salvo autorización específica.
knowledge_search
- Clasificaciones públicas e internas:
  - Artículos public: disponibles para todos los roles.
  - Artículos internal: solo personal interno.
  - Artículos confidential: solo admins y equipos específicos.

El repositorio aplica estas restricciones automáticamente en cada llamada, basándose en identidad y política.

_{Photo by Kevin Ku on Unsplash}

Salvaguardas contra inyección de prompts y abuso de herramientas

Los permisos finos no solo tratan de quién tiene permitido qué. También limitan hasta dónde puede llegar un prompt malicioso o un modelo comprometido.

Técnicas clave:

1. Filtros no anulables

Todos los filtros críticos de seguridad deben ser:

Aplicados en el servidor.
Construidos de forma que:
- La entrada del usuario o del modelo no pueda eliminarlos.
- Como mucho, la entrada del usuario añada filtros más estrictos.

Ejemplo:

Filtro base: tenant_id = 123.
Condición de usuario: status = 'open'.
Combinado: tenant_id = 123 AND status = 'open'.

El modelo nunca ve una vía para eliminar la condición tenant_id.

2. Validación de parámetros y listas blancas

Para cada herramienta:

Valida parámetros rigurosamente:
- Tipos, rangos, enums.
- No permitir fragmentos SQL de libre formato.
Prefiere objetos de consulta estructurados:
- En lugar de where_clause: string, usa:
  - filters: { field: string, operator: 'eq'|'lt'|'gt', value: any }[].
Rechaza:
- Consultas con comodines sin propósito claro.
- Conjuntos de resultados extremadamente amplios (tamaño descontrolado de contexto).

3. Restricciones en tamaño y forma de resultados

Protege tanto la privacidad como el rendimiento:

Cuenta máxima de filas por llamada.
Tamaño máximo total en bytes de la respuesta.
Agregación para resultados grandes:
- Resúmenes en lugar de filas crudas.
- Acceso paginado con controles más estrictos.

Configura estos límites por rol y por herramienta.

Auditoría, registro y forense

Los permisos finos están incompletos sin observabilidad.

Registra, en la capa de repositorio (no en el contexto del modelo):

Identidad del principal (id de usuario, tenant, roles).
Herramienta invocada.
Recurso y tipo de operación.
Resumen alto de filtros (p. ej., “ticket_ids: [123,124]”, “tenant_id: 456”).
Metadatos del resultado:
- Cuenta de filas.
- Nivel de clasificación de los datos devueltos.
Resumen de redacción:
- “X campos enmascarados”, “Y registros filtrados”.

Evita almacenar:

Consultas crudas con parámetros sensibles en los logs.
Resultados completos, especialmente si contienen PII o datos confidenciales.

Usa estos logs para:

Detectar patrones de acceso anómalos.
Validar que las políticas se comportan como se espera.
Soportar auditorías internas y externas.

Repositorios multi-tenant y estrategias de aislamiento

Los repositorios MCP con frecuencia sirven a múltiples tenants o entornos de cliente. La seguridad multi-tenant es donde los permisos finos realmente importan.

Modelos de aislamiento

Aislamiento fuerte (infraestructura por tenant)
- Bases de datos o esquemas separados por tenant.
- Mejor para escenarios de alta sensibilidad.
- El repositorio MCP elige la conexión correcta por tenant.
- Aun así, aplica comprobaciones por tenant como defensa en profundidad.
Aislamiento blando (infraestructura compartida, aislamiento lógico)
- Una sola base de datos, columna tenant_id en cada registro.
- RLS estricto más filtros de política.
- Política más compleja, pero más fácil de escalar.

En ambos modelos:

Considera listas blancas configurables:
- Para cada tenant:
  - Qué herramientas están habilitadas.
  - Qué datasets pueden usar.
  - Qué funcionalidades (p. ej., exportar, búsqueda masiva) están permitidas.
Restringe consultas entre tenants a un nivel fundamental:
- Las herramientas nunca deben aceptar identificadores de tenant como parámetros desde el modelo.
- El tenant se deriva solo del contexto de identidad fiable.

Manejo de clases de datos sensibles: PII, PHI y secretos comerciales

No todos los datos son iguales. Para categorías reguladas o muy sensibles, añade capas extra además del control genérico a nivel de campo.

PII (Personally Identifiable Information)

Marca siempre los campos que sean PII cuando corresponda.
Introduce niveles de acceso:
- Sin acceso
- Acceso enmascarado
- Acceso completo
Construye:
- Variantes de herramientas seguras para PII que nunca devuelvan identificadores completos.
- Reglas de auditoría que resalten patrones de acceso a PII.

PHI (Protected Health Information)

Adopta restricciones más estrictas:
- Denegar por defecto PHI salvo concesión explícita.
- Flujos de acceso de emergencia (break-glass) con registro adicional.
Prefiere acceso agregado o desidentificado en la mayoría de herramientas.

Secretos comerciales e IP interna

Marca documentos internos, repositorios de código o documentos de diseño con:
- classification: confidential_internal.
Asegura:
- Los asistentes externos o orientados al cliente no puedan acceder a estos repositorios.
- Los asistentes internos necesiten concesiones explícitas de política y logging robusto.

Pruebas y verificación del comportamiento de permisos

Un sistema de permisos solo es fiable si puedes probarlo de forma sistemática.

1. Pruebas unitarias de políticas

Para cada herramienta y recurso:
- Simula múltiples identidades y contextos.
- Asegura outcomes de allow/deny.
- Verifica que los filtros y resultados a nivel de campo coinciden con lo esperado.

2. Escenarios de acceso sintético

Crea usuarios de prueba para cada rol y tenant.
Ejecuta cargas de trabajo sintéticas:
- Búsquedas amplias.
- Búsquedas por identificador aleatorio.
- Intentos “¿y si…?”: p. ej., intentar acceder a tenants fuera de alcance.

Inspecciona:

Logs en busca de anomalías.
Esquemas devueltos en busca de fugas.

3. Red teaming y pruebas adversariales de prompts

Usa prompts adversariales destinados a:
- Forzar al modelo a llamar a herramientas restringidas.
- Eludir parámetros de herramientas.
- Enumerar metadata del sistema.
Confirma:
- Que la capa de repositorio y política bloquea llamadas impropias.
- Que el asistente responde “no puedo acceder” en lugar de filtrar datos parciales.

Consejos operativos para la seguridad de repositorios MCP

Resumiendo, varias prácticas operativas mantienen un sistema de permisos finos sostenible.

Centraliza la política
- Mantén una única fuente de verdad para las reglas de acceso.
- Evita dispersar comprobaciones por múltiples caminos ad-hoc.
Versiona las políticas
- Los cambios de política deben:
  - Versionarse.
  - Revisarse.
  - Poder revertirse.
Separación de funciones
- Los propietarios de datos definen clasificaciones de recursos.
- Los equipos de seguridad definen restricciones globales.
- Los equipos de aplicación conectan herramientas al motor de políticas.
Documenta los contratos de las herramientas
- Para cada herramienta, describe:
  - Qué puede acceder.
  - Qué roles pueden usarla.
  - Qué campos expone.
- Mantén esto sincronizado con la implementación.
Monitoriza la deriva
- Compara regularmente:
  - Política prevista (docs, configs).
  - Comportamiento efectivo (logs, resultados de pruebas).

Conclusión: trata los repositorios MCP como infraestructura crítica de seguridad

Los repositorios MCP no son solo capas de conveniencia para obtener datos en los modelos. Son infraestructura crítica para la seguridad que decide qué puede ver, recordar y sobre qué puede actuar el modelo.

Los permisos finos—en herramientas, recursos, filas y campos—son la única forma sostenible de:

Soportar despliegues complejos y multi-tenant.
Respetar requisitos regulatorios y gobernanza interna.
Proteger a usuarios, clientes y a tu organización de fugas de datos.

Diseñando repositorios con identidad explícita, políticas estructuradas, filtros no anulables y auditoría rigurosa, puedes permitir que los sistemas basados en MCP operen con datos reales de producción sin perder el control de quién ve qué, cuándo y cómo.

Enlaces externos

Fine-Grained Access Control for Sensitive MCP Data Apply fine-grained access control with Bedrock AgentCore Gateway … Securing the AI frontier: A CISO’s guide to access control for MCP Securing MCP Server Communications: Beyond Authentication MCP Authorization: Securing Model Context Protocol Servers With …