Permisos en MCP: Protege tus herramientas

El error más común en seguridad de servidores MCP es asumir que la autenticación (¿quién sos?) resuelve la autorización (¿qué podés hacer?). No es así. Un agente comprometido que se autentica correctamente tiene acceso a TODAS las herramientas del servidor si no hay scoping por herramienta. Esto se llama el Single Permission Boundary Problem, y es como guardar todas las llaves de la casa en un mismo casillero: si alguien accede a ese casillero, accede a todo (spoiler: eso es un problema gravísimo).

El problema: autenticación no es suficiente

Cuando un equipo asegura su servidor MCP por primera vez, enfoca todo en la puerta de entrada: quién puede conectar. OAuth, API keys, TLS — la capa de autenticación. Se siente completo. Preguntás “¿puede este agente usar este servidor?” y tenés respuesta.

Pero hay una segunda pregunta que nadie hace: “¿Cuáles herramientas en este servidor puede llamar este agente?” Eso es completamente diferente. Conflacionar ambas preguntas es cómo terminás con un agente de investigación que accidentalmente triggerea un deployment a producción (que literalmente pasó en un cliente de Azure hace dos meses según la documentación de Microsoft).

El punto es que la autenticación te dice “está conectado” pero no te dice “puede hacer esto”. Son capas de seguridad separadas.

El Single Permission Boundary Problem explicado

La mayoría de implementaciones de servidores MCP hoy son binarias: un agente se autentica → automáticamente accede a la superficie completa de herramientas. Punto.

Funciona en setup de un solo agente. Se rompe apenas tenés sistemas heterogéneos — arquitecturas donde un agente de investigación, uno de deployment y un data pipeline hablan con el mismo servidor MCP. Complementá con ejecutar agentes sin APIs externas.

Cada uno de esos agentes tiene un trabajo diferente, blast radius diferente, perfil de riesgo diferente. Un agente de research debería poder leer, consultar y resumir. No debería poder pushear código, triggerar deployments o borrar registros. Un agente de deployment probablemente necesita acceso a herramientas de infraestructura. No necesita tocar datos de clientes ni APIs financieras.

Si tu modelo de permisos es “autenticado = acceso total”, acabás de crear un problema de lateral movement por diseño. Un ataque de prompt injection que comprometa un agente de investigación ahora tiene acceso a cada herramienta que expone el servidor. Eso, según el análisis publicado en Dev.to el 4 de abril, es precisamente el patrón que ve la mayoría de equipos hoy.

Autenticación vs Autorización: dos capas de seguridad

Hay que diferenciar bien esto porque es donde la mayoría se pierde.

Autenticación = verificar identidad (OAuth, API keys, TLS, JWT). Responde: ¿quién sos? Autorización = controlar qué puede hacer esa identidad. Responde: ¿qué tenés permitido? Son dos problemas completamente diferentes, y necesitán soluciones diferentes.

El problema es que muchos equipos tratan la autenticación como “suficiente” para autorización. No es. La autenticación te deja entrar al club. La autorización te dice cuáles salones podés visitar dentro del club.

Arquitectura per-tool scoping: roles, manifests y visibilidad

La solución propuesta por el tutorial oficial de MCP y confirmada por análisis independientes tiene tres pilares:

Primer pilar: Role-aware tool manifests. Las herramientas no deberían ser una lista fija e indiscriminada. Deberían ser dinámicas: el servidor, antes de exponer la lista completa de herramientas, filtra según el rol del cliente. Si vos tenés rol “research”, ves read-only tools. Si tenés rol “deployment”, ves infrastructure tools. Si tenés rol “data_pipeline”, ves storage y query tools, punto.

Esto suena simple pero cambia todo. El agente solo ve lo que puede hacer. No ve herramientas y luego trata de usarlas y falla. Solo ve herramientas permitidas. Reducís la superficie de ataque: lo que no ves, no podés tratar de explotar. En análisis de seguridad y privacidad profundizamos sobre esto.

Segundo pilar: Runtime validation. Incluso si por algún motivo un agente logra llamar una herramienta que no debería poder usar (quizás tenés un bug en el filtrado), la validación en tiempo de ejecución lo bloquea. Antes de ejecutar cualquier tool, verificás: ¿este cliente tiene permiso para ESTA herramienta? Si no, retornás PermissionError. Fin de la historia.

Tercer pilar: Centralized role definitions. Los roles se definen una sola vez, en la configuración del servidor, y se aplican consistentemente. No es que cada herramienta tenga su propio sistema de permisos. Todos hablan el mismo lenguaje: roles globales, reglas por rol.

Implementación práctica: validación en tiempo de ejecución

Acá es donde entra lo concreto. Ponele que vos tenés un servidor MCP con herramientas de lectura, escritura y deployment. Vos querés que un agente “research” solo pueda leer. Un “deployer” puede leer y hacer deploy. Un “janitor” solo limpia logs.

Paso 1: definis roles en config del servidor.

Paso 2: usás un JWT con claims que especifique rol y herramientas permitidas. El token podría verse así: `{“sub”: “research-agent-123”, “role”: “research”, “allowed_tools”: [“query_database”, “read_cache”], “exp”: 1712282400}`.

Paso 3: implementás un decorador `@require_scope` en cada herramienta que necesite protección. Antes de ejecutar, el decorador valida contra el token del cliente. Lo explicamos a fondo en herramientas con permisos granulares.

Paso 4: si la autorización falla, no ejecutás nada. Retornás `{“error”: “PermissionError”, “message”: “Tool ‘deploy_to_production’ not allowed for role ‘research'”}`.

Según el análisis de Stytch sobre autenticación y autorización en MCP, esta es la arquitectura recomendada en 2026. Implementarla toma entre 4 y 8 horas en un servidor existente (si ya tenés autenticación en lugar).

Audit logging: la pieza crítica que falta

Acá está el twist:

El scoping de permisos no es verificable sin auditoría. Si vos implementás todo lo anterior pero no loggueás nada, es como poner guardias en la puerta pero no registrar quién entró. Si algo sale mal en producción, no tenés forma de saber si fue un bug del servidor, un agente comprometido, o una herramienta que usó permisos que no debería tener.

¿Qué necesitás loguear? Mínimo:

• Identidad del llamador: quién hizo el request (client ID, agent name, service account, user ID — lo que uses)
• Nombre de herramienta: qué intentó hacer exactamente
• Parámetros: con qué argumentos (útil para detectar patrones de abuso, ojo que acá guardás data sensible, redactá dónde corresponda)
• Timestamp: cuándo
• Resultado: éxito, permiso denegado, error de ejecución

En escala multi-agente, esto pasa de “nice to have” a “obligatorio”. En infraestructura donde coexisten agentes de research y deployment, sin auditoría no tenés forma de diferenciar “el agente se comportó como esperado” de “el agente fue comprometido y abusó de permisos”.

Errores comunes

1. Implementar scoping pero no auditoría

Agregás roles, filtros, validación — todo correcto. Pero no loggueás nada porque “la auditoría es overhead”. Resultado: cuando hay un incidente, no sabés qué pasó.

2. Roles demasiado amplios (defeat de la seguridad)

En vez de “research” y “deployment” separados, terminás con un rol gigante “trusted-agent” que puede hacer casi todo. O peor, creás un rol por cliente y terminás con 50 roles sin patrón. Revisitá el diseño: roles deberían ser pocos y bien definidos. Cubrimos ese tema en detalle en modelos de autenticación en plataformas.

3. Validación solo en servidor, no en cliente

Validás en runtime, bien. Pero el cliente sigue recibiendo la lista COMPLETA de herramientas en `list_tools()` y vos filtrás los resultados después. El agente ve herramientas que no puede usar. Mejor: filtrá en `list_tools()` mismo. El agente solo debería ver lo que puede hacer.

Preguntas Frecuentes

¿Qué es el Single Permission Boundary Problem?

Es cuando un servidor MCP expone todas las herramientas a cualquier agente autenticado, sin diferenciar qué puede hacer cada uno. Crea un solo perímetro de seguridad a nivel de servidor, no a nivel de herramienta. Cualquier agente que cruce ese perímetro accede a todo.

¿Cuál es la diferencia entre autenticación y autorización en MCP?

Autenticación verifica identidad (¿quién sos?) mediante OAuth, API keys o TLS. Autorización controla qué puede hacer esa identidad (¿qué herramientas podés llamar?) mediante roles y scopes. Son capas separadas. Fallás autenticación → conexión rechazada. Fallás autorización → herramienta bloqueada.

¿Cómo evito que un agente de investigación mal intencionado o compromometido acceda a herramientas de deployment?

Definiendo roles distintos con scopes específicos. El agente de investigación recibe un JWT con `role: “research”` y `allowed_tools: [“query”, “read”]`. Cuando intenta llamar `deploy`, el servidor valida el token, ve que no tiene permiso, y retorna PermissionError antes de ejecutar nada.

¿Qué información debo registrar en auditoría para detectar abuso de permisos?

Mínimo: identidad del agente, nombre de herramienta, parámetros, timestamp y resultado (permitido/denegado/error). Con esto podés detectar patrones: si un agente de investigación de repente intenta llamar herramientas de deployment cien veces seguidas, lo ves en los logs.

¿Cuánto tiempo tarda implementar scoping per-tool en un servidor MCP existente?

Si ya tenés autenticación en lugar, entre 4 y 8 horas según análisis de 2026. Necesitás: definir roles (1-2 horas), agregar JWT con claims (1-2 horas), implementar decoradores de validación (2-3 horas), agregar auditoría (1-2 horas). El mayor tiempo es prueba y diseño de roles, no ejecución.

Conclusión

La autenticación no es suficiente. Un servidor MCP seguro necesita dos capas: verificar quién sos (autenticación) y luego — independientemente — verificar qué podés hacer (autorización). El Single Permission Boundary Problem es real, es invisible hasta que no lo ves (o hasta que alguien lo explota), y la fix es straightforward: roles, scoping per-tool, runtime validation y auditoría estructurada.

En 2026, con agentes heterogéneos en producción, esto ya no es optional. Es el mínimo. Si tu servidor MCP hoy es “autenticado = acceso total”, te recomiendo que hagas la inversión de implementar scoping antes de que sea tarde. No es mucho trabajo, y el ROI en términos de seguridad es exponencial.

Fuentes

• Tool-Level Permission Scoping in MCP: Why Server Authentication Isn’t Enough – Dev.to (4 de abril 2026)
• MCP Security Documentation: Authorization – Anthropic
• MCP Authorization Best Practices – Cerbos
• MCP Authentication and Authorization – Microsoft Azure Foundry
• MCP Authentication and Authorization Guide – Stytch