)
Última actualización: 4 de noviembre, 2026
¿Qué son los logs de auditoría en MCP? Los logs de auditoría en MCP (MCP audit logging) registran cada llamada a herramientas, cada aprobación y cada cambio de configuración del Model Context Protocol. Conservan el contexto suficiente para responder después a una pregunta: qué agente hizo qué, en nombre de quién, con qué herramienta y si estaba permitido. Para un CISO son a la vez una fuente de detección para el SIEM y la evidencia que piden los auditores.
TL;DR: puntos clave
- La especificación de herramientas de MCP (versión 2026-07-28) indica que los clientes deberían registrar el uso de herramientas con fines de auditoría y que una persona debería poder denegar siempre las invocaciones (especificación MCP, 2026).
- OWASP incluye la monitorización, el registro y la auditoría como buena práctica 10 de 12 para MCP, con parámetros completos, contexto del usuario y hora en cada log de llamada (OWASP).
- Según el EU AI Act, proveedores y responsables del despliegue de sistemas de IA de alto riesgo deben conservar los logs generados automáticamente al menos 6 meses (artículos 19 y 26).
- El AI Omnibus (Reglamento (UE) 2026/1744) retrasó las normas de alto riesgo al 2 de diciembre de 2027 para los sistemas del anexo III y al 2 de agosto de 2028 para los productos del anexo I (EUR-Lex).
- El 55 % de 100 CISO encuestados tiene servidores MCP u otras integraciones de agentes en producción, y al 46 % le preocupa que los agentes excedan sus permisos o sufran un compromiso (Andreessen Horowitz, 2026).
- La utilidad de logging de MCP está obsoleta desde la versión 2026-07-28 del protocolo, así que basa la auditoría en clientes o en un gateway que controles (especificación MCP, 2026).
De un vistazo: qué debe vigilar un CISO en MCP
Respuesta rápida
¿Qué debe contener un log de auditoría MCP?
En cada llamada, registra el usuario final, el agente y el cliente, además del servidor MCP y su versión. Añade el nombre de la herramienta y el hash de su definición, los argumentos ocultados, la decisión de la política, la aprobación humana si la hubo, el resultado y la hora con un ID de traza. Registra también conexiones, cambios de definiciones y cambios de permisos, y envíalo todo al SIEM.
| Qué registrar | Por qué importa | Quién lo pide |
|---|---|---|
| Cada llamada con usuario, agente y herramienta | Reconstruye quién hizo qué y en nombre de quién | Respuesta a incidentes, auditores |
| Decisiones de política (permitido, bloqueado, enmascarado) | Demuestra que los controles se ejecutaron | Auditores SOC 2, equipos de riesgo |
| Aprobaciones y denegaciones humanas | Muestra supervisión en acciones sensibles | Supervisión del EU AI Act, auditoría interna |
| Hashes y cambios de definiciones | Detecta rug pulls y cambios no aprobados | Ingeniería de seguridad |
| Servidores, clientes y conexiones nuevos | Encuentra el shadow MCP antes de una fuga | CISO, gobierno de IA |
| Uso de credenciales y scopes por servidor | Detecta tokens compartidos o con exceso de privilegios | Equipos de identidad y acceso |
Cómo lo investigamos
El 4 de noviembre de 2026 revisamos las especificaciones de herramientas y de logging de MCP (versión 2026-07-28) y la cheat sheet de seguridad MCP de OWASP. También leímos los artículos 12, 19 y 26 del EU AI Act, el reglamento del AI Omnibus, los Trust Services Criteria de la AICPA y descripciones públicas del anexo A de ISO/IEC 42001. La lista de campos y el mapa de evidencias son nuestra síntesis, no asesoramiento jurídico.
Por qué los logs de auditoría en MCP no son logs de API
Los logs de auditoría en MCP necesitan su propio diseño porque el modelo, no un desarrollador, decide qué herramienta llamar y con qué argumentos. Los logs de API muestran que una cuenta de servicio llamó a un endpoint, pero casi nunca qué usuario lo pidió, qué agente eligió la herramienta, qué servidor respondió ni si una política revisó la llamada.
Según la cheat sheet de seguridad MCP de OWASP, MCP deja que los modelos decidan qué herramientas invocar, cuándo y con qué parámetros. Eso mezcla prompt injection, cadena de suministro y confused deputy. Entre sus riesgos clave está la exfiltración por canales legítimos, en la que instrucciones inyectadas esconden datos sensibles dentro de llamadas aparentemente normales. Solo los logs por llamada, con argumentos, pueden mostrarlo.
La responsabilidad también está repartida. Según la especificación MCP (2026), los clientes deberían registrar el uso de herramientas con fines de auditoría, mientras que los servidores deben validar entradas, aplicar controles de acceso, limitar el ritmo de llamadas y sanear las salidas. Con muchos clientes y servidores, ningún equipo ve el conjunto si los logs no se reúnen en un solo sitio. Para lo básico, empieza por nuestra guía de seguridad MCP.
)
Qué registrar en cada llamada a herramientas MCP
Registra lo suficiente para reconstruir el evento sin preguntar al agente qué pasó: identidad, contexto, acción, decisión de control y resultado. Trata el registro como evidencia, con campos coherentes, un mismo ID de traza en todos los saltos y ningún secreto en el contenido.
| Grupo de campos | Campos | Notas |
|---|---|---|
| Identidad | Usuario final, ID del agente, aplicación cliente, tenant | Registra a la persona, no solo la cuenta de servicio |
| Servidor | Nombre del servidor MCP, versión, transporte, endpoint o comando de arranque | Permite vincular la llamada a una entrada aprobada del registro |
| Herramienta | Nombre, hash de la definición, anotaciones en el momento de la llamada | Un hash distinto es señal de rug pull |
| Petición | Argumentos ocultados, hash de los argumentos, tamaño | El hash prueba la integridad sin guardar datos en bruto |
| Autorización | Audiencia del token, scopes usados, ID de la credencial | Nunca registres el token |
| Política | Decisión (permitir, bloquear, enmascarar, pedir aprobación), ID de la regla, resultado de los detectores | Demuestra que los controles se ejecutaron |
| Supervisión humana | Aprobador, decisión, hora, parámetros mostrados | Evidencia del human-in-the-loop |
| Resultado | Estado, tipo de error, latencia, tamaño de la respuesta, resumen ocultado | Sirve para detectar anomalías y fugas |
| Correlación | ID de traza, ID de sesión o conversación, ID de la llamada padre | Une las cadenas de varios pasos de un agente |
Este es un registro de auditoría simplificado e ilustrativo. Los nombres de campo son ejemplos, no un estándar.
Registra también lo que rodea a las llamadas: conexiones de servidores, cambios en la lista de herramientas, herramientas nuevas, autorizaciones fallidas, cambios de políticas y cambios en quién puede aprobar qué. Suelen ser las primeras señales de un problema.
Qué no registrar: secretos, datos personales y ruido
Un log de auditoría con tokens o datos de clientes se convierte en objetivo de ataque. Según la especificación de logging de MCP (2026), los mensajes de log no deben contener credenciales ni secretos, información de identificación personal ni detalles internos que puedan facilitar ataques. OWASP aplica la misma regla a la auditoría MCP: oculta secretos y datos personales.
Los investigadores quieren parámetros completos y los equipos de privacidad quieren menos datos. Tres patrones resuelven la mayor parte de esa tensión:
- Oculta en origen: enmascara secretos, tokens y datos personales antes de que el registro salga del gateway o del cliente, no después en el SIEM.
- Guarda el hash de lo que no puedes conservar: almacena un hash de argumentos y respuestas para demostrar la integridad sin guardar el contenido.
- Escalona el detalle: guarda metadatos completos de cada llamada y contenidos ocultados más amplios solo para herramientas sensibles, con un acceso más restringido a ese nivel.
La utilidad de logging de MCP no es un sustituto. Permite que los servidores envíen mensajes de log estructurados a los clientes, con niveles de severidad basados en syslog (RFC 5424). La especificación la declaró obsoleta en la versión 2026-07-28 y pide que las nuevas implementaciones no la adopten. Señala stderr para servidores stdio y OpenTelemetry para observabilidad estructurada. En cualquier caso, el servidor que auditas controla esos mensajes, así que tu auditoría debe salir de un componente que controles tú.
Cómo llevar los logs de auditoría MCP al SIEM
Los logs solo son un control cuando alguien actúa sobre ellos. Envía los registros de auditoría MCP al SIEM en formato estructurado y crúzalos con tus datos de identidad y activos. Después crea detecciones para los patrones que cita OWASP: herramientas nuevas en uso, consultas de nivel administrador y frecuencia de llamadas anómala.
| Detección | Señal en los logs MCP | Respuesta habitual |
|---|---|---|
| Rug pull | El hash de la definición no coincide con el aprobado | Bloquear la herramienta, abrir una revisión |
| Shadow MCP | Llamadas a un servidor o endpoint fuera del registro | Bloquear, identificar al responsable, evaluar la exposición |
| Exfiltración de datos | Secretos o datos personales en argumentos hacia herramientas externas | Bloquear o enmascarar, avisar al responsable de los datos |
| Fuga entre servidores | Datos devueltos por el servidor A aparecen en llamadas al servidor B | Aislar servidores, revisar prompts y herramientas |
| Abuso de privilegios | Herramientas o scopes de administrador fuera de lo normal | Aprobación reforzada, revocar credenciales |
| Aprobación omitida | Herramienta sensible ejecutada sin aprobación registrada | Tratarlo como incidente, corregir la política |
Normaliza antes de crear detecciones: un único esquema para clientes y gateways, hora en UTC, un ID de traza por tarea del agente y cada servidor etiquetado con su estado en el registro y su responsable. Nuestra guía de observabilidad con AI gateway explica cómo la telemetría del gateway alimenta las herramientas de monitorización.
Por último, pon a prueba el circuito con un ejercicio de red teaming planificado que active cada detección, y comprueba que las alertas llegan a la cola correcta.
Evidencias de cumplimiento: EU AI Act, SOC 2 e ISO 42001
Los logs de auditoría MCP encajan con las obligaciones de registro y monitorización de los principales marcos de IA y seguridad. Ninguno menciona MCP. Piden registrar los eventos del sistema, conservarlos y demostrar que los vigilas, y los logs de llamadas a herramientas lo hacen de forma directa para los agentes.
| Marco | Qué pide | Evidencia en los logs MCP |
|---|---|---|
| EU AI Act, artículo 12 | Los sistemas de alto riesgo deben permitir técnicamente el registro automático de eventos (logs) durante toda su vida | Logs del gateway o del cliente de cada acción y llamada del agente |
| EU AI Act, artículos 19 y 26(6) | Proveedores y responsables del despliegue conservan los logs generados automáticamente que estén bajo su control al menos seis meses, salvo otra norma | Política de retención y almacenamiento de la auditoría MCP |
| EU AI Act, artículo 26(5) | Los responsables del despliegue vigilan el funcionamiento del sistema de alto riesgo | Alertas del SIEM, registros de revisión y tickets de incidentes |
| SOC 2, CC7.2 | Vigilar los componentes en busca de anomalías y analizarlas para decidir si son eventos de seguridad | Detecciones MCP en el SIEM, registros de triaje |
| SOC 2, CC7.3 | Evaluar los eventos de seguridad para decidir si son incidentes y actuar | Tickets de incidentes vinculados a entradas de log MCP |
| ISO/IEC 42001, anexo A, A.6.2.8 | Decidir en qué fases del ciclo de vida se registran logs de eventos, como mínimo mientras el sistema está en uso | Una decisión documentada por agente y los propios logs |
Tres puntos que conviene cerrar con los equipos legal y de auditoría:
- Primero, el alcance: las obligaciones de registro del EU AI Act se aplican a sistemas de IA de alto riesgo. Un agente interno de programación no es de alto riesgo por defecto, pero uno usado en selección de personal o crédito puede serlo. Decide qué agentes entran antes de diseñar la retención.
- Conoce las fechas: según el Reglamento (UE) 2026/1744 (2026), las normas de alto riesgo se aplican desde el 2 de diciembre de 2027 para los sistemas del anexo III y desde el 2 de agosto de 2028 para los productos del anexo I.
- Más que logs: los auditores SOC 2 buscan una monitorización que funcione, así que guarda reglas de alerta, responsables y registros de revisión junto a los logs.
Para planificar el EU AI Act en conjunto, consulta nuestra guía de cumplimiento del EU AI Act para empresas.
Detectar servidores shadow MCP con tus logs
El shadow MCP son servidores que empleados o equipos conectan a sus agentes sin revisión de seguridad. Es una forma de shadow AI y cuesta verlo porque un servidor local puede ejecutarse como proceso hijo de un IDE o una aplicación de escritorio. Compara lo que aprobaste con lo que realmente se ejecuta.
Combina cuatro fuentes de datos:
- Logs del gateway: el tráfico hacia un servidor que no está en el registro es shadow MCP por definición. Enruta el tráfico MCP remoto por un gateway para que esta vista sea completa.
- Telemetría de endpoints: ficheros de configuración de clientes MCP y procesos que IDEs y asistentes de escritorio lanzan para servidores locales.
- Logs de red y DNS: conexiones salientes desde equipos de desarrollo hacia endpoints MCP remotos desconocidos.
- Logs de identidad y OAuth: nuevas autorizaciones OAuth a clientes de IA o servidores MCP, que muestran quién conectó qué y con qué scopes.
Después, trátalo como cualquier activo desconocido: localiza al responsable, revisa a qué datos podía llegar el servidor y, o bien lo incorporas al registro, o lo bloqueas. Nuestra guía sobre riesgos del shadow AI, detección y prevención cubre el programa completo, y la de registros y listas de permitidos MCP explica cómo incorporar servidores aprobados.
Seguridad y gobernanza: una sola auditoría en el gateway
Lo difícil de la auditoría MCP es la cobertura. Cada cliente registra a su manera, los servidores locales no dejan nada que controles y los remotos pertenecen a terceros. Un gateway delante del tráfico MCP registra identidad, decisiones de política y llamadas de la misma forma, sea cual sea el agente o el servidor.
Según Andreessen Horowitz (2026), el 55 % de 100 CISO encuestados ya tiene servidores MCP o integraciones similares en producción, así que las lagunas de cobertura no son hipotéticas.
NeuralTrust lo aborda como una Runtime Security Mesh. La Agent Gateway (TrustGate) propaga la identidad del usuario final en cada salto y aplica RBAC por agente y por herramienta. Mantiene registros de auditoría criptográficos pensados para superar la revisión de tu equipo de seguridad y de tu auditor. Su MCP Gateway registra qué LLM accedió a qué herramienta, con permisos y propósitos claros. NeuralTrust ofrece residencia de datos split-plane, para que los datos sensibles se queden en tu perímetro.
Agent Posture Management (TrustLens) ayuda con el inventario, y AI Red Teaming (TrustTest) comprueba que controles y detecciones aguantan. Los límites del plan importan para la evidencia: el plan Free conserva los logs 7 días y el Standard, 30, mientras que las integraciones con SIEM y OTel llegan con Enterprise. Para una visión del mercado, consulta los mejores MCP gateways y nuestra comparativa AI gateway vs MCP gateway.
¿Por dónde empezar?
Empieza por la cobertura, sigue con la detección y termina con la evidencia. Un esquema perfecto sirve de poco si la mitad del tráfico MCP lo esquiva. Cuando todo pase por un punto de control, añade detecciones y después ajusta la retención y los informes para los auditores. Cada fase depende de la anterior.
| Fase | Objetivo | Acciones clave |
|---|---|---|
| 1. Cobertura | Ver cada llamada MCP | Enrutar el tráfico MCP remoto por un gateway, inventariar servidores locales, acordar un esquema de log |
| 2. Detección | Actuar sobre lo que ves | Enviar logs al SIEM, añadir detecciones de rug pull, shadow MCP y exfiltración, asignar responsables |
| 3. Evidencia | Demostrarlo a los auditores | Fijar la retención por marco, documentar la decisión de registro por agente, guardar las revisiones |
La identidad atraviesa todas las fases. Si las llamadas no llevan al usuario final, los logs no pueden responder "en nombre de quién". Nuestra guía de autenticación MCP explica cómo OAuth y la gestión de tokens conservan esa identidad.
Conclusión
Los logs de auditoría en MCP permiten al CISO convertir la actividad de los agentes en algo que su equipo puede investigar y los auditores pueden verificar. Registra cada llamada con usuario, agente, servidor, hash de la herramienta, argumentos ocultados, decisión de política y resultado. Deja fuera los secretos, envía los registros al SIEM y crea detecciones para rug pulls, shadow MCP y exfiltración. Después, usa esos mismos registros como evidencia para el EU AI Act, SOC 2 e ISO 42001. Un único gateway hace realista esa cobertura.
Asegura la auditoría MCP en producción con NeuralTrust
Registra cada llamada de agentes y herramientas MCP con identidad, decisiones de política y ocultación de datos, y envía la auditoría a tu SIEM con el plan Enterprise.
)
Comparativas relacionadas
- Seguridad MCP 101
- Autenticación MCP
- Riesgos del shadow AI: detección y prevención
- Los mejores MCP gateways
Preguntas frecuentes sobre los logs de auditoría en MCP
1. ¿Qué son los logs de auditoría en MCP?
Registran cada llamada a herramientas, aprobación y cambio de configuración del Model Context Protocol con identidad, contexto y resultado. Responden qué agente hizo qué, en nombre de quién, con qué herramienta y bajo qué política. Los equipos de seguridad los usan para detectar en el SIEM, y los auditores, como evidencia de que los controles funcionan.
2. ¿Qué hay que registrar en cada llamada a herramientas MCP?
El usuario final, el agente, el cliente, el servidor MCP y su versión, el nombre de la herramienta y el hash de su definición. Añade los argumentos ocultados, los scopes usados, la decisión de la política, la aprobación humana si la hubo, el resultado, la latencia y un ID de traza. OWASP pide parámetros completos, contexto del usuario y hora, ocultando secretos y datos personales.
3. ¿La especificación MCP obliga a registrar la auditoría?
La especificación de herramientas de MCP dice que los clientes deberían registrar el uso de herramientas con fines de auditoría, una recomendación y no un requisito estricto. También indica que siempre debería haber una persona capaz de denegar invocaciones. La utilidad de logging de MCP es para diagnóstico del servidor, no debe contener secretos ni datos personales y está obsoleta desde la versión 2026-07-28.
4. ¿Cuánto tiempo hay que conservar los logs de auditoría MCP?
Depende de tus obligaciones. Para sistemas de IA de alto riesgo, el EU AI Act exige a proveedores y responsables del despliegue conservar los logs generados automáticamente que estén bajo su control al menos seis meses, salvo que otra norma de la Unión o nacional diga lo contrario. Las normas sectoriales, los contratos o SOC 2 pueden exigir más. Define la retención por agente con el equipo legal.
5. ¿Los logs MCP ayudan con SOC 2 e ISO 42001?
Sí. El criterio CC7.2 de SOC 2 pide vigilar los componentes en busca de anomalías, y el CC7.3, evaluar los eventos de seguridad, así que las detecciones MCP y sus registros de triaje son evidencia directa. El control A.6.2.8 del anexo A de ISO/IEC 42001 pide decidir cuándo se registran los logs de eventos, como mínimo mientras el sistema está en uso.
6. ¿Cómo se detectan los servidores shadow MCP?
Comparando lo aprobado con lo que se ejecuta. Los logs del gateway muestran tráfico hacia servidores no registrados y la telemetría de endpoints, configuraciones y procesos MCP locales. Los logs de red muestran llamadas a endpoints remotos desconocidos y los de OAuth, nuevas autorizaciones a herramientas de IA. Después, localiza al responsable y regulariza o bloquea el servidor.
Sobre el autor
Roger Howroyd es Head of Global SEO and AI en NeuralTrust, donde dirige la estrategia de búsqueda de la compañía en SEO, AEO, GEO y optimización para LLM. Está especializado en búsqueda impulsada por IA, estrategia de contenidos y SEM. Conecta con él en LinkedIn.
NeuralTrust es la plataforma líder para proteger y escalar agentes de IA. Nombrada pionera en el Gartner Emerging Market Quadrant for AI Application Security 2026, reconocida en cuatro informes Gartner Hype Cycle en 2026 y destacada en la Gartner Market Guide for Guardian Agents 2026, la Gartner Market Guide for AI Gateways 2025 y el KuppingerCole Leadership Compass for Generative AI Defense 2025. Con sede en Barcelona y oficinas en Londres y Nueva York. Certificada ISO 27001.
Fuentes
Consultadas el 4 de noviembre de 2026.
- Model Context Protocol, "Tools" (versión de la especificación 2026-07-28), 2026.
- Model Context Protocol, "Logging" (versión de la especificación 2026-07-28, función obsoleta), 2026.
- OWASP Cheat Sheet Series, "MCP Security Cheat Sheet".
- EU Artificial Intelligence Act, "Artículo 12: Registros", "Artículo 19: Archivos de registro generados automáticamente" y "Artículo 26: Obligaciones de los responsables del despliegue".
- Unión Europea, "Reglamento (UE) 2026/1744 (Digital Omnibus on AI)", Diario Oficial, 24 de julio de 2026.
- AICPA, "2017 Trust Services Criteria (with revised points of focus, 2022)".
- ISO, "ISO/IEC 42001:2023 Artificial intelligence: Management system".
- Andreessen Horowitz, "The New Security Agenda", 2026.