Seguridad en agentes con tool calling: prompt injection y permisos mínimos

Un agente con tool calling no se limita a generar texto: ejecuta acciones. Esa diferencia cambia por completo el modelo de amenazas. Un chatbot manipulado dice algo incorrecto; un agente manipulado puede consultar datos, enviarlos fuera o modificar registros con las credenciales que le diste.

Este artículo explica el problema y las defensas que sí funcionan a nivel de arquitectura, es decir, en el harness y no en el prompt — la misma línea que seguimos en la tercera parte de esta serie y en nuestra guía sobre desarrollo agéntico en equipos de software.

¿Qué es la prompt injection (directa e indirecta) y por qué es más grave en un agente que en un chatbot?

La prompt injection ocurre cuando texto no confiable que llega al modelo altera su comportamiento. En un chatbot el efecto suele quedarse en una respuesta incorrecta; en un agente con herramientas, ese mismo texto puede convertirse en una acción real: enviar un correo, consultar una base de datos o borrar un registro.

OWASP distingue dos variantes. En la inyección directa, es el propio usuario quien escribe la instrucción maliciosa. En la indirecta, el modelo acepta contenido de fuentes externas, como webs o archivos, que lleva instrucciones ocultas. Para un agente, la indirecta es la más peligrosa: el atacante no necesita hablar con él, le basta con que el agente lea algo que él controla.

Simon Willison, que acuñó el término por analogía con la inyección SQL, lo describe como el problema de mezclar contenido de confianza y contenido sin confianza en un mismo contexto, sin que el modelo pueda distinguir de forma fiable la importancia de una instrucción según su origen. Anthropic ilustra el caso típico: un correo aparentemente inofensivo con instrucciones en texto blanco, invisibles para la persona, que ordenan reenviar los mensajes confidenciales a una dirección externa mientras el agente redacta las respuestas que se le pidieron.

OWASP añade un matiz importante: la gravedad depende del contexto de negocio y de cuánta agencia se le haya dado al modelo en la arquitectura. Ahí es donde se puede actuar.

¿Qué es la "tríada letal" de los agentes de IA?

Es la combinación de tres capacidades en un mismo agente: acceso a datos privados, exposición a contenido no confiable y capacidad de comunicar hacia fuera. Cuando coinciden las tres, un atacante puede lograr que el agente lea los datos privados y se los envíe.

Willison definió esta tríada en junio de 2025. Conviene entender cada pieza con ejemplos cotidianos:

• Datos privados: la razón de ser de muchas herramientas, como historiales de clientes, citas o facturas.
• Contenido no confiable: cualquier texto o imagen que un tercero pueda controlar. Un buzón de correo es el ejemplo perfecto, porque cualquiera puede escribirle al agente.
• Comunicación externa: cualquier vía por la que salgan datos. Willison advierte que basta con que una herramienta pueda hacer una petición HTTP, cargar una imagen o presentar un enlace para servir de canal de fuga.

La consecuencia práctica es una pregunta de diseño que puedes aplicar a cada agente: ¿combina las tres? Si la respuesta es sí, hay que quitar una de las patas. Willison señala además que los proveedores suelen corregir estos casos cerrando el canal de fuga, de modo que las instrucciones maliciosas ya no tengan por dónde sacar lo robado. Cuando eres tú quien mezcla herramientas, esa corrección no la hace nadie por ti.

¿Por qué MCP aumenta el riesgo de prompt injection en un agente?

Porque facilita combinar herramientas de orígenes distintos, y cada herramienta añadida puede aportar una de las tres patas de la tríada. Willison explica que el Model Context Protocol anima a mezclar herramientas que acceden a datos privados, que pueden alojar contenido malicioso y que pueden comunicarse con el exterior, a menudo todo en la misma herramienta.

Su ejemplo es el servidor MCP oficial de GitHub: podía leer incidencias públicas, que un atacante podía haber abierto, acceder a repositorios privados y crear pull requests de forma que exfiltraba esos datos. Las tres patas reunidas en una sola herramienta.

Para la seguridad de herramientas MCP, la guía de OpenAI recomienda mantener activadas las aprobaciones, de manera que una persona revise y confirme cada operación, tanto de lectura como de escritura. Antes de conectar un servidor MCP, trátalo como cualquier dependencia con privilegios: ¿qué lee, qué contenido ajeno ingiere y por dónde puede salir información?

¿Se puede evitar del todo la prompt injection?

No, al menos hoy. Ninguna de las fuentes primarias consultadas afirma que el problema esté resuelto, y varias dicen lo contrario de forma explícita.

• OWASP reconoce que, por la naturaleza estocástica de los modelos, no está claro que existan métodos infalibles de prevención, y propone medidas que mitigan el impacto.
• Anthropic publicó en noviembre de 2025 que, con Claude Opus 4.5 en uso de navegador, un atacante adaptativo interno con 100 intentos por entorno lograba una tasa de éxito del 1%. La propia Anthropic aclara que sigue siendo un riesgo significativo y que el problema no está resuelto.
• OpenAI, en su guía de seguridad para construir agentes, indica que incluso aplicando las mitigaciones los agentes pueden equivocarse o ser engañados, y que el aislamiento y las salidas estructuradas reducen el riesgo pero no lo eliminan.
• Willison desconfía de los productos "guardrail" que prometen detectar el 95% de los ataques: en seguridad web, ese porcentaje es una nota suspensa.

De aquí sale el principio de diseño de todo el artículo: asume que alguna inyección tendrá éxito y diseña para que el daño posible sea pequeño. Es la misma idea que vimos en la Parte 3: la seguridad debe vivir en el harness, no en la esperanza de que el modelo se comporte.

¿Qué es el principio de mínimo privilegio en un agente y cómo se aplica?

Consiste en dar al agente solo las funciones, los permisos y la autonomía estrictamente necesarios para su tarea. OWASP lo recoge como riesgo de Excessive Agency y señala tres causas raíz: funcionalidad, permisos y autonomía excesivos.

Aplicado a un agente real, se traduce en controles concretos que se implementan fuera del modelo:

OWASP propone ejemplos muy concretos. Un agente que recomienda productos solo necesita lectura sobre la tabla de productos, y esa restricción debe imponerse con los permisos de la identidad de base de datos, no con una instrucción en el prompt. Un asistente que resume correos no necesita poder enviarlos: si el plugin trae esa función, sobra. Con ese diseño, un correo malicioso que ordene reenviar el buzón completo se queda sin herramienta con la que hacerlo.

El registro y el límite de frecuencia no previenen el abuso, pero acortan su duración y lo hacen visible.

¿Cómo separar el contenido no confiable de las instrucciones del agente?

Nunca coloques contenido no confiable en un canal con privilegios, y limita por esquema lo que puede pasar de un paso al siguiente. Dos medidas concretas salen de las guías de OWASP y OpenAI.

1. No inyectar variables no confiables en los mensajes de más autoridad. OpenAI explica que los mensajes de desarrollador tienen prioridad sobre los de usuario y asistente, así que meter ahí entrada no confiable da al atacante el máximo control. Lo no confiable debe viajar en mensajes de usuario.
2. Usar salidas estructuradas entre pasos. Si entre dos fases del flujo solo circulan enumerados o campos con esquema fijo, se eliminan los canales de texto libre por los que una inyección podría colar instrucciones o datos. OpenAI recomienda extraer de la entrada externa solo campos específicos y validados.

OWASP añade identificar y separar claramente el contenido externo para limitar su influencia.

Un ejemplo ilustrativo de contrato entre un agente que lee contenido externo y otro que ejecuta acciones:

import { z } from "zod";

// Ejemplo ilustrativo: lo único que pasa al agente ejecutor son campos tipados.
const ExtractedData = z.object({
  productId: z.string().uuid(),
  priceFound: z.number().positive(),
  inStock: z.boolean(),
});

Los campos numéricos, booleanos o con formato fijo no pueden transportar frases. Cualquier campo de texto libre sí, así que conviene restringirlo con enumerados, longitudes máximas o formatos. Estas medidas reducen el riesgo, pero no lo eliminan, y conviene decirlo con esa claridad.

¿Cuándo debe intervenir un humano en un agente con herramientas?

Antes de cualquier acción irreversible, que envíe información fuera del sistema o que afecte a terceros: enviar, borrar, pagar, publicar. No hace falta aprobarlo todo, y esa es una de las ideas de la Parte 1: el humano en el bucle se reserva para las acciones sensibles.

OWASP pone como ejemplo una aplicación que publica contenido en redes sociales: la rutina de aprobación debe estar en la extensión que implementa la operación de publicar. OpenAI es más estricta para herramientas MCP: recomienda mantener activadas las aprobaciones para que la persona revise y confirme cada operación, tanto de lectura como de escritura.

Un criterio de diseño propio: la aprobación solo protege si quien aprueba ve la acción real, con destinatario y datos concretos, y no un resumen redactado por el mismo modelo que pudo ser manipulado. Un ejemplo ilustrativo de la diferencia:

# Resumen redactado por el modelo (no fiable):
  "¿Archivo los correos antiguos del servidor?"

# Llamada real que el harness intercepta y muestra tal cual:
tool: delete_records
args: { table: "customers", all: true }

¿Autorizar? [Sí] [No]

Quien lee solo el resumen aprueba un archivado inocuo; quien lee la llamada real detecta un borrado total. La aprobación debe renderizarse desde los parámetros validados que recibirá la función, no desde el texto del modelo.

¿Cómo probar que un agente resiste la prompt injection?

Trata al modelo como un usuario no confiable y prueba que los límites de confianza aguantan aunque el modelo falle. OWASP recomienda pruebas adversarias y simulaciones de ataque periódicas con ese enfoque, y OpenAI propone evaluaciones y calificación de trazas para ver dónde se equivoca el agente.

Una lista mínima, antes de registrar una herramienta nueva, ya sea mediante MCP o llamadas nativas:

1. ¿Qué datos privados puede leer con esta herramienta?
2. ¿Qué contenido de terceros entra en su contexto?
3. ¿Por qué canal puede salir información? ¿Puede hacer peticiones a dominios arbitrarios o solo a una lista de permitidos?
4. ¿Qué es lo peor que puede hacer si el modelo obedece una instrucción maliciosa?
5. ¿La autorización se comprueba en código, fuera del modelo? ¿Valida quién es el usuario autenticado o confía en el identificador que propone el modelo en los parámetros?
6. Si solo consulta datos, ¿se conecta con permisos de solo lectura a nivel del motor de base de datos?
7. ¿Queda registrada cada llamada, con fecha, llamante, herramienta, argumentos y resultado, para auditarla?
8. ¿Existen pruebas que inyecten entradas maliciosas en los parámetros y verifiquen que la capa de código las rechaza?

Y una prueba práctica: construir un conjunto pequeño de entradas maliciosas por herramienta y verificar, de forma determinista, que la capa de autorización las rechaza aunque el modelo las proponga. Si la defensa depende de que el modelo se niegue, no es una defensa.

Conclusión

La prompt injection no se elimina; se acota. Cada herramienta que das a un agente amplía lo que un texto malicioso puede lograr, así que el trabajo de diseño consiste en dar menos: menos funciones, menos permisos, menos autonomía y, sobre todo, nunca las tres patas de la tríada a la vez. Es la continuación natural de lo visto en las partes anteriores: gobernar la autonomía, controlar la ejecución y tratar el harness como el lugar donde vive la seguridad.

Preguntas frecuentes

¿Es lo mismo prompt injection que jailbreak?

Están relacionados, pero no hay consenso total en cómo nombrarlos. OWASP trata el jailbreak como una forma de prompt injection en la que el atacante logra que el modelo ignore sus protocolos de seguridad. Willison los considera problemas distintos: la inyección explota la mezcla de contenido fiable y no fiable en el mismo contexto, mientras que el jailbreak busca que el modelo diga algo indebido. Para un agente con herramientas, la inyección es la que más importa.

¿Basta con decirle al modelo en el prompt que ignore las instrucciones maliciosas?

No. OWASP recomienda acotar el comportamiento del modelo en el prompt como una medida más, pero no como defensa única. Willison pregunta qué confianza se puede tener en que esa protección funcione siempre, dado el número infinito de formas de redactar una instrucción maliciosa.

¿Son suficientes los guardrails y clasificadores de detección?

Son una capa útil, pero no deben ser la única. Anthropic combina entrenamiento, clasificadores y pruebas con equipos humanos y aun así afirma que el problema no está resuelto. OpenAI describe sus propios guardrails como una primera línea de protección, no como una solución infalible.

¿Qué es la excesiva agencia (excessive agency) en un agente de IA?

Es la vulnerabilidad que permite acciones dañinas como respuesta a salidas inesperadas, ambiguas o manipuladas del modelo, sea cual sea la causa. OWASP identifica como raíz típica el exceso de funcionalidad, de permisos o de autonomía.

Esta es la cuarta parte de una serie sobre arquitectura de sistemas agénticos. Las anteriores cubren autonomía frente a autoridad de ejecución, tool calling, idempotencia y observabilidad y modelo frente a harness. Continúa también la línea de nuestra guía sobre desarrollo agéntico en equipos de software.

Fuentes técnicas

• LLM01:2025 Prompt Injection, OWASP Gen AI Security Project: genai.owasp.org
• LLM06:2025 Excessive Agency, OWASP Gen AI Security Project: genai.owasp.org
• The lethal trifecta for AI agents, Simon Willison (16-jun-2025): simonwillison.net
• Mitigating the risk of prompt injections in browser use, Anthropic (24-nov-2025): anthropic.com
• Safety in building agents, OpenAI API Docs: developers.openai.com