Equipo rojo de AgentRedTeam y OWASP LLM01

Por qué los agentes cambian la matemática de inyección

De la salida a la acción

En un chatbot puro, el objetivo de una inyección es hacer que el modelo diga algo que no debería decir. El impacto se detiene en el texto que sale del modelo. Cuando el mismo modelo puede invocar una herramienta, el texto inyectado puede convertirse en un comando que la herramienta ejecuta. Un atacante que puede dirigir una herramienta de lectura de archivos para obtener un documento confidencial, o una herramienta de envío de correo para reenviar ese documento, ha convertido un truco de palabras en una violación de datos. La gravedad depende, por lo tanto, de lo que la herramienta puede hacer, no de lo ingenioso que sea la respuesta.

El alcance de la herramienta define el radio de acción

El radio de acción es la unión de todos los recursos que las herramientas del agente pueden tocar. Si el agente solo tiene una API de solo lectura para un blog público, el peor caso es filtrar información pública. Si el agente puede llamar a una herramienta de escritura de base de datos, una herramienta de eliminación de sistema de archivos o una pasarela de pago externa, la misma inyección podría borrar registros, alterar saldos o mover dinero. El trabajo de equipo rojo debe asignar cada herramienta a los almacenes de datos, servicios o hardware que puede afectar, y luego probar si una inyección puede llegar a esos activos.

Conceptos erróneos comunes

- Asumir que la longitud de la salida del modelo limita el daño - falso, porque una cadena corta puede desencadenar una llamada a una herramienta destructiva. - Creer que filtrar el mensaje del usuario es suficiente - falso, porque las inyecciones pueden llegar dentro de los resultados de la herramienta o las solicitudes del sistema. - Pensar que un modelo de bajo parámetro es seguro - falso, cuando ese modelo se empareja con un conjunto de herramientas poderosas.

Para una referencia rápida sobre codificación defensiva, consulte la hoja de trucos de OWASP sobre prevención de inyección de instrucciones de LLM.

Superficies para probar más allá del cuadro de chat

Solicitud del sistema y configuración

La solicitud del sistema a menudo contiene claves de API, URL de servicio o lenguaje de política interna. Un atacante que pueda inyectar en esta área puede obtener credenciales directas o aprender dónde apuntar pruebas adicionales. Revise la solicitud para cualquier secreto estático y pruebe si se pueden eco o exfiltrar a través de una llamada a una herramienta.

Esquemas de herramientas y validación de argumentos

Cada herramienta expuesta define un esquema JSON para sus entradas. Si el esquema acepta cadenas de forma libre sin validación estricta, un atacante puede incrustar comandos dentro de esas cadenas. Por ejemplo, una herramienta "run_sql" que toma una cadena de consulta raw es vulnerable a inyección de SQL a menos que la capa del agente sanitice o parametice la entrada. Verifique si el agente impone límites de tipo, límites de longitud o listas de permitidos en cada argumento.

Tuberías de generación aumentada de recuperación (RAG)

Cuando el agente recupera datos de fuentes externas - páginas web, correos electrónicos, sistemas de tickets -, esos datos se convierten en parte del contexto del modelo. Un atacante que controle alguna de esas fuentes puede colocar instrucciones que el modelo tratará como confiables. Pruebe envenenando una fuente de alimentación externa conocida y observando si el agente actúa en el comando oculto.

Propagación de instrucciones dentro de los resultados de la herramienta

Algunos diseños devuelven la salida de la herramienta directamente en la siguiente llamada al modelo sin re-sanitizar. Si una herramienta devuelve un fragmento de texto que incluye una nueva instrucción, el modelo puede obedecerla en el siguiente paso. Esto crea una inyección de dos etapas donde la primera etapa es datos de aspecto benigno y la segunda etapa es el comando malicioso. Pruebe cada ruta de salida de la herramienta para ver si el agente re-alimenta resultados raw en el generador de solicitudes.

Lista de verificación práctica

- Extraiga la solicitud del sistema y busque secretos codificados. - Enumere cada herramienta, anote su esquema y trate de pasar tipos de datos inesperados. - Identifique todas las fuentes de datos externas utilizadas para RAG e inyecte marcadores benignos para verificar el alcance. - Capture las salidas de la herramienta y alimentelas nuevamente como nuevas entradas para ver si el agente las trata como comandos. - Documente cualquier cadena donde un solo mensaje del usuario conduce a múltiples invocaciones de herramientas.

Para comparar con defensas de inyección clásicas, la hoja de trucos de inyección de SQL ofrece patrones útiles: OWASP A03:2021 - Inyección.

El exceso de agencia es el riesgo companion

Qué significa el exceso de agencia

OWASP coloca la Excesiva Agencia en LLM03 para 2026. Describe agentes que pueden realizar acciones irreversibles - enviar correo electrónico, eliminar archivos, ejecutar código - sin un paso de aprobación separado. El riesgo crece cuando la autonomía del modelo supera las salvaguardas alrededor de sus herramientas.

Áreas de enfoque del equipo rojo

- Verificar si las herramientas destructivas requieren una confirmación explícita de un humano o un servicio separado. - Intentar encadenar dos o más herramientas juntas utilizando solo salidas intermedias generadas por el modelo. - Verificar si el agente puede elevar sus propios privilegios, por ejemplo, llamando a una herramienta que actualiza su propia clave de API. - Probar los desencadenadores basados en tiempo: ¿se puede utilizar una llamada a una herramienta retrasada para evitar un límite de velocidad o una expiración de sesión?

Matriz de riesgos ilustrativa

Categoría de herramienta | Privilegio típico | Confirmación necesaria | Abuso potencial si falta Lectura de archivo | Acceso de solo lectura a carpetas designadas | Ninguna (la lectura suele ser segura) | Exfiltración de registros, código fuente, configuración Escritura de archivo | Crear o sobrescribir archivos | Sí - aprobación de usuario o solicitud firmada | Inserción de puertas traseras, corrupción de datos Escritura en base de datos | INSERTAR/ACTUALIZAR/ELIMINAR en tablas | Sí - aprobación de transacción o autenticación de múltiples factores | Pérdida de datos, fraude financiero, escalada de privilegios HTTP externo | Red de salida a dominios arbitrarios | Sí - comprobación de lista de permitidos | Exfiltración de datos, señalización de C2, SSRF Ejecución de código | Shell o intérprete arbitrario | Sí - aislamiento de sandbox + aprobación | Compromiso total del host, implementación de ransomware

La tabla muestra por qué un equipo rojo debe verificar cada fila: si la columna de confirmación falta, el agente puede pasar de benigno a dañino con una sola entrada envenenada.

Qué debe contener un informe de prueba

Campos esenciales

Un hallazgo útil necesita más que un booleano "pass/fail". Registre la exacta locución del usuario que activó la cadena, la lista ordenada de herramientas que el agente llamó y el efecto observable final (por ejemplo, un archivo escrito, una solicitud de red enviada, una fila de base de datos cambiada). Incluya los argumentos de herramienta raw como se enviaron y la traza de razonamiento interno del modelo si su marco lo expone.

Guía de gravedad

- Baja - fuga de información pública o cambio de estado reversible. - Media - acceso a datos internos que no están regulados, o una acción reversible que requiere restablecimiento manual. - Alta - alteración de datos regulados, transacción financiera o ejecución de código arbitrario. - Crítica - puerta trasera persistente, destrucción de datos o capacidad de mantener una posición después de que finaliza la sesión.

Priorizar correcciones para hallazgos de alta y crítica primero; los elementos de baja gravedad se pueden abordar en un sprint de endurecimiento posterior.

Pistas de remedio accionables

- Agregar validación a nivel de esquema que rechace cadenas que contengan palabras clave SQL o metacaracteres de shell. - Envolver herramientas destructivas en un microservicio que demande un token de aprobación firmado. - Implementar una lista de permitidos de salida para llamadas HTTP de salida y registrar cada conexión intentada. - Sanitizar las salidas de herramientas antes de que se vuelvan a insertar en la locución del modelo - eliminar o escapar cualquier contenido que se parezca a una instrucción. - Utilizar una réplica de solo lectura para cualquier herramienta de consulta de base de datos a menos que se requiera explícitamente una escritura.

El trabajo de equipo rojo no sustituye los controles de diseño

Por qué las pruebas complementan, no reemplazan, las salvaguardas

El trabajo del equipo rojo descubre brechas que ya existen en la implementación. No crea las garantías que provienen del diseño de herramientas con privilegios mínimos, puertas de confirmación o segmentación de red. Trate cada prueba como un paso de validación: si los controles detienen la cadena inyectada, tiene evidencia de que funcionan; si no lo hacen, tiene un defecto concreto que solucionar.

Controles para priorizar

- Ejecute cada herramienta bajo un usuario de sistema operativo dedicado con el conjunto mínimo de capacidades del sistema de archivos. - Requiera un servicio de aprobación separado para cualquier llamada que pueda modificar el estado, registre la decisión y aplique un tiempo de espera. - Aplicar políticas de red que limiten las conexiones salientes a servicios internos conocidos y una lista corta de API externas. - Cifre los secretos en reposo y nunca los coloque en el sistema de prompts; use un servicio de bóveda en su lugar. - Registre cada invocación de herramienta con ID de usuario, marca de tiempo, hash de entrada y hash de salida para revisión forense.

Cuando estos controles estén en su lugar, los hallazgos del equipo rojo cambian de “encontramos una forma de romperlo” a “intentamos X y los controles lo bloquearon”, lo que es una señal de mayor madurez de seguridad.

Qué no es esto

No hay garantía de exhaustividad

Esta guía no promete que seguir los pasos atrapará cada posible inyección. Técnicas novedosas, vulnerabilidades de herramientas de día cero o características de agente no divulgadas pueden eludir las comprobaciones descritas aquí.

No es una solución al 100 %

Aplicar las mitigaciones reduce el riesgo pero no lo elimina. La defensa en profundidad requiere una supervisión continua, revisiones regulares de la cadena de herramientas y actualizaciones cuando aparecen nuevas versiones de OWASP.

La afirmación de no perderse nada es falsa

Ningún método de equipo rojo puede afirmar que nunca se perderá un error. El objetivo es aumentar el costo para un atacante y hacer que la explotación exitosa sea perceptible y rastreable.

No es un reemplazo para la codificación segura

Las recomendaciones asumen que ya sigue las prácticas básicas de codificación segura – validación de entrada, codificación de salida y principio de privilegios mínimos. Agregan capas específicas de agente sobre esa base.

Referencias

- https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html - https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html - https://genai.owasp.org/llmrisk/llm01-prompt-injection - https://owasp.org/Top10/2021/A03_2021-Injection

Artículos relacionados

- Pruebas de abuso de herramientas para agentes LLM - Explorar la matriz completa de temas de AI micro-SaaS →