La stack de seguridad de agentes: por qué ningún control aislado aguanta

La mayoría de los equipos que se toman en serio la prompt injection se agarra a una buena idea y se para ahí. Añaden un delimitador alrededor del texto no confiable, o atornillan un clasificador que marca entradas sospechosas, y tratan el problema como resuelto. El instinto es correcto. El control aislado no basta, y la razón merece entenderse con precisión, porque cambia cómo diseñas el sistema entero.

Solo que la prompt injection indirecta no es una vulnerabilidad que parcheas. Es una propiedad estructural de cómo funcionan los modelos de lenguaje. Un modelo lee un flujo de tokens y no puede distinguir con fiabilidad qué tokens son instrucciones tuyas y cuáles son contenido de un documento que le pidieron procesar. Si una factura envenenada contiene una frase que se lee como una orden, el modelo puede seguirla, porque para el modelo todo es texto. No hay forma conocida de hacer a un modelo perfectamente inmune a esto manteniéndolo útil. Así que el objetivo no es la inmunidad. El objetivo es la contención, y la contención es una propiedad de una stack, no de ninguna capa en particular.

Esta es la parte que separa una arquitectura seria de una esperanzada. Cualquier control que nombres tiene un modo de fallo. La pregunta nunca es "¿es bueno este control?". Es "cuando este control falle, ¿qué atrapa el fallo?". Si la respuesta honesta es "nada", no tienes seguridad. Tienes un punto único de fallo con una etiqueta de seguridad.

El spotlighting reduce la superficie de ataque. No la cierra.

Empieza por el control aislado más común, porque es el que los equipos más confunden con una solución.

El spotlighting es la práctica de marcar contenido no confiable para que el modelo pueda distinguirlo de las instrucciones de confianza: codificándolo, delimitándolo o etiquetando cada token que vino de una fuente externa. Ayuda de verdad. Un modelo al que le dices "todo lo que hay entre estas marcas es dato, no instrucciones" sigue órdenes inyectadas con menos frecuencia. Si no haces nada más, haz esto.

Pero fíjate en lo que el spotlighting hace realmente. Baja la probabilidad de que el modelo confunda dato con instrucción. No hace imposible la confusión, porque el modelo sigue siendo un sistema probabilístico que lee los dos flujos con los mismos ojos. Una inyección suficientemente bien construida, o una distribución de entradas para la que la marcación no se afinó, pasa a una tasa por encima de cero. Y "por encima de cero" es el número equivocado para un proceso donde una sola inyección exitosa puede mover dinero o filtrar datos regulados.

El spotlighting es una primera capa precisamente porque es barato y reduce la carga de todo lo que hay detrás. Nunca es la única capa, porque lo que hay detrás tiene que asumir que el spotlighting a veces falla.

Las cuatro capas, y por qué cada una asume que la anterior falló

La defensa en profundidad aquí no son cuatro copias de la misma idea. Son cuatro mecanismos independientes, cada uno atrapando una clase distinta de fallo, dispuestos para que eludir uno caiga en el siguiente.

Capa 1: spotlighting de la entrada. Marca y aísla el contenido no confiable para que el modelo tenga menos probabilidad de tratarlo como instrucción. Reduce la superficie de ataque. Asume que nada atrapa lo que se le escapa, así que nunca se confía en que sea completa.

Capa 2: aislamiento dual-LLM CaMeL. Este es el núcleo estructural, y es cualitativamente distinto de la capa 1. En lugar de pedirle a un modelo que tenga cuidado con el texto no confiable, repartes el trabajo entre dos. Un planificador privilegiado, el P-LLM, decide qué hacer e invoca herramientas, pero nunca lee directamente contenido no confiable. Un lector en cuarentena, el Q-LLM, lee el documento no confiable y extrae lo necesario, pero no tiene herramientas y no puede actuar. El componente que toca la entrada envenenada estructuralmente no puede ejecutar una acción privilegiada. Ante cualquier duda, el patrón falla cerrado. Cuesta alrededor de siete puntos porcentuales de utilidad, un precio modesto por convertir "esperamos que el modelo resista la inyección" en "el modelo que lee el ataque no tiene manos". Donde el spotlighting baja una probabilidad, el aislamiento elimina una capacidad.

Capa 3: guardrails de detección. Clasificadores y heurísticas independientes que inspeccionan entradas, salidas y llamadas a herramientas en busca de firmas de ataque conocidas y anomalías. Esta capa asume que las capas 1 y 2 pueden ser eludidas por algo novedoso, e intenta atraparlo por patrón. Es imperfecta en la dirección contraria a la del modelo: falla en los ataques que no ha visto, que es exactamente por lo que se sitúa junto a la capa estructural y no en su lugar.

Capa 4: punto de decisión de políticas, política como código. La última línea, y la que no depende en absoluto de detectar el ataque. Cada acción con consecuencia pasa por un PDP que la evalúa contra la política de la que tu equipo de cumplimiento es dueño, que versiona y firma (OPA/Rego, por ejemplo). Incluso si una inyección sobrevive a las tres capas anteriores y llega al punto de disparar una acción real, el PDP hace la pregunta determinista: ¿este agente, con estos argumentos, en este contexto, tiene permitido hacer esto? Un reembolso fuera de política se deniega por muy convincentemente que hayan convencido al agente de pedirlo. Esta capa atrapa el fallo de la detección misma, porque no intenta saber si la petición era maliciosa. Solo sabe si está permitida.

Lee la stack de abajo arriba y la intención de diseño queda clara. El spotlighting hace los ataques más raros. El aislamiento elimina la capacidad de actuar del lector. La detección atrapa patrones conocidos. El PDP impone lo que está permitido, sin importar lo que el modelo creyera. Cada capa se elige por lo que atrapa cuando falla la de arriba, y a ninguna se le pide que sea perfecta, porque ninguna puede serlo.

Mapear la stack a la OWASP Agentic Security Initiative

Una stack es más fácil de defender cuando cada riesgo nombrado tiene un dueño nombrado. La OWASP Agentic Security Initiative enumera las clases de amenaza; cada una debería corresponder a un control explícito, no a un gesto de la mano.

La tabla no es decoración. Es el artefacto que permite a un comité de riesgos preguntar, fila a fila, "¿quién es dueño de esto y dónde vive?" y obtener una respuesta que señala un componente. Fíjate en que ningún control aislado aparece en todas las filas. El ASI01 lo contiene el aislamiento más el spotlighting; el ASI02 y el ASI06, el PDP; el ASI03 y el ASI09, la identidad; el ASI10, el control de salida. El mapa solo se cierra cuando las capas se combinan. Una stack a la que le falte cualquiera de ellas deja filas sin dueño, y una fila sin dueño es donde empieza el próximo incidente.

El replanteamiento

La pregunta equivocada, la que lleva a los equipos a comprar una sola herramienta y declarar la victoria, es "¿cuál es la mejor defensa contra la prompt injection?". No hay mejor defensa, porque toda defensa falla en algún punto, y los fallos son todo el problema de diseño.

La pregunta correcta es cuando eludan nuestro control más fuerte, qué capa independiente atrapa la acción antes de que se confirme, y cada riesgo OWASP se mapea a un dueño con nombre. Si tu arquitectura responde a eso, tienes una stack de seguridad. Si nombra un control ingenioso y confía en que aguante, tienes una demo que todavía no ha conocido a su primer adversario serio.

Si quieres recorrer las cuatro capas contra uno de tus procesos en producción y encontrar las filas sin dueño, reserva una reunión.