Tu agente de IA tiene la clave de la base de datos. ¿Quién más la tiene?
Los agentes con function calling y MCP convirtieron el chatbot en un usuario privilegiado de tu sistema. Los cinco patrones de abuso que encontramos en pentests de agentes y cómo reducir el radio de impacto.
De chatbot a usuario privilegiado
En 2024 el riesgo de un chatbot era decir algo incorrecto. En 2026 el riesgo es hacer algo incorrecto. Los agentes conectados mediante function calling, MCP (Model Context Protocol) o integraciones directas consultan el CRM, abren tickets, emiten reembolsos, ejecutan SQL y llaman a APIs internas. El modelo se convirtió en un usuario del sistema, muchas veces con una service account con más permisos que cualquier humano.
El OWASP Top 10 para LLM lo llama Excessive Agency (LLM06) e Insecure Output Handling (LLM02). En la práctica, es lo que más hallazgos críticos genera en nuestras pruebas de agentes.
Los cinco patrones que encontramos
1. La tool confía en el modelo
get_invoice(customer_id) recibe el ID que el modelo decidió pasar. Si se puede convencer al modelo (por prompt injection directa o por un documento envenenado) de pasar el ID de otro cliente, la tool obedece. Es BOLA/IDOR con un intermediario que habla español. La corrección es la misma que en las APIs: autorización dentro de la tool, ligada a la identidad del usuario autenticado, nunca a un parámetro elegido por el modelo.
2. Una credencial para todo
El agente se ejecuta con una única API key o service account que ve todos los tenants. Cualquier inyección exitosa se convierte en acceso total. Hemos visto agentes de soporte con permiso de escritura en la base de datos de producción "porque una tool necesitaba actualizar un estado".
3. Encadenamiento de tools
Por separado, read_file y send_email son inofensivas. Juntas, son exfiltración. El atacante no necesita una tool peligrosa; necesita dos tools benignas y un prompt que las encadene. Probar tool por tool no lo detecta: hay que probar combinaciones.
4. Acciones sin confirmación humana
Reembolsar, borrar, transferir, publicar. Cuando el agente ejecuta acciones irreversibles sin un paso de aprobación, un único documento malicioso en la base de conocimiento se convierte en un incidente financiero. El patrón seguro es human-in-the-loop para cualquier acción destructiva o que mueva dinero, con límites por transacción y por periodo.
5. Salida del modelo tratada como confiable
El modelo devuelve markdown, HTML o JSON que el frontend renderiza o que otro sistema ejecuta. Sin sanitización, es XSS o inyección de comandos con un salto más. El caso clásico: el agente genera un enlace con datos del contexto en la URL y el propio cliente de la aplicación hace la petición que exfiltra.
Cómo reducir el radio de impacto
- Mínimo privilegio por tool, con la identidad del usuario final propagada (no una cuenta del agente).
- Allowlist de tools por contexto: el agente de soporte no necesita
run_sql. - Separación estructural entre instrucciones y datos recuperados, con marcado explícito del contenido no confiable.
- Confirmación humana para acciones irreversibles; límites de importe y de tasa.
- Logs de cada llamada a tool con entrada, salida y el fragmento de contexto que la motivó; sin ellos no hay investigación posible.
- Pruebas de seguridad del sistema completo antes de cada ampliación de permisos del agente.
Cómo lo prueba Pentest Machine
En el AI/LLM Pentest mapeamos cada tool, credencial e integración del agente, probamos inyección directa e indirecta, encadenamientos y escalada de privilegios, y entregamos una PoC reproducible con el impacto real: el registro expuesto, el correo enviado, el reembolso emitido en entorno de pruebas. Si tu agente ya tiene acceso a datos de clientes, ya forma parte de tu superficie de ataque.