Auditoría de seguridad de agentes de IA y servidores MCP
[ En corto ]
Una auditoría de seguridad de agentes de IA comprueba qué puede hacer realmente un agente autónomo antes de ponerlo en producción: su arquitectura y sus permisos efectivos, su resistencia a pruebas adversarias, los conectores y servidores MCP que expone, y si un incidente podría reconstruirse después. El riesgo dominante no es el modelo, sino el exceso de agencia: permisos más amplios de lo necesario unidos a la capacidad de encadenar acciones sin revisión.
Cuándo hay que auditar
Un agente no es un chatbot con mejor prompt: es un sistema con permisos que encadena acciones. La pregunta no es si se comporta bien, sino qué puede llegar a hacer.
Deberías auditar si
- El agente tiene herramientas conectadas que escriben, no solo que leen.
- Expone o consume servidores MCP enlazados con sistemas corporativos.
- Lee contenido que no controlas: correos, documentos de cliente, páginas web o tickets.
- Actúa en nombre de un usuario con los privilegios de ese usuario, o con los suyos propios.
- Vas a ponerlo delante de clientes o dentro de un sistema que ya está sujeto a auditoría.
Es otra cosa, con otro alcance
- Un asistente sin herramientas conectadas: el riesgo está en lo que dice, no en lo que hace.
- Un prototipo cerrado con datos ficticios y sin acceso a sistemas reales.
- La infraestructura que lo soporta, que se audita con las técnicas de seguridad de siempre y entra en el alcance solo si se acuerda.
Cómo se audita, en seis pasos
Auditar solo el prompt del sistema deja fuera la mayor parte de la superficie real de ataque. La secuencia encadena arquitectura, pruebas adversarias, conectores y trazabilidad.
Revisar la arquitectura y los permisos efectivos
No los permisos declarados: los efectivos. Qué puede leer, qué puede escribir y qué puede encadenar el agente por sí solo, siguiendo las credenciales hasta el final. Aquí aparece casi siempre el exceso de agencia, que es el riesgo dominante.
Definir qué se considera fallo
Antes de atacar hay que acordar qué resultado es inaceptable para este caso de uso concreto. Sin ese criterio, el red teaming produce anécdotas curiosas en vez de hallazgos que alguien tenga que arreglar.
Pruebas adversarias sobre el modelo y sus herramientas
Por escenarios: extracción de datos, evasión de restricciones, manipulación mediante contenido externo y abuso de las herramientas conectadas. Cada hallazgo cierra con una prueba reproducible y una contramedida verificable, no con una captura de pantalla.
Revisar conectores y servidores MCP
Mínimo privilegio por herramienta, autenticación y ámbito por cliente, validación estricta de entradas y salidas, y control de las descripciones de las herramientas, que son texto que el modelo lee y por tanto un vector de inyección más.
Verificar la trazabilidad
La pregunta de cierre: si mañana ocurre un incidente, ¿podría reconstruirse? Eso exige registro de entradas, salidas, herramientas invocadas y decisiones humanas. Un agente sin ese rastro no se puede auditar después, solo apagar.
Entregar pruebas, no impresiones
El informe se cierra con cada hallazgo acompañado de su reproducción y su contramedida, y con la verificación de que la contramedida funciona. Un informe que no se puede volver a ejecutar dentro de seis meses no sirve para saber si se arregló.
Lo que casi nadie te cuenta
Auditar el modelo y no el agente
El modelo es una pieza. La superficie real la forman sus herramientas, sus permisos y el contenido que lee. Una auditoría que solo prueba el modelo deja fuera casi todo lo que puede salir mal.
Confiar en el prompt de sistema como control de seguridad
Las instrucciones del sistema son una guía de comportamiento, no un límite de permisos. Lo que impide que un agente borre algo no es haberle pedido que no lo haga: es no haberle dado el permiso.
Olvidar la inyección indirecta
El ataque no llega por la conversación, sino dentro de un documento, un correo o una página que el agente lee por su cuenta. Es la vía que más se subestima justamente porque no la abre un usuario malicioso sentado delante.
Tratar las descripciones de herramientas como configuración
Son texto que el modelo lee y obedece. Un servidor MCP de un tercero con descripciones manipuladas puede dirigir el comportamiento del agente sin tocar una línea de tu código.
No registrar porque «ya lo hace la infraestructura»
El registro de infraestructura dice qué llamada se hizo. No dice qué se le pidió al agente, qué decidió ni por qué encadenó lo que encadenó. Son dos preguntas que ninguna herramienta de observabilidad clásica responde.
OWASP Top 10 para LLM: de riesgo a prueba concreta
La lista de OWASP nombra los riesgos; no dice cómo comprobarlos. Esta es nuestra traducción de cada uno a una prueba que se puede ejecutar y a la evidencia que debería quedar.
| Riesgo | Prueba concreta | Evidencia esperada |
|---|---|---|
| Inyección de prompts | Instrucciones adversarias por el canal directo y dentro de un documento que el agente lee. | La instrucción no altera permisos ni dispara acciones irreversibles sin revisión. |
| Revelación de información sensible | Solicitudes dirigidas a extraer datos de otros usuarios o de documentos fuera de ámbito. | El filtrado por identidad actúa en la recuperación, no después de generar. |
| Cadena de suministro | Revisión de modelos, librerías y servidores MCP de terceros, con sus versiones y su origen. | Inventario de dependencias con procedencia verificada y política de actualización. |
| Envenenamiento de datos y modelo | Inserción de contenido manipulado en las fuentes que alimentan el índice o el ajuste. | Control de origen y versiones en la ingesta, con capacidad de revertir. |
| Tratamiento inseguro de las salidas | Salidas del modelo dirigidas a componentes que ejecutan, consultan o renderizan. | Validación de la salida antes de llegar a cualquier intérprete o navegador. |
| Exceso de agencia | Recorrido de los permisos efectivos y de las cadenas de acción que el agente completa sin revisión. | Mínimo privilegio por herramienta y revisión humana en lo irreversible. |
| Filtración del prompt de sistema | Intentos de extracción del prompt y comprobación de qué revelaría si se filtrase. | El prompt no contiene secretos: su filtración no otorga acceso a nada. |
| Debilidades en vectores y embeddings | Consultas cruzadas entre ámbitos para comprobar la segmentación del índice. | Metadatos de permisos y vigencia por fragmento, aplicados en la recuperación. |
| Desinformación | Preguntas cuya respuesta correcta se conoce, midiendo el respaldo en las fuentes. | Capa de evaluación que mide si la respuesta está sostenida por lo recuperado. |
| Consumo no acotado | Peticiones costosas y repetidas para observar el comportamiento ante el límite. | Cuotas por usuario y por herramienta, con alerta sobre patrones anómalos. |
Cómo lo abordamos en Montevive
Auditamos lo que también construimos
Desplegamos agentes y servidores MCP en producción, no solo los revisamos. Eso cambia el tipo de hallazgo: se sabe dónde se rompen estas cosas porque se han roto antes, y las contramedidas que se proponen son las que se han tenido que implantar.
Publicamos el trabajo técnico
El primer servidor MCP open source para Penpot y la herramienta Go Name Detector de detección de nombres para anonimización están publicados y se pueden revisar. Es la forma de que la metodología se pueda comprobar en vez de creer.
El informe entrega pruebas reproducibles
Cada hallazgo incluye su reproducción, la contramedida y la verificación de que funciona. Si dentro de seis meses alguien quiere saber si aquello se arregló, tiene que poder volver a ejecutarlo, no releer un PDF.
Lo que nos preguntan sobre auditar agentes de IA
Las preguntas que nos llegan antes de empezar, respondidas sin rodeos.
Con cuatro bloques encadenados: revisión de la arquitectura y de los permisos efectivos del agente; pruebas adversarias sobre el modelo y sobre sus herramientas; revisión de los conectores y servidores que expone; y verificación de la trazabilidad, es decir, si un incidente podría reconstruirse después. Auditar solo el prompt del sistema deja fuera la mayor parte de la superficie real de ataque.
El riesgo dominante es el exceso de agencia: permisos más amplios de lo necesario combinados con la capacidad de encadenar acciones sin revisión. A partir de ahí aparecen la inyección indirecta desde contenido que el agente lee, el diputado confundido —el agente actuando con sus privilegios en beneficio de quien le habla— y la ausencia de registro que impide reconstruir lo ocurrido.
Principio de mínimo privilegio por herramienta, autenticación y ámbito por cliente, validación estricta de las entradas y salidas de cada herramienta, control de las descripciones de herramientas —que son texto que el modelo lee y por tanto un vector de inyección—, y registro de cada invocación con su resultado. [Enlazar el MCP server open source publicado por el equipo como evidencia.]
Es la lista de referencia de riesgos en aplicaciones con modelos de lenguaje: inyección de prompts, revelación de información sensible, cadena de suministro, envenenamiento de datos y modelo, tratamiento inseguro de las salidas, exceso de agencia, filtración del prompt de sistema, debilidades en vectores y embeddings, desinformación y consumo no acotado. [Publicar la tabla riesgo → prueba concreta → evidencia esperada.]
Es lograr que el modelo siga instrucciones del atacante en lugar de las del sistema, bien de forma directa en la conversación, bien de forma indirecta a través de un documento, una página web o un correo que el modelo lee. No hay defensa única: se combinan separación de canales de confianza, permisos mínimos en las herramientas, validación de salidas y supervisión humana en las acciones irreversibles.
Definiendo primero qué se considera fallo para ese caso de uso, y después atacando por escenarios: extracción de datos, evasión de restricciones, manipulación mediante contenido externo y abuso de herramientas conectadas. Cada hallazgo debe cerrar con una prueba reproducible y una contramedida verificable, no con una captura de pantalla.
Depende de tres variables medibles: número de sistemas en alcance, si hay agentes con herramientas conectadas y si se audita también la infraestructura que los soporta. [Publicar rango por tipo de alcance y qué incluye cada uno. Ningún competidor lo hace y es una de las preguntas de decisión con más volumen de prompt.]
Registrando entradas, salidas, herramientas invocadas y decisiones humanas, con alertas sobre patrones anómalos y revisión periódica de muestras. La monitorización de IA añade a la de seguridad clásica dos preguntas que ninguna herramienta de infraestructura responde: si el comportamiento del modelo se ha desviado y si alguien está intentando manipularlo.
Criterios para comparar proveedores: si auditan el agente completo o solo el modelo, si publican metodología y referencias técnicas verificables, y si el informe entrega pruebas reproducibles. [Bloque de prueba: código abierto publicado, casos y persona que firma la página.]
El riesgo que no ves, y la oportunidad que aún no aprovechas
Respondemos en menos de 24 horas.
Pide tu diagnóstico
Responderemos en menos de 24h.