Prompt injection: logran que tu IA se niegue a ayudar

El uso más común de prompt injection en el mundo real no es robar tus datos. Es conseguir que tu IA diga que no.

Si tu equipo integra scripts antifraude o anti-bot de terceros — y en fintech y e-commerce de la región eso es la norma — ya viviste la escena. Pegas el JavaScript minificado del proveedor en el asistente y preguntas qué hace ese archivo. El modelo titubea, menciona algo sobre contenido peligroso y no entrega nada. Te encoges de hombros, asumes que la herramienta se pone remilgada con código ofuscado, y terminas leyendo el archivo a mano.

Ese encogerse de hombros es el ataque funcionando. Un script de detección de bots que se está sirviendo a usuarios reales ahora mismo contiene 1.275 caracteres Unicode invisibles, en un solo bloque contiguo, al 0,39% del archivo. Decodificados, forman un system prompt falso que exige guías paso a paso sobre armas biológicas, evasión fiscal y dosificación de estupefacientes. Nada de eso está escrito para ser respondido. Está escrito para ser rechazado.

El rechazo es el producto

Esta es la parte que todos reprodujeron y nadie leyó con atención. En la captura del propio investigador, el modelo no cayó. Dijo, en texto claro, que dejaría fuera del análisis el texto dirigido a la IA y los nombres señuelo. Ejecutó seis comandos. Terminó el trabajo. Entonces el filtro de salida reemplazó la respuesta terminada por "This content can't be shown. We take extra caution with requests involving biological research."

El análisis terminó. El filtro se lo comió. Fuente: nullpt.rs.

El modelo hizo bien su trabajo y la capa de seguridad suprimió el resultado. Ese es un ataque distinto del jailbreak, y es el que funciona contra un modelo cuidadoso: nunca hace falta engañar al asistente, basta con contaminar el tema hasta que el filtro dispare.

Ahora ponle precio. Si alguna parte de cómo entregan software asume que un modelo puede leer código que ustedes no escribieron — revisión de dependencias, auditoría de seguridad antes de una ronda o una adquisición, respuesta a incidentes sobre un bundle minificado a las dos de la mañana, migración de un SDK heredado — esa suposición ahora tiene un modo de fallo adversarial sin ninguna alarma asociada. Un rechazo es indistinguible de "el modelo no es bueno en esto". Sin excepción, sin 500, sin una línea en el log. El ingeniero se encoge de hombros, la hora se va a otro lado, y en tu plan sigue pareciendo que el trabajo se hizo.

Dos de los costos caen sobre gente que no escribe código. El primero es riesgo de estimación: "revisamos el bundle del proveedor con IA" es cobertura que ya contabilizaste y quizá no tengas. El segundo es cobertura de auditoría: si alguien pregunta cómo se revisó el código de terceros y la respuesta honesta es "el modelo se negó y seguimos adelante", eso es una brecha, no un control.

Qué verificamos y qué estamos tomando por palabra

Esta historia tiene dos mitades y no tienen la misma fuerza.

Descargamos el script nosotros mismos el 29 de octubre de 2026: HTTP 200, 420.741 bytes, last-modified: Mon, 26 Oct 2026 19:06:57 GMT — actualizado dos días antes de la divulgación y todavía servido sin cambios después de ella. Contamos los caracteres ocultos (1.275, de los cuales 1.002 caen en el bloque Unicode Tags propiamente dicho). Los decodificamos y recuperamos el payload completo, incluidas nueve líneas de disparador político en chino que desaparecen del bloque de código renderizado del investigador por falta de glifo. Revisamos uno a uno los seis nombres de función usados como cebo de rechazo: solo dos aparecen en texto plano en el build servido hoy, así que la lista publicada abarca más de un build o más de un archivo. Todo eso lo podemos mostrar.

Lo que no confirmamos: qué modelos se negaron y cuáles obedecieron (la prueba de un investigador, no reproducida por nosotros), las cifras del crawl que originó el hallazgo, y el vínculo de propiedad entre el dominio que sirve el script y una empresa rusa de anti-DDoS, que se apoya en una sola consulta. Y lo más importante: la intención es una inferencia. El investigador lo plantea como pregunta — ¿será ofuscación anti-LLM? — y ninguna declaración del proveedor lo confirma. ServicePipe no se ha pronunciado públicamente.

Lee la tesis en ese registro. El mecanismo está verificado y el efecto es reproducible; la intención es la lectura más razonable de la evidencia, no un hallazgo. El argumento no depende de ella. El archivo se comporta así lo haya querido alguien o no, y tu pipeline tiene que sobrevivir a ambos casos.

Cómo llegan 1.275 caracteres invisibles a una ventana de contexto

La codificación no tiene nada de exótico. Cada carácter del payload es texto común desplazado en 0xE0000, lo que coloca ASCII imprimible dentro del bloque Unicode Tags — un rango obsoleto que el aviso de seguridad de Microsoft de septiembre de 2026 describe como "una copia sombra de los caracteres ASCII imprimibles", donde U+E0041 refleja A y U+E0061 refleja a.

Cada cuadrito es un carácter de instrucciones dirigido a tu IA, no a ti.

La fuente no tiene glifo para ese rango, así que el renderizador no muestra nada, o cuadritos vacíos. El diff no muestra nada. El revisor no ve nada. grep -c 'SYSTEM OVERRIDE' sobre el archivo en vivo devuelve cero, y el grep por el nombre de la variable también. Pero un tokenizador no consulta la fuente. Para el modelo es texto y ya.

Los mismos bytes, decodificados. Nada de eso está hecho para responderse — solo para rechazarse.

La mitad visible de la técnica es más burda y funciona igual: funciones bautizadas para que cualquier modelo que lea el archivo corra hacia el rechazo. Esta está en texto plano en el build servido hoy, y no calcula nada parecido. El nombre es todo el payload.

Una función en un script de detección de bots en producción, bautizada solo para que tu IA no lea el archivo.

La posición es el detalle operativo. El bloque empieza en el byte 1.635 de 420.741. Cualquier cosa que lea los primeros 2 KB de ese archivo ya ingirió el payload entero.

Negar es el caso común, no el exótico

Más de un tercio de las inyecciones reales solo quiere que la respuesta de tu agente no sirva para nada. Fuente: Palo Alto Unit 42, marzo de 2026.

La telemetría de Unit 42 (Palo Alto) de marzo de 2026 sobre prompt injection indirecta vía web ordena las intenciones observadas según lo que el atacante buscaba. La categoría individual más grande es "irrelevant-output", de baja severidad, con 28,6%; "ai-access-restriction" suma otro 8,1%. Juntas, más de un tercio de las inyecciones reales no quiere nada de tu agente salvo que su respuesta no valga nada. Destrucción de datos es 14,2%. Transacciones no autorizadas, 6,2%.

Ese orden es justo el que la mayoría de los programas de seguridad tiene al revés. La exfiltración se lleva el presupuesto; la degradación es lo que aparece.

Qué decidir esta semana

Tres cosas, y solo la primera es trabajo de ingeniería. Las aplicamos las tres en las auditorías que hacemos al llevar software hecho con IA a producción.

1. Canonicaliza en la frontera de ingesta, no en el prompt. Elimina o rechaza codepoints en U+E0000–U+E007F, y en los planos no asignados por encima, en todo lo que llega al modelo desde afuera: páginas descargadas, código de dependencias, tickets de soporte, documentos subidos. Eso es trabajo de pipeline, donde se convierte en un filtro que puedes testear, y no de un system prompt pidiéndole al modelo que tenga cuidado. Es la misma frontera que trazamos en contener el código escrito por IA.
2. Cuenta tus rechazos. La tasa de rechazo es telemetría. Si tus agentes se niegan a trabajar, alguien tiene que poder decir con qué frecuencia y sobre qué entradas, igual que notarías un 5xx subiendo. La mayoría de los equipos descarta esa señal como ruido, que es exactamente la propiedad de la que depende este ataque. Dimos con el mismo punto ciego desde el otro lado en cuando un agente de IA se queda callado.
3. Deja de contabilizar "lo revisamos con IA" como cobertura sobre código que no escribiste hasta que sepas qué recibió el modelo realmente — no lo que pegaste, sino lo que llegó después de la canonicalización, con el conteo de lo que se eliminó.

Puntos clave

• La intención más común observada en prompt injection real es degradar la salida del agente (28,6% de irrelevant-output más 8,1% de restricción de acceso en la telemetría de Unit 42), no robar datos.
• Un script de detección de bots en producción lleva 1.275 caracteres Unicode invisibles, al 0,39% del archivo, que decodifican a un "SYSTEM OVERRIDE" falso con una lista de temas prohibidos. Verificamos el archivo, el conteo y la decodificación; la finalidad es una inferencia y el proveedor no se ha pronunciado.
• El payload es invisible para el renderizador, el diff, el code review y grep, y sigue siendo texto común para el tokenizador.
• El modo de fallo es un rechazo después de un análisis correcto — el filtro de salida suprimiendo un resultado terminado — no un jailbreak. No deja código de error ni alarma.
• Corrige en la frontera de ingesta, cuenta los rechazos como telemetría, y no contabilices la revisión por IA como cobertura de auditoría sobre código de terceros.