Trust-handoff failures in agent pipelines: 'safe' is not 'authorized'

What is this?

A Black Hat USA 2026 briefing scheduled for August 5, 2026 — Trusted Enough to Run: Breaking AI Agents in Official Workflows, by Elad Meged of Novee Security — reports a class of failure the presenters call a trust-handoff failure, and says it shows up across agent workflows built on systems from Anthropic, Google and OpenAI at the same time. The claim, per Novee’s own briefing preview (published June 27, 2026) and an independent write-up (July 2026), is that the vulnerability is not a bug in any single vendor’s model but a structural property of multi-stage agent pipelines.

The full technical details are expected at the conference. What has been described publicly is the shape of the problem: one stage in a workflow marks a piece of data as safe against its own threat model, and a later stage then consumes that same data with more authority than the earlier check ever anticipated. No zero-day, no leaked credential, no user action beyond the agent running its normal workflow. This write-up covers the reported pattern and its defenses; we will revisit it once the full material is public.

How it works

Modern agent “workflows” are pipelines. A browsing or retrieval stage pulls in external content, a sanitizing or moderation stage screens it, a planning stage decides what to do, and an action stage calls a tool. Each stage is written against a local threat model — the thing it is responsible for catching.

The reported failure lives in the seams between those stages. A sanitizing stage may legitimately conclude “this text contains no injection patterns I screen for” and pass the output downstream tagged, implicitly, as clean. The problem is that “clean” was defined relative to that stage’s job. When a later action stage treats the same output as trustworthy enough to authorize a tool call, it has silently promoted “passed one filter” into “approved to act” — a meaning the sanitizer never assigned.

Stage boundary where trust is silently promoted
-----------------------------------------------
[browse]  -> external content pulled in            (untrusted)
[sanitize]-> "no injection patterns I check for"   (clean *for this stage*)
[plan]    -> treats sanitized text as reliable     (implicit promotion)
[act]     -> calls a tool on it                     (now treated as authorized)

This is a trust-boundary problem, not a content problem: there is no malicious string that a filter could have caught, because the individual stages each did their job. The defect is that the boundary between them carries the data forward but not how much that data should be trusted for the next stage’s purpose. The framing lines up with the systems-oriented view in the June 2026 survey Toward Secure LLM Agents, which models agent security around the interaction of information flow, delegated authority and persistent state rather than around single-component bugs.

Why it matters

Three things make this worth attention even before the full talk.

First, it is cross-vendor. The presenters report the same pattern across Anthropic, Google and OpenAI workflows, which points at an architectural assumption shared by everyone building multi-stage agents rather than one vendor’s slip. Swapping to a “more secure” model does not remove a flaw that lives in the pipeline wiring.

Second, it needs no exotic trigger. If the account holds, the agent running its ordinary workflow is enough. That puts it in the same family as the lethal trifecta: individually reasonable capabilities that become dangerous only when they share a trust context nobody designed explicitly.

Third, it is easy to miss in testing. A gateway that only inspects prompts and responses — the configuration Rein Security reportedly defeated against a large retailer’s shopping assistant in a separate Black Hat 2026 talk — has no visibility into what the agent actually executes, so it cannot see a trust level being promoted at an internal boundary. Point-in-time tests that check each stage in isolation will pass every stage and still miss the seam.

A caveat on sourcing: this is a forthcoming briefing, and what is public today is the abstract and second-hand summaries, not the underlying proof-of-concept. Treat the specifics as provisional until the talk and any accompanying write-up are released. The architectural lesson, however, does not depend on the demo.

Defenses

The fix the presenters and analysts point to is architectural, and it is available now regardless of the talk.

1. Attach an explicit trust level to every payload that crosses a stage boundary. Do not let trust be implied by “it came from the previous stage.” Tag data with where it originated and how much it has actually been verified, and carry that tag across the boundary with the data.

2. Make downstream stages enforce a minimum trust requirement. Any stage that takes an action — calls a tool, writes to a system, spends money, executes code — should refuse input below a declared threshold and fail closed. Sanitization is not promotion: passing an injection filter does not make content authorized to trigger a financial action.

from enum import IntEnum

class Trust(IntEnum):
    UNTRUSTED = 0      # raw web/email/user content
    SCREENED  = 1      # passed a filter — scoped to THAT filter's threat model
    INTERNAL  = 2      # output of another agent in the chain
    VERIFIED  = 3      # signed / human-approved / source-controlled

def act(payload_trust: Trust, min_required: Trust) -> bool:
    # Action stages fail closed below their own minimum, no matter the source.
    if payload_trust < min_required:
        raise PermissionError("[BLOCKED] trust-handoff guardrail: "
                              f"{payload_trust.name} < {min_required.name}")
    return True

3. Match the sanitizing stage’s threat model to the downstream use, not just its own job. If a filter was built to catch prompt-injection strings, its “clean” verdict says nothing about whether the content is safe to hand to a shell, an SMTP tool or a payment API. Each risk surface needs its own check.

4. Authorize the action, not the identity or the origin. Bind approval to the specific operation and its concrete arguments at the moment of execution, in line with authorizing workflow steps rather than agent identity. This blocks the “trusted because it came from an internal stage” promotion directly.

5. Instrument the seams. Log what each stage asserted about its output and what the next stage assumed, so a silent promotion is visible in telemetry. This is the observability gap behind related implicit-authority failures on error paths and time-of-check/time-of-use gaps in agents.

6. Red-team your own boundaries. Feed content that is benign to stage N’s filter but dangerous to stage N+1’s tool, and confirm the pipeline blocks it. If it executes, the defect is in your wiring, not in the model.

Status

Item	Reference	Date	Notes
Trusted Enough to Run: Breaking AI Agents in Official Workflows	Black Hat USA 2026 briefing (Elad Meged, Novee Security)	2026-08-05	Forthcoming; reports trust-handoff failure across Anthropic, Google, OpenAI workflows
Briefing preview	Novee Security	2026-06-27	Track overview and abstract
Independent analysis	The Agentic Protocol	2026-07	Defensive framing of the pattern
Systems framing	Toward Secure LLM Agents (SoK)	2026-06	Information flow, delegated authority, persistent state

The useful takeaway does not wait for the talk: in a multi-stage agent, “this passed my check” and “this is authorized for what you are about to do” are different statements. Until every boundary carries the first without silently upgrading it to the second, a filter that did its job can still hand an action stage something it should never have been allowed to run.