Intro

El prompt injection no se vuelve peligroso solamente porque un modelo pueda responder algo incorrecto. Se vuelve mucho mas serio cuando ese modelo puede actuar.

En un chatbot aislado, una instruccion maliciosa puede terminar en una respuesta mala, una fuga parcial de contexto o una negativa mal resuelta. Eso ya importa, pero el radio de impacto sigue relativamente contenido: el sistema genera texto.

En un agente con herramientas, el problema cambia de categoria.

Ese mismo texto puede influir en una llamada a una tool, una lectura de archivos, una consulta a una base, un envio de email, una accion en un CRM, una operacion sobre GitHub, una navegacion web o un comando de shell. Ahi la pregunta deja de ser "que contesto el modelo?" y pasa a ser:

Que estuvo a punto de hacer el sistema porque un texto no confiable lo convencio?

Esa frontera es la que muchas defensas siguen tratando demasiado tarde.

El error: pensar que el problema vive solo en el prompt

La forma simple de explicar prompt injection es decir que alguien mete instrucciones hostiles dentro del contexto del modelo para alterar su comportamiento.

Eso es correcto, pero queda corto.

OWASP describe el problema como una manipulacion de modelos mediante prompts maliciosos o enganosos, incluyendo variantes directas e indirectas donde la instruccion aparece dentro de contenido externo como una pagina, documento o email. OpenAI, en su analisis sobre agentes, lo plantea como instrucciones ubicadas en contenido externo que intentan hacer que el modelo haga algo que el usuario no pidio.

La parte incomoda esta en la palabra "externo".

Para un agente moderno, casi todo puede ser externo:

  • una pagina web que el browser visita;
  • un ticket de soporte;
  • un email;
  • un documento recuperado por RAG;
  • un issue de GitHub;
  • un README dentro de un repositorio;
  • una descripcion de una tool;
  • una respuesta de una API;
  • un comentario en una pull request;
  • un PDF;
  • una tabla interna;
  • un resultado de busqueda.

Si el agente usa ese contenido para decidir que hacer despues, el contenido ya no es solamente informacion. Es parte del entorno de decision.

Y ese entorno puede ser hostil.

Chatbot, RAG, agente: tres niveles de riesgo

Conviene separar tres escenarios.

Chatbot

El usuario habla con un modelo que responde texto. El atacante intenta que ignore reglas, revele instrucciones internas o conteste algo que no deberia.

El riesgo existe, pero normalmente vive en la salida.

RAG

El sistema recupera documentos y los mete en contexto. Ahora el atacante puede esconder instrucciones en una fuente que el usuario quizas ni ve: una pagina indexada, un documento compartido, una nota interna, metadata o HTML oculto.

El riesgo ya no depende solo del input directo del usuario. La inyeccion puede venir por una fuente recuperada.

Agente con tools

El modelo no solo lee y responde. Tambien decide si llama herramientas.

Ese agente puede tener acceso a:

  • filesystem;
  • browser;
  • email;
  • calendario;
  • CRM;
  • base de datos;
  • repositorio;
  • CI/CD;
  • shell;
  • MCP servers;
  • APIs internas.

En ese punto, el prompt injection deja de ser un problema de conversacion y pasa a ser un problema de ejecucion.

El fallo serio no es que el modelo diga "voy a exfiltrar datos". El fallo serio es que el sistema le permita llamar la tool que efectivamente los envia.

Por que los filtros no alcanzan

Una respuesta comun frente a prompt injection es agregar filtros:

  • bloquear frases como "ignore previous instructions";
  • detectar palabras sensibles;
  • usar regex;
  • agregar una regla al system prompt;
  • pedirle al modelo que no obedezca instrucciones externas;
  • revisar solo el output final.

Todo eso puede ayudar como capa secundaria, pero no alcanza como control principal.

Hay tres razones.

La primera es que el texto malicioso no necesita verse malicioso. Puede parecer una instruccion administrativa, una nota de soporte, una aclaracion tecnica, una politica interna falsa o un comentario dentro de una tarea legitima.

La segunda es que el ataque puede ser indirecto. El usuario puede pedir algo inocente como "resumi este ticket" o "corre los tests". El payload vive en el ticket, en el repo, en el documento o en la pagina que el agente consume.

La tercera es que, cuando hay tools, el output final puede llegar demasiado tarde. Si la accion peligrosa ya se ejecuto, una alerta en el dashboard despues del hecho no es defensa. Es evidencia.

La defensa importante tiene que ubicarse antes de la ejecucion.

El punto de control esta entre decision y accion

El lugar critico en un agente no es solamente el input.

Tampoco es solamente el output.

El lugar critico es el borde donde una decision del modelo se convierte en una accion real:

contenido no confiable -> razonamiento del agente -> tool call -> efecto externo

Ese camino se parece mucho mas a un problema de source-to-sink que a un problema de moderacion de texto.

La fuente puede ser un email, una web, un issue o un documento. El sink puede ser una tool que envia datos, ejecuta comandos, escribe archivos, modifica estado o llama una API externa.

Si no hay control en ese borde, el sistema queda dependiendo de que el modelo siempre distinga dato de instruccion, siempre recuerde sus limites y siempre resista manipulacion contextual.

Ese no es un supuesto solido para produccion.

Adrian como ejemplo de defensa runtime

Un video reciente de Matt Johansen, de Vulnerable U, muestra una herramienta open source llamada Adrian, de Secure Agentics. El interes del video no esta en que Adrian sea "la solucion definitiva" al prompt injection. No lo es, y ninguna herramienta seria deberia venderse asi.

Lo interesante es donde se ubica la defensa.

Adrian se presenta como una capa de runtime security para agentes. Segun su documentacion, analiza actividad del agente, tool calls, acciones, outputs y trazas de razonamiento cuando estan disponibles. Puede operar en modo alerta, modo bloqueo o human review. Tiene SDK para LangChain/LangGraph, SDK TypeScript y plugin para Claude Code.

Eso lo pone en una categoria distinta a un filtro de palabras.

En vez de preguntar solamente:

Este prompt parece malicioso?

la pregunta se vuelve:

Esta accion encaja con el remit del agente y el contexto de la tarea?

Ese cambio es importante.

Un agente de soporte puede estar autorizado a leer tickets y responder al cliente que abrio el caso. Eso no significa que este autorizado a enviar un paquete de datos de clientes a una direccion externa.

Un agente de coding puede estar autorizado a leer archivos del repositorio, modificar codigo y correr tests. Eso no significa que deba leer ~/.ssh, exportar variables de entorno, tocar credenciales cloud o ejecutar comandos de red fuera del flujo esperado.

La diferencia no siempre se detecta con regex. Se detecta entendiendo el trabajo del agente y el riesgo de la accion.

Lo que muestra el showcase

El video recorre varios casos utiles para entender el problema.

Primero, muestra el riesgo general: navegadores con IA, agentes embebidos en aplicaciones, chatbots de soporte, tickets, LinkedIn, Reddit, emails e issues de GitHub como fuentes potenciales de instrucciones indirectas.

Despues, muestra el flujo de Adrian con Claude Code. Se configura el plugin, se verifica el modo de bloqueo y se prueba una accion normal: listar archivos del proyecto. Esa accion pasa.

Luego se intenta algo mas sensible: acceder a material de .ssh. Ahi Adrian clasifica la accion como alta severidad y la bloquea antes de que se ejecute.

Ese ejemplo es chico, pero pedagogicamente bueno. No hace falta dramatizarlo. Un agente de coding puede necesitar shell y filesystem para trabajar. Justamente por eso el control no puede ser "prohibir todo". Tiene que distinguir trabajo normal de accion fuera de remit.

El segundo caso es mas cercano a producto. El video habla de un agente de soporte construido con LangChain que lee tickets. Dentro de un ticket puede esconderse una instruccion hostil. Si el agente mezcla contenido del ticket con instrucciones operativas, puede terminar enviando datos de clientes a un destinatario no autorizado.

Ese es el patron que deberia preocupar a cualquier empresa que esta metiendo agentes en workflows internos:

ticket no confiable -> agente de soporte -> email/export tool -> fuga de datos

El tercer caso, mas ofensivo y tratado como laboratorio controlado, involucra un flujo de coding donde una instruccion escondida en el entorno del proyecto intenta empujar al agente hacia ejecucion no autorizada. En el video se compara la ejecucion sin Adrian y con Adrian. Sin control runtime, el agente puede avanzar hacia una accion peligrosa. Con Adrian activo, la accion se bloquea como evento de alta severidad.

No hace falta publicar payloads ni comandos para que el aprendizaje sea claro. El punto no es la receta ofensiva. El punto es el modelo de riesgo:

contenido del repo -> agente con shell -> ejecucion no prevista

Los agentes de desarrollo son especialmente delicados porque combinan lectura de codigo, escritura de archivos, package managers, git, tests, CI/CD y a veces credenciales locales. Un prompt injection escondido en un issue, README, comentario, test o archivo de configuracion puede transformarse en una orden que el agente intenta ejecutar.

Remit: la politica que muchos agentes no tienen

Una palabra clave en este tipo de defensa es remit: el alcance legitimo del agente.

No alcanza con decir "este agente puede usar email" o "este agente puede usar shell". Hay que definir para que, en que contexto y con que limites.

Por ejemplo, para un agente de soporte:

  • puede leer el ticket activo;
  • puede consultar una base de conocimiento;
  • puede responder dentro del mismo hilo;
  • puede escalar a un humano;
  • no puede enviar datos a destinatarios externos no vinculados al ticket;
  • no puede leer masivamente registros de clientes;
  • no puede ejecutar comandos o llamar webhooks arbitrarios.

Para un agente de coding:

  • puede leer y modificar archivos dentro del repo;
  • puede correr tests y builds;
  • puede usar package managers dentro del workspace;
  • puede consultar documentacion tecnica;
  • no puede leer credential stores del sistema;
  • no puede subir secretos;
  • no puede modificar pipelines protegidos sin aprobacion;
  • no puede hacer outbound calls que no tengan relacion con desarrollo.

Esta politica no deberia vivir solo como una frase aspiracional en el prompt. Tiene que influir en permisos, tools expuestas, validaciones, approvals, logs y runtime enforcement.

Alertar, pedir aprobacion o bloquear

No todas las acciones tienen el mismo riesgo.

Un sistema maduro deberia distinguir al menos tres respuestas:

Alert mode

El agente sigue operando, pero el sistema registra eventos y clasificaciones. Sirve para aprender como se comporta el agente en trafico real o en pruebas controladas sin romper workflows.

Es el modo razonable para empezar.

Human review

La accion queda pausada hasta que una persona aprueba o rechaza. Tiene sentido para operaciones raras, sensibles, reversibles con costo o ambiguas.

El approval tiene que mostrar contexto suficiente: que tool se iba a llamar, con que argumentos, que fuente influyo, cual es el efecto esperado y por que se marco riesgo.

Block mode

La accion se niega antes de ejecutarse. Tiene sentido para patrones claramente fuera de remit: exfiltracion, credenciales, escritura destructiva, ejecucion no autorizada, cambios en produccion o acciones externas sin consentimiento.

El bloqueo no deberia ser una caja negra. Si el equipo no entiende por que se bloqueo, va a terminar apagando el control.

Lo que Adrian resuelve y lo que no

Adrian es interesante porque mueve la discusion hacia donde tiene que estar: runtime, acciones, contexto y control antes de ejecutar.

Pero no conviene convertirlo en fetiche.

Hay limites importantes.

Si el backend de clasificacion no esta disponible y el plugin esta configurado en fail-open, las herramientas pueden seguir ejecutando. Eso puede ser aceptable para disponibilidad, pero no para todos los entornos.

Si el framework o el modelo no exponen suficiente contexto o trazas de razonamiento, la calidad del analisis puede bajar.

Si el clasificador es otro LLM, tambien puede equivocarse. Va a haber falsos positivos y falsos negativos. Por eso el control tiene que combinarse con permisos reales, sandboxing, scopes, validaciones y observabilidad.

Ademas, la propia documentacion del SDK marca un punto importante: los outputs de tools no se clasifican directamente como accion inicial; si un output trae contenido malicioso, se ve en el siguiente turno del modelo, cuando intenta inducir otra llamada. Eso puede funcionar para cortar la cadena, pero no reemplaza controles deterministicos dentro de cada tool.

La conclusion correcta no es "instala una herramienta y listo".

La conclusion correcta es:

La seguridad de agentes necesita controles alrededor del modelo,
no solo instrucciones dentro del modelo.

Checklist practico para equipos

Si una empresa esta desplegando agentes con tools, deberia revisar estas preguntas antes de hablar de autonomia:

  • Que fuentes de contenido no confiable lee el agente?
  • Que tools puede llamar?
  • Cuales de esas tools tienen efectos externos?
  • Que credenciales hereda?
  • Puede leer mas datos de los necesarios?
  • Puede escribir o modificar estado?
  • Puede enviar informacion fuera del sistema?
  • Hay separacion entre lectura y accion?
  • Hay scopes distintos para staging y produccion?
  • Hay logs por tool call, argumentos y decision?
  • Hay approvals para acciones irreversibles o sensibles?
  • Hay modo audit antes de activar bloqueo?
  • Se prueban indirect prompt injections en tickets, documentos, issues, paginas y outputs de tools?
  • Que pasa si el clasificador falla o no responde?
  • Que acciones estan bloqueadas deterministicamente aunque el modelo insista?

La pregunta mas importante es esta:

Si un texto hostil logra influir en el agente, cual es el peor efecto real que puede causar?

Esa respuesta define el diseno.

El modelo mental correcto

Prompt injection no se elimina con un prompt mejor.

Se reduce con arquitectura.

Eso implica:

  • tratar contenido externo como dato no confiable;
  • separar instrucciones de evidencia;
  • minimizar privilegios;
  • disenar tools con contratos estrictos;
  • validar argumentos fuera del modelo;
  • aplicar approvals proporcionales al riesgo;
  • aislar ejecucion;
  • monitorear acciones en runtime;
  • bloquear sinks peligrosos antes de que produzcan efectos.

El valor de herramientas como Adrian es que empujan el debate en esa direccion. No prometen que el modelo se vuelva inmune a manipulacion. Intentan que, cuando la manipulacion ocurre, el agente no pueda convertirla facilmente en accion peligrosa.

Esa es una diferencia enorme.

Porque en agentes, la seguridad no se mide solo por lo que el modelo entiende.

Se mide por lo que el sistema le permite hacer.

Fuentes