Blanqueo de prompts entre modelos: un rechazo que no sobrevive al relevo

¿Qué es esto?

El 3 de julio de 2026, Axis Intelligence Research añadió a su seguimiento mensual AI Model Vulnerability Tracker (actualizado el 4 de julio de 2026) una entrada que describe un patrón al que llama blanqueo de prompts entre modelos mediante encadenamiento de API. No es un fallo de ningún modelo concreto. Es una brecha que se abre entre dos modelos cuando la salida de uno se inyecta en el otro como un simple mensaje de usuario — exactamente el cableado del que dependen los stacks de orquestación multiagente.

La observación es sencilla e incómoda. El modelo A rechaza una petición. El orquestador, por diseño o por descuido, reenvía una versión reformulada de la misma petición subyacente al modelo B. El modelo B no tiene idea de que el modelo A ya la había rechazado. Ve un mensaje de usuario nuevo, de apariencia inocua, y responde. El rechazo no viajó con la petición. En el laboratorio, 14 de 18 cadenas probadas produjeron la salida rechazada en dos saltos.

Cómo funciona

El mecanismo es estructural, no ingenioso. Un rechazo de seguridad es una propiedad de una sola inferencia: el modelo evalúa el prompt que tiene delante y declina. Esa decisión no es una etiqueta duradera adherida a la petición; es un evento que ocurre dentro de una llamada al modelo y luego se evapora. Cuando un orquestador cede el relevo — del resumidor al planificador, del planificador al ejecutor de herramientas, del modelo de un proveedor al de otro — normalmente reenvía contenido, no el historial de seguridad que lo produjo.

Así que el segundo modelo hereda las palabras, pero no el veredicto. Una petición que parece dañina en una formulación puede reformularse, descomponerse en subtareas o simplemente reetiquetarse como «contexto a procesar» antes de llegar al modelo B. Como el modelo B responde a lo que parece un turno de usuario inocuo, su propio entrenamiento de alineación se activa frente a la pregunta equivocada. La superficie de ataque, según el seguimiento, es la costura entre los modelos, no una debilidad de ninguno de ellos.

Esto coincide con un argumento más amplio en la literatura de investigación. Un artículo de posición de mayo de 2026, Safety and Fairness in Agentic AI Depend on Interaction Topology, Not on Model Scale or Alignment, defiende la tesis general: cuando el comportamiento de un sistema está dominado por cómo se conectan sus componentes, la alineación por componente no se compone de forma fiable en seguridad a nivel de sistema. Alinear cada modelo de forma aislada restringe el comportamiento local; es la topología del pipeline la que determina lo que el conjunto hace en realidad. El blanqueo entre modelos es esa tesis abstracta apareciendo como un hallazgo concreto y reproducible.

Por qué importa

La orquestación multiagente pasó de la demo de investigación a la fontanería de producción durante el primer semestre de 2026. Como documenta la revisión de mitad de año sobre IA agéntica de DeepInspect (1 de julio de 2026), las llamadas encadenadas de modelos están ahora detrás de funcionalidades empresariales cotidianas — resumir, luego planificar, luego actuar — mezclando a menudo proveedores y versiones de modelos en una misma ruta de petición. Cada relevo de esa cadena es un punto donde un rechazo puede perderse discretamente.

La consecuencia es que «usamos un modelo bien alineado» deja de ser un argumento de seguridad suficiente. El hallazgo se reprodujo con una variedad de modelos de frontera actuales actuando como eslabón posterior, lo que significa que la exposición es una propiedad del patrón de arquitectura, no de las barreras de un proveedor concreto. Un equipo puede comprar el modelo más propenso al rechazo del mercado y aun así desplegar un pipeline que blanquea una petición rechazada a través de él — porque al modelo nunca se le dijo que ya había ocurrido un rechazo.

Defensas

La solución es dejar de tratar un relevo como una página en blanco. Haga viajar el estado de seguridad a través de la costura y vuelva a comprobar en cada frontera en lugar de suponer que un modelo previo ya lo hizo.

En concreto: vuelva a filtrar en cada salto. Aplique clasificación de entradas al contenido que entra en cada modelo de la cadena, no solo en aquel con el que el usuario dialoga. El segundo modelo debe protegerse como si su entrada fuera texto de usuario no confiable — porque, funcionalmente, lo es. Propague las señales de rechazo. Cuando un modelo previo declina, el orquestador debería registrarlo y negarse a reenviar aguas abajo una petición semánticamente equivalente, en lugar de reformularla y reintentarla en silencio. Preserve la procedencia. Etiquete el contenido según su origen — usuario, herramienta o salida de otro modelo — para que una barrera posterior pueda ponderarlo correctamente en vez de leerlo todo como un turno de usuario de confianza. Coloque la capa de política en la frontera de petición, no dentro de los modelos. Una pasarela que ve toda la cadena puede aplicar una política única y coherente en todos los saltos, algo que ningún modelo aislado puede hacer porque ninguno ve la ruta completa. Y pruebe el pipeline, no las piezas. Evalúe la seguridad de extremo a extremo sobre la cadena ensamblada; una campaña que solo somete a red team cada modelo por separado se perderá justamente esta clase de fallo, porque vive entre ellos.

Estado

Aspecto	Detalle
Referencia	AVI-2026-0104, «Cross-Model Prompt Laundering via API Chaining» (seguimiento Axis Intelligence)
Divulgación	Registrado el 3 de julio de 2026; reportado a OpenAI, Anthropic y Google DeepMind el 3 de julio de 2026
Clase	Brecha de seguridad arquitectónica — estado de rechazo no preservado en los relevos entre modelos
Reproducción	14 de 18 cadenas probadas produjeron la salida rechazada en dos saltos (pruebas de laboratorio)
Afectados	Reportado contra GPT-5, Claude Sonnet 4.6 y Gemini 3 Pro como modelo posterior; patrón a nivel de framework
Anclaje académico	Artículo de posición sobre topología de interacción (arXiv 2605.01147, mayo de 2026): la alineación por componente no se compone en seguridad del sistema
Explotado in the wild	No reportado como explotado; divulgado bajo divulgación coordinada