Fallo de traspaso de confianza en pipelines de agentes: «filtrado» no es «autorizado»

¿Qué es esto?

Una ponencia prevista en Black Hat USA 2026, el 5 de agosto de 2026 — Trusted Enough to Run: Breaking AI Agents in Official Workflows, presentada por Elad Meged, de Novee Security — señala una clase de fallo que los autores denominan fallo de traspaso de confianza (trust-handoff failure) y afirma que aparece de forma simultánea en flujos de trabajo de agentes construidos sobre sistemas de Anthropic, Google y OpenAI. Según el avance publicado por Novee (27 de junio de 2026) y un análisis independiente (julio de 2026), la debilidad no es un fallo de un modelo concreto, sino una propiedad estructural de los pipelines de agentes de varias etapas.

Los detalles técnicos completos se esperan durante la conferencia. Lo que se ha descrito públicamente es la forma del problema: una etapa del flujo marca un dato como seguro según su propio modelo de amenazas y, después, una etapa posterior consume ese mismo dato con más autoridad de la que el control anterior había previsto. Sin 0-day, sin credencial robada, sin ninguna acción del usuario más allá de que el agente ejecute su flujo normal. Este artículo trata el patrón reportado y sus defensas; volveremos sobre él cuando el material completo sea público.

Cómo funciona

Los «flujos de trabajo» de agentes modernos son pipelines. Una etapa de navegación o recuperación importa contenido externo, una etapa de filtrado o moderación lo revisa, una etapa de planificación decide la acción y una etapa de acción invoca una herramienta. Cada etapa se escribe frente a un modelo de amenazas local: aquello que tiene por misión detectar.

El fallo reportado vive en las costuras entre esas etapas. Una etapa de filtrado puede concluir legítimamente «este texto no contiene patrones de inyección que yo vigile» y transmitir su salida, marcada de forma implícita como limpia. El problema es que «limpio» se definió respecto a la misión de esa etapa. Cuando una etapa de acción posterior trata la misma salida como suficientemente fiable para autorizar una llamada a una herramienta, ha promovido en silencio «pasó un filtro» a «aprobado para actuar», un significado que el filtro nunca asignó.

Frontera de etapa donde la confianza se promueve en silencio
------------------------------------------------------------
[browse]  -> contenido externo importado            (no fiable)
[sanitize]-> «ningún patrón de inyección vigilado»  (limpio *para esta etapa*)
[plan]    -> trata el texto filtrado como fiable    (promoción implícita)
[act]     -> invoca una herramienta sobre él         (ahora tratado como autorizado)

Es un problema de frontera de confianza, no de contenido: no hay cadena maliciosa que un filtro hubiera podido detectar, porque cada etapa hizo su trabajo. El defecto es que la frontera entre ellas transporta el dato, pero no cuánta confianza merece ese dato para el propósito de la etapa siguiente. Este enfoque coincide con la visión orientada a sistemas de la síntesis de junio de 2026 Toward Secure LLM Agents, que modela la seguridad de los agentes en torno a la interacción entre flujo de información, autoridad delegada y estado persistente, y no en torno a fallos de componentes aislados.

Por qué importa

Tres puntos merecen atención incluso antes de la charla.

Primero, es multiproveedor. Los autores señalan el mismo patrón en Anthropic, Google y OpenAI, lo que apunta a una suposición de arquitectura compartida por todos los que construyen agentes de varias etapas, y no a un desliz de un único proveedor. Cambiar a un modelo «más seguro» no elimina un fallo que vive en el cableado del pipeline.

Segundo, no requiere ningún disparador exótico. Si la afirmación se sostiene, basta con que el agente ejecute su flujo ordinario. Eso lo sitúa en la misma familia que el trío letal: capacidades individualmente razonables que solo se vuelven peligrosas cuando comparten un contexto de confianza que nadie diseñó de forma explícita.

Tercero, es difícil de detectar en pruebas. Una pasarela que solo inspecciona prompts y respuestas —la configuración que Rein Security habría vencido contra el asistente de compras de un gran minorista en otra charla de Black Hat 2026— no tiene visibilidad de lo que el agente realmente ejecuta, así que no puede ver un nivel de confianza promovido en una frontera interna. Las pruebas puntuales que revisan cada etapa por separado aprobarán cada etapa y aun así pasarán por alto la costura.

Una advertencia sobre las fuentes: se trata de una charla futura, y lo que es público hoy es el resumen y síntesis de segunda mano, no la prueba de concepto subyacente. Considere los detalles como provisionales hasta que se publique la ponencia y cualquier material asociado. La lección de arquitectura, en cambio, no depende de la demostración.

Defensas

La corrección que señalan autores y analistas es arquitectónica, y está disponible ahora, con independencia de la ponencia.

1. Adjunte un nivel de confianza explícito a cada carga que cruce una frontera de etapa. No deje que la confianza se deduzca de «viene de la etapa anterior». Etiquete el dato con su origen y su grado real de verificación, y transporte esa etiqueta a través de la frontera junto con el dato.

2. Haga que las etapas posteriores exijan un mínimo de confianza. Cualquier etapa que actúe —invocar una herramienta, escribir en un sistema, gastar dinero, ejecutar código— debe rechazar una entrada por debajo de un umbral declarado y fallar en modo cerrado. Filtrar no es promover: pasar un filtro de inyección no hace que un contenido esté autorizado a disparar una acción financiera.

from enum import IntEnum

class Trust(IntEnum):
    UNTRUSTED = 0      # contenido web/correo/usuario en bruto
    SCREENED  = 1      # pasó un filtro — limitado al modelo de amenazas DE ESE filtro
    INTERNAL  = 2      # salida de otro agente de la cadena
    VERIFIED  = 3      # firmado / aprobado por humano / bajo control de fuente

def act(payload_trust: Trust, min_required: Trust) -> bool:
    # Las etapas de acción fallan en modo cerrado por debajo de su mínimo, sea cual sea el origen.
    if payload_trust < min_required:
        raise PermissionError("[BLOQUEADO] guardia de traspaso de confianza: "
                              f"{payload_trust.name} < {min_required.name}")
    return True

3. Alinee el modelo de amenazas de la etapa de filtrado con el uso posterior, no solo con su propia misión. Si un filtro se construyó para detectar cadenas de inyección de prompt, su veredicto «limpio» no dice nada sobre si el contenido es seguro para entregarlo a un shell, a una herramienta SMTP o a una API de pago. Cada superficie de riesgo necesita su propia comprobación.

4. Autorice la acción, no la identidad ni el origen. Vincule la aprobación a la operación concreta y a sus argumentos reales en el momento de la ejecución, en línea con autorizar los pasos del flujo en lugar de la identidad del agente. Eso bloquea directamente la promoción «fiable porque viene de una etapa interna».

5. Instrumente las costuras. Registre lo que cada etapa afirma de su salida y lo que la etapa siguiente supone, de modo que una promoción silenciosa sea visible en la telemetría. Esta es la brecha de observabilidad detrás de fallos relacionados de autoridad implícita en rutas de error y de ventanas time-of-check/time-of-use en agentes.

6. Haga red team de sus propias fronteras. Suministre contenido benigno para el filtro de la etapa N pero peligroso para la herramienta de la etapa N+1, y confirme que el pipeline lo bloquea. Si se ejecuta, el defecto está en su cableado, no en el modelo.

Estado

Elemento	Referencia	Fecha	Notas
Trusted Enough to Run: Breaking AI Agents in Official Workflows	Ponencia Black Hat USA 2026 (Elad Meged, Novee Security)	2026-08-05	Futura; señala un traspaso de confianza en Anthropic, Google, OpenAI
Avance de la ponencia	Novee Security	2026-06-27	Presentación del track y resumen
Análisis independiente	The Agentic Protocol	2026-07	Enfoque defensivo del patrón
Marco de sistemas	Toward Secure LLM Agents (SoK)	2026-06	Flujo de información, autoridad delegada, estado persistente

La enseñanza útil no espera a la ponencia: en un agente de varias etapas, «esto pasó mi control» y «esto está autorizado para lo que vas a hacer» son afirmaciones distintas. Mientras cada frontera no transporte la primera sin promoverla en silencio a la segunda, un filtro que hizo su trabajo aún puede entregar a una etapa de acción algo que nunca debió poder ejecutar.