LISTEN TO THIS ARTICLE

Agent Data Injection Needs Trust Boundaries, Not Prompt Filters

Agent Data Injection argues that attackers can disguise malicious payloads as data the agent treats as trusted metadata, tool output, resource identifiers, or context structure Agent Data Injection.

Evidence base: Agent Data Injection submitted on 6 July 2026, Workflow-Level Jailbreak Construction in IDE Coding Agents revised on 9 July 2026, OWASP's LLM Top 10, OpenAI's agent-safety guidance, Microsoft guidance on indirect prompt injection, and Swarm Signal coverage on sandboxing and agent browsers Agent Data Injection.

Key takeaways

  • Main change: agent attacks are targeting data boundaries, not just instruction text.
  • Practical implication: retrieved data, tool responses, filenames, URLs, and metadata need provenance labels.
  • Caveat or risk: prompt filters can still help, but they do not create an authority model.
  • Recommendation: separate trusted control data from untrusted content before an agent can call tools.

ADI focuses on whether the agent can tell which parts of its input deserve authority.

The Failure Mode

The useful part of the ADI paper is its category split. Classic indirect prompt injection says hostile content gets interpreted as an instruction. ADI says hostile content can instead masquerade as the data that controls the workflow: origins, identifiers, tool formats, browser targets, or agent context fields Agent Data Injection.

That matters for AI safety and governance because agents don't only answer. They click, fetch, edit, run commands, and pass context across tools. The paper reports arbitrary-click attacks against web agents and remote-code-execution or supply-chain attacks against coding agents, including named real-world agent surfaces Agent Data Injection.

This is not the same problem Swarm Signal covered in agent sandbox egress budgets or agent browser traffic policy. Those articles focused on what an agent is allowed to reach. ADI focuses on whether the agent can tell which parts of its input deserve authority.

Why Prompt Filters Are Too Small

OWASP still lists prompt injection as the first LLM application risk, and that is fair OWASP LLM Top 10. Microsoft also describes indirect prompt injection as a risk when models process untrusted data and recommends defence in depth across isolation, monitoring, and policy enforcement Microsoft.

The problem is that many mitigations still sound text-centric. They inspect prompts, scrub obvious instruction strings, or tell the model not to obey web pages. ADI makes that insufficient. If a poisoned resource identifier or forged tool-response field changes what the agent believes it is acting on, the harmful step may not look like a jailbreak sentence Agent Data Injection.

Workflow-level jailbreak research reaches the same uncomfortable place from another angle. In a July coding-agent study, direct baselines produced only 8 successful unsafe responses out of 816 tested baseline responses, while the full workflow condition produced unsafe teaching-shot completions in all 816 cases under the authors' rubric Workflow-Level Jailbreak Construction.

Inference: a safe chat answer is weak evidence for a safe agent run. The dangerous object is the trajectory.

A production agent should not just reject malicious prose.

What To Test Instead

OpenAI's agent-safety guidance defines prompt injection as untrusted text or data entering an AI system and changing behaviour, including data exfiltration through tool calls or misaligned downstream actions OpenAI agent safety. Its guardrails documentation also treats tool behaviour as something that can be checked before and after execution OpenAI Agents SDK guardrails.

That is closer to the right unit. A production agent should not just reject malicious prose. It should carry trust labels through retrieval, browser state, tool outputs, file paths, shell commands, and memory writes. Inference from the ADI results: it should know the difference between "the user authorised this target" and "a web page supplied a string that looks like a target" Agent Data Injection.

The counterargument is that full provenance is expensive. It adds schemas, allowlists, taint tracking, review gates, and annoying blocked actions. That objection is valid. It is also less expensive than letting untrusted data silently acquire execution authority.

Operator takeaway

If you run agents with tools, add an ADI test before claiming prompt-injection coverage.

One practical action: seed evaluations with poisoned metadata, forged tool outputs, malicious resource identifiers, and conflicting origin labels.

One thing to measure: whether the agent preserves provenance through the whole run and blocks tool calls whose authority came from untrusted data.

One thing to avoid: treating a clean refusal transcript as proof that the deployed workflow is safe.

Source trail

Research:

Industry and practitioner context:

Related Swarm Signal analysis: