MCP no es un límite de seguridad: controla el acceso del agente en los datos
MCP no está muerto. MCP tampoco es tu límite de seguridad. La primera frase corrige el titular provocador. La segunda corrige el error de arquitectura más caro.
El Model Context Protocol, no “Model Content Protocol”, estandariza cómo una aplicación de IA descubre e invoca herramientas, recursos y prompts. Eso facilita construir y gobernar integraciones. No demuestra que quien llama pueda leer el teléfono de un cliente concreto, modificar una factura o exportar un documento. Si un agente de IA capaz de programar llega al mismo sistema mediante una shell, un SDK o una API directa con credenciales más amplias, la herramienta MCP estrecha es una ruta preferida, no un límite.
Esta diferencia importa al comprar, diseñar o aprobar infraestructura para agentes. Un protocolo puede facilitar un comportamiento seguro. Solo un punto de aplicación que la carga no pueda evitar hace que el comportamiento inseguro falle. Si después necesitas el flujo OAuth y el diseño multi-tenant, consulta nuestra arquitectura de referencia para autorización MCP empresarial. Este artículo responde a la pregunta anterior: ¿dónde debe estar la frontera de confianza?
¿Necesitas un diseño de control de acceso que seguridad pueda aprobar?
Planificar una revisión de producción¿Cuál es la respuesta corta?
MCP es un límite de interfaz. La autorización es una decisión de política. Tu límite de seguridad es el conjunto de puntos de aplicación inevitables entre una identidad y cada acción o dato protegido.
La prueba práctica es sencilla: ¿puede el agente obtener los mismos datos o causar el mismo efecto por otra vía? Si la respuesta es sí, el servidor MCP no es el límite completo. Cada ruta alternativa necesita controles iguales o más fuertes, incluidas APIs directas, conexiones a bases de datos, sesiones de navegador, archivos locales, colas y SDK de cloud.
| Capa | Qué define | Qué no garantiza |
|---|---|---|
| MCP | Descubrimiento e invocación de herramientas, recursos y prompts; esquemas; marco opcional de autorización HTTP | Permiso por objeto, fila o campo en un sistema downstream |
| API | Un contrato general de servicio y sus operaciones | Mínimo privilegio sin identidad y autorización aplicadas |
| Harness del agente | Qué herramientas, comandos de shell y redes expone el runtime | Protección frente a credenciales o rutas disponibles fuera del harness |
| Límite de seguridad | Una decisión inevitable y fail closed antes de una lectura o escritura protegida | Nada fuera de los recursos y rutas que controla |
¿MCP está pensado para limitar lo que puede hacer un agente de IA?
Puede ayudar a reducir la interfaz, pero eso no equivale a imponer el límite. Las herramientas MCP tienen esquemas de entrada y los clientes pueden presentar una superficie más pequeña y relevante para la tarea que una API REST amplia. El esquema MCP actual también define anotaciones como readOnlyHint y destructiveHint. La especificación deja claro que son indicaciones y que un cliente no debe tomar decisiones de seguridad basándose en anotaciones de un servidor no confiable.
La especificación de autorización HTTP de MCP aporta controles OAuth valiosos. Exige resource indicators para que un token esté destinado a un servidor MCP concreto, y la guía de seguridad prohíbe el token passthrough hacia APIs downstream. Esos controles responden: “¿este token fue emitido para este servidor?”. No responden por completo: “¿puede este sujeto ver el campo contact_email del cliente 42 para esta tarea de soporte?”.
La segunda pregunta requiere contexto de negocio y de recurso. Debe resolverse en un sistema de autorización determinista, no en un prompt ni en el criterio del modelo.
¿Puede un agente capaz de programar saltarse MCP?
Sí, si su entorno de ejecución expone otra ruta utilizable y las credenciales necesarias. No, si el sistema que lo rodea elimina o limita esas rutas.
Escribir código no concede automáticamente acceso a cualquier API. El agente sigue necesitando red, credenciales, herramientas ejecutables y permiso. Ahí falla el argumento “MCP está muerto”. La generación de código cambia el modelo de amenazas, pero un sandbox, una allowlist de egress, una identidad de workload y credenciales de mínimo privilegio pueden dejar ese código sin poder fuera de la ruta aprobada.
La conclusión correcta no es “MCP no sirve”. Es: no confundas una interfaz cómoda con un control imposible de evitar. MCP sigue siendo útil para discovery tipado, invocación consistente, separación de credenciales y puntos de auditoría. Solo se convierte en un punto de control creíble cuando el runtime no puede rodearlo y el recurso downstream vuelve a comprobar la autorización.
¿Dónde debe vivir el control de acceso para agentes de IA?
Tan cerca del recurso protegido como resulte práctico, mientras las capas anteriores reducen el riesgo antes de llegar. “Control de acceso a nivel de datos” no significa una función mágica de base de datos. Significa que la decisión final incluye el objeto, la operación y la clasificación del dato, y que cubre todas las rutas hacia ese objeto.
| Capa de control | Decisión que debe aplicar | Ejemplo |
|---|---|---|
| Identidad delegada | Quién pidió, qué agente actúa y en nombre de quién | Un token de corta duración separa al sujeto humano del actor agente |
| Sandbox y egress | Qué archivos, procesos, hosts y protocolos son alcanzables | El agente de soporte llega al servicio de clientes, no a producción SQL |
| Política de herramienta o API | Qué operación y argumentos están permitidos ahora | Reembolso permitido solo por debajo de un importe aprobado |
| Política por objeto o fila | Qué registros exactos puede leer o cambiar el sujeto | El agente solo recupera clientes de la cola de soporte del usuario |
| Protección de campos | Qué atributos son necesarios para este propósito | Teléfono enmascarado salvo que exista permiso de devolución de llamada |
| Auditoría y revocación | Si la decisión puede explicarse, detenerse e investigarse | Registrar sujeto, actor, propósito, objeto, campos, versión de política y resultado |
Este modelo por capas coincide con prácticas de seguridad consolidadas. La arquitectura Zero Trust de NIST centra la protección en recursos, no en la ubicación de red. La guía ABAC de NIST evalúa atributos del sujeto, objeto, operación y entorno. Un agente es una entidad no humana que actúa dentro de un contexto, así que el modelo conocido sigue funcionando si conservas ese contexto.
¿Cómo es el control a nivel de datos en una tarea real de soporte?
Tomemos el ejemplo del argumento viral:
retrieve_customer_by_email(email)Un nombre de herramienta estrecho parece más seguro que un endpoint genérico GET /customers. No basta. El email puede pertenecer a un cliente fuera del tenant del usuario. La herramienta puede devolver campos innecesarios. Un agente capaz de programar puede llamar directamente a la API subyacente. Una credencial de servicio compartida puede tener acceso de administrador.
Una petición defendible lleva un contexto de decisión completo:
subject: user_184
actor: support_agent_7
purpose: resolve_ticket
action: customer.read
resource: customer_42
requested_fields: [name, plan, last_invoice_status]
tenant: acme_eu
ticket: ticket_912
environment: production
La aplicación es determinista:
- Deriva tenant, sujeto y actor de una identidad verificada, nunca de argumentos escritos por el modelo.
- Confirma la relación con el ticket y el permiso del usuario sobre ese objeto cliente.
- Permite solo los campos necesarios para el propósito de soporte.
- Aplica la misma comprobación en la API y en la capa de datos, aunque el gateway MCP ya haya permitido la herramienta.
- Devuelve un identificador de decisión de política con la respuesta para auditoría y análisis de revocación.
En datos relacionales, la seguridad a nivel de fila de PostgreSQL puede determinar qué filas ve o modifica un rol y usa default deny cuando RLS está activo sin una política aplicable. Para documentos compartidos y organizaciones jerárquicas, un modelo de relaciones granular como OpenFGA puede responder si este usuario o agente delegado puede hacer esta acción sobre este objeto. Son ejemplos, no requisitos de producto.
¿El cifrado por campo convierte los datos en el límite?
El cifrado puede reforzar el límite. No sustituye a la autorización.
Si el mismo runtime sobreprivilegiado puede pedir al servicio de claves que descifre todos los emails, el cifrado en reposo no ha cambiado el permiso efectivo. La mejora aparece cuando la liberación de la clave o la reidentificación también depende de identidad verificada, propósito, objeto, campo y tiempo, y cuando el texto claro solo existe en el componente confiable más pequeño.
Usa cada control criptográfico para su función:
- Cifrado envelope o por campo: limita qué servicios e identidades pueden recuperar campos sensibles.
- Tokenización o seudonimización: permite que la mayoría de workflows use sustitutos estables sin ver el valor original. La documentación de Google Cloud explica patrones reversibles e irreversibles.
- Redacción y enmascarado: eliminan datos innecesarios antes de que lleguen al modelo.
- Credenciales breves y vinculadas a audiencia: reducen alcance y duración del daño si se roba una credencial.
La regla práctica es: autoriza primero, minimiza después y descifra al final. No entregues un dataset amplio para luego pedir al modelo que ignore los campos que nunca debió recibir.
"Una herramienta MCP estrecha es útil. Solo se convierte en límite cuando el agente no puede evitarla y el recurso protegido aplica de forma independiente la misma identidad y política."
Seguridad MCP vs API: ¿cuál debes usar?
Normalmente ambas. MCP y las APIs resuelven partes distintas del stack. MCP ofrece a los clientes agente un contrato estándar de discovery e invocación. Las APIs siguen siendo la interfaz de servicio duradera detrás de muchos servidores MCP. Ninguna elección elimina la necesidad de autorización por objeto.
| Situación | Forma recomendada | Condición de seguridad |
|---|---|---|
| Varios clientes agente necesitan las mismas herramientas curadas | MCP delante de servicios existentes | Identidad en gateway y reautorización downstream |
| Un workflow determinista llama a un servicio | API directa o SDK puede ser más simple | Identidad de workload limitada y política por objeto |
| El agente ejecuta código arbitrario | MCP más sandbox y política de egress | Sin credenciales más amplias ni ruta de red alternativa |
| Campos muy sensibles | Broker de datos o servicio de recuperación dedicado | Minimización, descifrado controlado y auditoría completa |
| Muchos tenants y sistemas downstream | Gateway MCP, motor de políticas y controles por tenant | Tenant desde claims verificados, nunca desde el input |
Para el flujo OAuth, validación de audiencia, token exchange y aislamiento de tenants, continúa con la guía de arquitectura de autorización MCP. Para elegir entre las capas de conocimiento, conectividad y procedimiento, consulta MCP vs RAG vs Agent Skills vs Custom GPTs.
¿Qué debes preguntar a un proveedor MCP o de plataformas de agentes?
El riesgo comercial no depende de si el proveedor tiene una diapositiva llamada “enterprise MCP gateway”. Pide evidencia de que el límite declarado resiste intentos de evasión.
- Propagación de identidad: ¿los logs distinguen usuario, agente, servicio y actor downstream en cada salto?
- Rutas alternativas: ¿qué impide que código shell, automatización de navegador o una API directa use credenciales más amplias?
- Granularidad: ¿la política incluye herramienta, argumentos, tenant, objeto, relación, campos, propósito y riesgo?
- Fail closed: ¿qué ocurre si no están disponibles el motor de políticas, el proveedor de identidad o el servicio de claves?
- Credenciales: ¿los tokens son breves, están vinculados a audiencia y se intercambian en lugar de reenviarse?
- Minimización: ¿se pueden enmascarar, tokenizar o retirar campos antes de la inferencia?
- Prueba de auditoría: ¿un ID conecta intención, política, tool call, API downstream y campos devueltos?
- Revocación: ¿con qué rapidez pierde acceso un usuario, agente, tenant, servidor o versión de política?
- Prueba adversarial: ¿demuestra el proveedor un acceso cross-tenant y un bypass por API directa correctamente denegados?
Si la respuesta es “el prompt le dice al agente que no lo haga”, no hay límite de seguridad. Si es “la herramienta MCP es read-only”, pregunta qué componente verifica esa afirmación. El esquema oficial de MCP advierte que las anotaciones son indicaciones, no hechos confiables.
¿MCP está muerto?
No. La conclusión útil es menos dramática: MCP es infraestructura, no autoridad. Un protocolo estándar puede reducir costes de integración, hacer descubribles las herramientas, separar ciertas credenciales del modelo y crear un punto de inspección consistente. Son propiedades valiosas.
MCP falla cuando se le asigna un trabajo que no pretende completar. No corrige un token de administrador, una shell sin límites, una base multi-tenant plana ni un servicio que autoriza solo durante el login. La solución no es descartar MCP. Diseña identidad, ejecución y acceso a datos para que el protocolo se encuentre dentro de una frontera de confianza real.
Checklist de implementación
- Inventaría cada ruta desde el runtime del agente hasta datos sensibles y efectos laterales.
- Elimina credenciales permanentes de administrador y aísla el entorno de ejecución.
- Propaga por separado la identidad humana delegada y el actor agente.
- Aplica políticas de herramienta y argumentos antes de ejecutar.
- Vuelve a comprobar autorización sobre el objeto o fila exacta en downstream.
- Minimiza campos antes del modelo y controla después descifrado o reidentificación.
- Usa tokens breves vinculados a audiencia e intercámbialos para servicios downstream.
- Registra un ID de correlación y decisión de política en toda la cadena.
- Prueba bypass por API directa, lectura cross-tenant, campo prohibido e identidad revocada.
Reflexiones finales
MCP es una interfaz estándar útil, no un límite de seguridad completo. Las APIs son contratos de servicio potentes y tampoco son límites por defecto. El límite aplicable es la cadena que el agente no puede evitar: ejecución restringida, identidad delegada, política determinista sobre acción y argumentos, autorización por objeto en el recurso, minimización o descifrado controlado y una auditoría que demuestre cada decisión. Construye primero esa cadena. Después usa MCP donde su interoperabilidad y tooling simplifiquen la operación.
Fuentes primarias
- Especificación de autorización de Model Context Protocol, 2025-11-25
- Buenas prácticas de seguridad de Model Context Protocol
- Referencia del esquema MCP para anotaciones de herramientas
- RFC 8707, Resource Indicators for OAuth 2.0
- RFC 9700, Best Current Practice for OAuth 2.0 Security
- NIST SP 800-207, Zero Trust Architecture
- NIST SP 800-162, Attribute Based Access Control
- Políticas de seguridad por fila de PostgreSQL
- OpenFGA, autorización granular
- Google Cloud Sensitive Data Protection, seudonimización
- AWS Security Blog, patrones seguros de acceso para agentes con MCP