Informe práctico · Deep Dive
Un informe práctico desde VamiGRC
Un servidor MCP seguro mantiene todas las decisiones relevantes fuera del agente de IA. Al desarrollar el servidor MCP que conecta asistentes de IA como Claude con VamiGRC, aprendimos que una confirmación dentro del chat no es un control de seguridad: un agente manipulado puede responderla él mismo. Este informe muestra cómo trasladamos al backend la identidad, las aprobaciones, la autonomía y los límites entre inquilinos, cómo pusimos a prueba cada uno de ellos y qué limitaciones persisten.
Desde la revisión de la especificación MCP de junio de 2025, un servidor MCP protegido es un servidor de recursos de OAuth 2.1. La práctica va a la zaga, y en una plataforma GRC hay todavía más en juego.
8,5 %
de los más de 5200 servidores MCP de código abierto analizados en octubre de 2025 utilizaban OAuth.
State of MCP Server Security 2025: Research Report (octubre de 2025) (abre un sitio web externo)
Specification, Revision 2025-06-18: Authorization (junio de 2025) (abre un sitio web externo)
El agente lee riesgos, incidentes y datos de proveedores, y puede modificarlos. Un cambio erróneo no es solo un error de software: puede falsear las evidencias en las que confía un auditor.
¿Cómo puede un agente de IA trabajar con datos de cumplimiento sin convertirse en el punto más débil de la plataforma?
Modelamos tres atacantes, con STRIDE para el tipo de fallo y el OWASP MCP Top 10 como catálogo de riesgos. Seleccione un atacante para ver qué controles lo limitan, qué pruebas negativas se relacionan con él y qué riesgo queda.
Riesgo residual: En una sesión secuestrada, con el nivel L2 el agente todavía puede confirmar en el chat y puede teclear él mismo la referencia de eliminación. Por eso, las eliminaciones y las decisiones requieren la aprobación en la aplicación. La inyección de prompts en sí no puede evitarse por completo.
Riesgo residual: Lo que permitan la API pública y los límites de la organización sigue siendo posible: con el nivel L2, una sesión secuestrada todavía puede confirmar en el chat cambios que no sean eliminaciones ni decisiones, y la reversión solo es parcial.
El hilo conductor: un agente manipulado no irrumpe en el sistema. Utiliza permisos que posee legítimamente. Por eso, cada control debe situarse donde el agente no pueda alcanzarlo.
El agente nunca posee un token que el backend acepte como una sesión de usuario normal. La cadena de inicio de sesión en cuatro pasos:
El asistente localiza el servidor de autorización a través de los Protected Resource Metadata del servidor MCP (RFC 9728).
El usuario inicia sesión en el propio VamiGRC y ve una pantalla de consentimiento: qué asistente, si solo lectura o lectura y modificación, y qué inquilino.
El asistente recibe un token de acceso válido durante minutos, no días, vinculado al servidor MCP como audiencia, además de un token de actualización que cambia con cada uso.
El backend acepta ese token únicamente como un token de API acotado: solo la API pública, nunca funciones de administración y nunca más que el propio rol del usuario.
Nuestro diseño anterior intercambiaba el inicio de sesión en un proveedor de identidad externo por un token del backend. Funcionaba, pero las sesiones de larga duración y el intercambio de tokens no casaban bien, y tras periodos de inactividad los usuarios veían «sesión caducada». Desde que VamiGRC es el propio servidor de autorización, esa clase de problemas ha desaparecido.
Un único scope ausente, offline_access, hizo que un importante cliente de IA fallara antes incluso de mostrar una página de inicio de sesión.
Fundamentos: RFC 9728: OAuth 2.0 Protected Resource Metadata (abril de 2025) (abre un sitio web externo) · RFC 8707: Resource Indicators for OAuth 2.0 (febrero de 2020) (abre un sitio web externo) · RFC 9700: Best Current Practice for OAuth 2.0 Security (enero de 2025) (abre un sitio web externo) · The OAuth 2.1 Authorization Framework (Internet-Draft) (abre un sitio web externo)
Nuestra primera versión pedía al usuario que confirmara cada cambio en la conversación. Parecía seguro, pero la confirmación se respondía dentro del mismo canal que controla el atacante.
El control está en el canal del atacante.
El agente no puede falsificar estas capas. Las eliminaciones y las decisiones requieren además la aprobación en la aplicación.
Cada escritura es una llamada en dos pasos. El primero devuelve una vista previa y la almacena en el servidor; solo su confirmación escribe. Si el registro ha cambiado entretanto, la confirmación se rechaza.
En el paso de confirmación, el servidor MCP firma la solicitud exacta. El backend rechaza cualquier escritura sin este comprobante, por lo que un token de acceso robado, usado directamente contra la API, no puede escribir.
Un simple «sí» no elimina nada. El usuario debe teclear la referencia del registro, y la vista previa enumera todo lo que está vinculado a él. Los registros que pueden archivarse se archivan en lugar de borrarse.
No todas las acciones merecen la misma confianza. Cada ruta de escritura de la API pública pertenece a una clase de acción, y la organización fija para cada clase el nivel de autonomía máximo, conforme a los niveles L0 a L3 de VamiGRC.
L0
El agente no puede actuar.
En el servidor MCPSe rechaza con un motivo claro y la persona actúa en VamiGRC.
L1
El agente prepara, la persona actúa.
En el servidor MCPUn borrador que la persona revisa y guarda.
L2
El agente actúa tras la aprobación de una persona.
En el servidor MCPVista previa y confirmación; para eliminaciones y decisiones, aprobación en la app.
L3
El agente actúa solo y todo queda registrado.
En el servidor MCPSolo para clases de bajo riesgo, como las notas.
La organización fija el máximo, y cada persona solo puede restringirlo para sus propios asistentes. Siempre rige la configuración más estricta.
Las eliminaciones y las decisiones nunca son autónomas, y las decisiones firmadas, como las aprobaciones, nunca pasan por el chat.
Una ruta sin clase se considera bloqueada. Una prueba falla en cuanto una nueva ruta de escritura carece de clase.
Elija una clase de acción, el máximo de la organización y el límite personal. La calculadora aplica las tres reglas.
Nivel efectivo
L2Ejecutado por IA con aprobación obligatoria
Vista previa y confirmación; para eliminaciones y decisiones, aprobación en la app.
Restringido por el máximo de la organización.
Modelo simplificado basado en este informe práctico, no una réplica de la configuración del producto.
Los consultores trabajan para varios clientes, por lo que una persona suele tener acceso a varios inquilinos (tenants). El servidor MCP sigue al inquilino que la persona ha seleccionado en la app de VamiGRC, comprobado en cada llamada y sin caché. Esa comodidad crea un riesgo nuevo.
La vista previa almacena su inquilino y su empresa, y la respuesta indica ambos.
El servidor MCP sigue el cambio en la siguiente llamada.
La confirmación se rechaza antes de que se envíe nada.
El servidor rechaza la operación en lugar de recurrir en silencio a otro inquilino.
Cada prueba intenta romper un control, de extremo a extremo contra un backend real y un cliente MCP real, no solo en pruebas unitarias.
| Prueba | Resultado esperado | Resultado |
|---|---|---|
| Código de autorización usado dos veces | Rechazado, y la conexión creada con él se cierra | Superada |
| Token de actualización antiguo reutilizado tras la rotación | Rechazado, y se cierra toda la conexión | Superada |
| Un simple «sí» ante una vista previa de eliminación | No se elimina nada; se exige la referencia | Superada |
| Cambio de inquilino entre la vista previa y la confirmación | Confirmación rechazada, no se escribe nada | Superada |
| Varios cambios de inquilino seguidos | La conexión sigue cada cambio | Superada |
| Eliminación por ID en otra empresa | No encontrado; el registro se conserva | Superada |
| Escritura sin el comprobante de confirmación | Rechazada | Superada |
| Límite personal más estricto que el de la organización | Rige el límite más estricto | Superada |
Lo que los encontró fue probar los controles como lo haría un atacante, y no solo las funcionalidades.
Cinco conclusiones trasladables a otros servidores MCP y cinco limitaciones, expuestas abiertamente.
Diez preguntas extraídas de este informe práctico. Cuantas más veces responda «Sí», menos dependerá su seguridad de lo que haga el agente.
Respondidas: 0/10
El resultado es una orientación, no una evidencia de auditoría. Sus respuestas no salen de su navegador.
Así asignamos los controles a los catálogos de riesgos. Ambos catálogos son jóvenes, y el mapeo cambiará con ellos.
MCP01
OWASP MCP Top 10 (v0.1, beta) (abre un sitio web externo)
Sin token passthrough, tokens de vida corta vinculados a la audiencia, tokens de actualización rotatorios con detección de reutilización y acceso limitado a la API pública.
MCP10
OWASP MCP Top 10 (v0.1, beta) (abre un sitio web externo)
Las respuestas indican el inquilino y la empresa, los datos de los registros se marcan como no confiables y el agente solo ve lo que permite el rol de la persona.
LLM06:2025
OWASP Top 10 for LLM Applications 2025 (abre un sitio web externo)
Niveles de autonomía por clase de acción, topes fijos y aprobación en la aplicación para eliminaciones y decisiones.
El OWASP MCP Top 10 es una beta, y el Agent Control Standard está en la versión 0.1.0. Los diez riesgos MCP en nuestro Deep Dive
El informe práctico preparado para decisores: modelo de amenazas, identidad sin token passthrough, aprobaciones en el backend, niveles de autonomía y gobernanza, vinculación al inquilino y registro de auditoría, pruebas negativas, preguntas a proveedores y un plan de 30-60-90 días.
Revisamos servidores MCP e integraciones de agentes tal como describe este informe: con un modelo de amenazas, controles fuera del agente y pruebas negativas.
Especificaciones, estándares y estudios en los que se basa este informe práctico.
Respuestas breves
Porque se produce en el mismo canal que controla un atacante. Un agente manipulado mediante inyección de prompts puede responder él mismo «sí» a la pregunta, y quien tenga un token de acceso robado se salta el chat por completo. Son más eficaces los controles que el agente no puede falsificar: vistas previas impuestas por el servidor, un comprobante de confirmación vinculado a la solicitud exacta y, para eliminaciones y decisiones, la aprobación en la aplicación.
Desde la revisión de junio de 2025, un servidor MCP protegido es un servidor de recursos de OAuth 2.1. Se exigen el descubrimiento de metadatos a través de los Protected Resource Metadata (RFC 9728), PKCE y tokens emitidos con el servidor MCP como audiencia; el token passthrough está prohibido. El informe práctico muestra qué más hace falta en cuanto un agente tiene permiso para escribir.
Definen lo que un agente puede hacer por sí solo: L0 manual, L1 asistido por IA, L2 ejecutado por IA con aprobación obligatoria y L3 totalmente autónomo y plenamente auditado. En el servidor MCP de VamiGRC, la organización fija el nivel máximo por clase de acción, cada persona solo puede restringirlo y una ruta sin clase queda bloqueada. Las eliminaciones y las decisiones nunca son autónomas.
No. El texto de los registros se marca como no confiable, pero un modelo puede seguirlo igualmente. Los controles limitan lo que puede hacer un agente manipulado, pero no detienen la manipulación en sí. Por eso, las eliminaciones y las decisiones requieren la aprobación en la aplicación.
Con una prueba negativa por cada control que intente romperlo de forma deliberada: canjear dos veces un código de autorización, reutilizar un token de actualización antiguo, cambiar de inquilino entre la vista previa y la confirmación, escribir sin el comprobante de confirmación o eliminar por ID en otra empresa. De extremo a extremo, contra un backend real y un cliente MCP real, no solo en pruebas unitarias.
Ambos están en una fase temprana: el OWASP MCP Top 10 es una beta en la versión 0.1, y el Agent Control Standard está en la versión 0.1.0. Asignamos nuestros controles a los riesgos Token Mismanagement & Secret Exposure, Context Injection & Over-Sharing y Excessive Agency, y ajustaremos el mapeo a medida que los estándares maduren.
Revisamos servidores MCP e integraciones de agentes como lo haría un atacante y le mostramos qué decisiones siguen al alcance del agente.
