Enterprise Security in the Agentic AI Era

Agent Message Structure Manipulation

6 min read

Agent Message Structure Manipulation

An attacker forges, replays, or alters the structured messages passing between agents, tools, and orchestration layers, changing task parameters, tool arguments, routing metadata, conversation state, or schema fields, so that a downstream component executes an unintended action.1 The OWASP AI Exchange gives the threat its own entry and permalink and classifies it as an input threat.1

Distinction from indirect prompt injection

The Exchange draws the separation by target. Indirect prompt injection smuggles instructions inside untrusted text content that an application inserts into a prompt. This threat targets the message fabric itself — protocol fields, envelopes, and delegation chains — and the Exchange states that the attack rests on those fields rather than on natural-language instructions alone.1

That leaves a detection gap. One of the Exchange’s four examples carries the attack in poisoned structured metadata with no classic prompt-injection prose in it,1 and a text-pattern classifier tuned for injection phrasing has nothing to match on in such a payload. A message that passes every content filter and every channel authentication check can still bind a tool call to an attacker-chosen file path.

The Exchange states that the threat reaches single agentic flows as well as multi-agent systems.1 A retrieval-augmented agent treating tool output or its own planner steps as trusted structured input is exposed with no second agent in the system.

Worked examples

The Exchange gives four, spanning multi-agent and single-agent shapes:1

  1. Agent impersonation on a weakly authenticated channel. The attacker injects forged messages that change the arguments of a downstream tool call.
  2. A malicious tool response. The response is valid JSON with manipulated field values — task ID, recipient, file path — and the orchestrator treats it as ground truth. The planner functions correctly throughout; the failure is data integrity.
  3. Single-agent RAG pipeline. Poisoned structured metadata in a retrieved document chunk alters routing and parameter binding, with no second agent and no injection prose involved.
  4. LLM-to-LLM prompt infection. One corrupted message propagates through a conversation graph over multiple hops.

Impact

Four stated impacts, reachable even where every visible user prompt is benign:1

  • Goal hijacking — the agent’s objective is redirected.
  • Privilege escalation through confused-deputy behaviour, where a component acts on its own authority for a request it should not have honoured.
  • Cascading misinformation across agents.
  • Unauthorized tool actions.

Controls

Three of the Exchange’s named controls are specific to the message fabric, and one is a framing rule that governs all of them.1 The entry also routes to general input-threat and least-privilege controls specified in sections this wiki has not yet summarized.

ControlWhat it establishes
Channel integrityMessage signing, mutual TLS, and replay protection, so a message’s origin and freshness are verifiable
Signed delegation tokensValidated across the full chain, with scope non-expansion, so a relayed request cannot widen the authority it started with
Deny-by-default schema validationApplied at tool and message boundaries, so a field outside the declared schema is rejected rather than interpreted

The framing rule is that peer-agent, tool, and orchestrator messages are untrusted input, including inside single-agent tool loops.1 That extends the untrusted-input treatment past the multi-agent setting where it is usually applied, and it is the rule that makes example 3 above tractable.

Channel integrity and delegation-token validation answer different questions. Signing and mutual TLS establish who sent a message; scope non-expansion establishes whether the sender held the authority the message claims. A signed message from an authenticated peer can still carry a delegated request wider than its originator’s rights, which is the case the second control exists for.

The multi-agent layer

The Exchange attaches a separate control note at the multi-agent layer, and it carries a claim made nowhere else in the document’s prompt-injection material. Individual agent controls such as access control are named necessary and not sufficient, on the stated ground that emergent collective behaviour can violate policy even where each agent complies in isolation.1

Per-agent compliance is therefore not evidence of system compliance. The wiki’s Threat Classes 2026 Class 3 argues the same property from one reconstructed incident and from reasoning about shared media; the Exchange states it as a general position.

Ownership across neighbouring pages

Four wiki pages hold adjacent material, and the division is deliberate.

PageWhat it owns
Orchestration HijackingPlanner subversion through content, and the privilege-mediated delegation confused deputy
This pageMessage-fabric integrity: forged, replayed, and altered protocol fields
Multi-Agent Runtime SecurityDetection, containment doctrine, and cross-agent forensics
Prompt Injection ContainmentThe containment stack and the Exchange’s seven layers of protection

The reference architecture’s Egress plane holds the channel-securing controls — A2A signed Agent Cards, inter-agent path blocking, MCP runtime authorization — and records the content-validation half as an unfilled gap, since no listed reference implementation emits evidence for full-chain delegation scope or boundary schema validation.

Limits

  • Schema validation bounds the shape of a field and not its truth. Example 2 above passes schema validation, because a manipulated recipient or file path is a well-formed value of the declared type. Deny-by-default schema validation removes the unexpected-field class and leaves the plausible-wrong-value class.
  • Replay protection depends on the orchestrator holding message state. An orchestrator that treats each tool response independently has no window against which to judge freshness.
  • The Exchange states no detection method for the single-agent case. Example 3 arrives through the same retrieval path the application is built on, and the controls named above sit at message boundaries an in-process RAG pipeline may not have.

Single-source extraction

This page rests on one primary source: the OWASP AI Exchange’s threat entry.1 No other taxonomy the wiki tracks names message-structure manipulation as a distinct threat category. The nearest is ASI07, insecure inter-agent communication, which covers interception, spoofing, replay, and downgrade on agent-to-agent channels and is scoped to those channels, so it reaches neither the orchestrator’s routing metadata nor the single-agent tool loop this entry includes. CSA MAESTRO and MITRE ATLAS carry no named equivalent. The examples, impacts, and controls above are the Exchange’s, and the corroboration a second primary would supply does not yet exist. Independent evidence of exploitation in the wild is also absent: the Exchange’s four examples are constructed rather than incident-derived.

Cross-references

Notes

Footnotes

  1. OWASP AI Exchange — Agent message structure manipulation, retrieved 2026-08-18. The threat definition and manipulated field set; the input-threat category line; the stated distinction from indirect prompt injection by target; the statement that the threat applies to single agentic flows as well as multi-agent systems; the four examples; the impact set; channel integrity through signing, mutual TLS, and replay protection; signed delegation tokens with full-chain validation and scope non-expansion; deny-by-default schema validation at tool and message boundaries; the untrusted-input framing including single-agent tool loops; and the multi-agent layer note on emergent collective behaviour. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11

Graph View

Backlinks