Un chatbot recibe texto y devuelve texto. Un agente de IA puede recibir una solicitud, consultar documentos, llamar APIs, decidir qué herramienta usar y modificar un sistema en nombre de alguien. Esa diferencia cambia el modelo de amenazas. El riesgo ya no termina en una respuesta incorrecta: alcanza cada dato, credencial y operación disponible durante la ejecución.
Cuando el chat se convierte en un plano de control
La arquitectura típica conecta el modelo con un orquestador, memoria, un mecanismo de búsqueda, APIs internas y servicios de terceros. Cada conexión agrega una frontera de confianza. Una instrucción puede llegar del usuario, pero también de un correo, un documento recuperado, una respuesta de API o el mensaje de otro agente. Si el modelo puede convertir ese contenido en una llamada de herramienta, cualquier entrada no confiable puede intentar influir en una acción privilegiada.
Los permisos excesivos convierten un error en impacto
OWASP describe la agencia excesiva a partir de tres causas: funcionalidad, permisos y autonomía excesivos. Un agente creado para resumir tickets no necesita editar usuarios, ejecutar consultas arbitrarias ni enviar mensajes. Aun así, la integración suele reutilizar una cuenta de servicio amplia porque es más rápido para la POC. En ese diseño, el modelo no rompe la autorización. Simplemente usa una credencial que ya recibió demasiada autoridad.
- Expón al agente solo las herramientas necesarias para el caso de uso, sin shell ni cliente HTTP genérico cuando una función específica sea suficiente
- Separa lectura, creación, modificación y eliminación en operaciones distintas con sus propios alcances
- Ejecuta cada acción en el contexto del usuario o mediante una identidad dedicada a la función, nunca con una cuenta administrativa compartida
- Exige aprobación independiente para acciones destructivas, financieras, administrativas o visibles externamente
- Aplica límites de llamadas, tiempo, costo, profundidad de cadena y volumen por sesión
Un secreto en el contexto sigue siendo un secreto expuesto
Las claves de API, los tokens OAuth y las credenciales de base de datos no deberían aparecer en el prompt, la memoria, la salida de herramientas ni los logs sin filtrar del agente. El modelo necesita el resultado de una operación autorizada, no el secreto que la autoriza. Un gateway de herramientas puede obtener la credencial de una bóveda, llamar al servicio y devolver solo los campos permitidos. Los tokens de corta duración, los alcances mínimos y la rotación reducen el tiempo y el alcance de una fuga.
La misma regla se aplica a los datos de negocio. Antes de construir el contexto, la aplicación debe aplicar autorización por usuario y objeto, clasificación, minimización y enmascaramiento. Recuperar un documento por similitud no demuestra que el solicitante pueda leerlo. Si el filtro de autorización ocurre después de la recuperación, los datos de otra área o tenant pueden haber entrado ya al contexto y reaparecer en la respuesta o en una llamada externa.
Las entradas y salidas necesitan contratos separados
Toda entrada externa debe tratarse como dato no confiable, incluidas las respuestas de APIs consideradas socias. Validar tamaño, tipo, formato y origen reduce ambigüedades, pero no resuelve por sí solo la prompt injection. La decisión importante es arquitectónica: el contenido recuperado no puede ampliar permisos, habilitar una herramienta ni eliminar una aprobación exigida por la política.
La salida del modelo también es la entrada de otro componente. SQL, HTML, rutas de archivo, destinatarios de correo y argumentos de herramientas deben pasar por schema, listas permitidas, encoding y autorización antes de usarse. OWASP llama a este problema Improper Output Handling. Confiar en la fluidez de una respuesta como si fuera validación permite que una salida manipulada alcance un intérprete o una API privilegiada.
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"type": "object",
"properties": {
"tool": { "const": "crm.read_contact" },
"contact_id": {
"type": "string",
"pattern": "^[a-z0-9-]{1,64}$"
}
},
"required": ["tool", "contact_id"],
"additionalProperties": false
}Una integración de terceros forma parte de la cadena de ataque
Plugins, conectores, servidores MCP, modelos, bases vectoriales y APIs SaaS forman parte de la cadena de suministro del agente. NIST AI 600-1 recomienda inventariar a terceros con acceso al contenido de la organización, evaluar riesgos de proveedores, mantener monitoreo y preparar la respuesta a incidentes. En la práctica, no basta con preguntar si el proveedor cifra los datos. Es necesario saber qué datos recibe, dónde se almacenan, por cuánto tiempo se retienen, quién puede invocar la integración y qué ocurre cuando falla o es comprometida.
- Mantén un inventario de modelos, herramientas, APIs, fuentes de datos y responsables de cada integración
- Fija versiones y verifica el origen, las firmas y los cambios de conectores cuando el ecosistema ofrezca esos controles
- Define timeout, reintentos limitados, circuit breaker y un comportamiento seguro ante respuestas ausentes o malformadas
- Elimina herramientas experimentales que ya no sean necesarias y revoca sus credenciales
- Planifica cómo desactivar el conector y preservar evidencia sin depender del propio proveedor afectado
Sin trazabilidad no existe una investigación confiable
Registrar solo la conversación no es suficiente. Una investigación debe reconstruir qué versión del agente estaba activa, quién inició la sesión, qué identidad se usó, qué fuentes entraron al contexto, qué herramienta se solicitó, qué parámetros se normalizaron, qué política decidió, quién aprobó y cuál fue el resultado. Los logs deben preservar correlación e integridad sin almacenar tokens ni datos sensibles innecesarios.
- Identificadores de sesión, usuario, agente, modelo, prompt de sistema y versión de la política
- Fuente y clasificación de los datos recuperados, con el contenido sensible enmascarado
- Herramienta, objetivo, parámetros normalizados, decisión de autorización e identificador de la aprobación
- Resultado, error, latencia, cantidad de intentos y activación de límites o circuit breaker
- Alertas por herramientas inusuales, rechazos repetidos, aumento de privilegios y volumen fuera del patrón esperado
Criterios prácticos para una POC segura
Una POC sirve para reducir incertidumbre, no para heredar silenciosamente controles de producción. Puede operar con datos sintéticos, un entorno aislado y un alcance estrecho. Antes de conectar datos reales o habilitar usuarios, define criterios verificables de entrada y salida. La propia OWASP recomienda pruebas estructuradas antes de producción y después de cambios relevantes en prompts, herramientas, memoria, recuperación, políticas o proveedor del modelo.
- El caso de uso, los usuarios, los datos, las herramientas y las acciones permitidas están documentados
- Los datos sintéticos o minimizados sustituyen la información sensible siempre que sea posible
- Cada credencial es dedicada, de corta duración, revocable y restringida al recurso necesario
- Las salidas estructuradas fallan de forma cerrada cuando no pasan el schema o la autorización
- Las acciones de alto impacto exigen una aprobación vinculada al objetivo y a los parámetros exactos
- Prompt injection directa e indirecta, abuso de herramientas, escalada de privilegios, exfiltración y envenenamiento de memoria tienen casos de prueba repetibles
- Los límites interrumpen loops, repeticiones, consumo y cadenas de herramientas fuera de lo esperado
- Los logs permiten reconstruir la decisión sin exponer secretos
- Existe un responsable de detener la POC, revocar accesos y atender incidentes
El pentest comienza en las fronteras, no en el prompt
Evaluar únicamente si el modelo rechaza un jailbreak deja sin probar la mayor parte de la superficie. Un pentest de agentes debe atravesar la aplicación, las APIs, el mecanismo de autorización, la memoria, las herramientas y los servicios de terceros. Probamos si una entrada controlada puede cambiar una decisión y, sobre todo, si los controles externos al modelo impiden que esa decisión se convierta en acceso, modificación o salida de datos no autorizada.
Para una empresa que decide si la POC puede avanzar, la pregunta útil no es si el agente parece inteligente. Es si el sistema sigue siendo seguro cuando el modelo se equivoca, es manipulado o recibe una respuesta malformada. Ahí es donde una revisión de arquitectura y un pentest orientado al abuso producen evidencia para la decisión de producción. Referencias técnicas consultadas: OWASP Top 10 for LLM Applications 2025, OWASP AI Agent Security Cheat Sheet y NIST AI 600-1.