Source-linked AI summary
Agentic AI Defense: Decode-Time Provenance Binding for MCP
Eric Yocam, Varghese Vaidyan, Paris Kalathas, Patrick Tague, Bruce DeBruhl, Yong Wang
TL;DR
Indirect prompt injection can enter agent workflows through untrusted content, while existing text-channel approaches do not cover instructions concealed in images and decoded by tools. The paper proposes decode-time provenance binding that combines authenticated labels with layer-maintained lineage to contain such content at critical-tool calls. In the reported testbed, the mechanism blocks all attacks, including valid-label substitution, within fully mediated contexts.
Problem
Indirect prompt injection places instructions in content agents read, and the reported provenance guarantee is scoped to fully mediated execution contexts.
Source: §I · p. 1, §IX · p. 11Method
Decode-time provenance binding combines authenticated labels with an MCP-maintained lineage ledger so critical-call decisions use recorded dependencies rather than agent-presented labels.
Source: B. Mechanism · p. 6, C. Security invariant · p. 6Results
0% attack success for the mechanism versus 100% for the undefended pipeline and 62.5% for each keyword and regex defense across the 24-payload bank.
Source: B. Attack success by defense · p. 7Takeaways & Limitations
Within fully mediated contexts, HMAC authentication and layer-maintained lineage together prevent valid-label substitution that neither guarantee alone prevents.
Source: C. Security invariant · p. 6, D. Component ablation · p. 8The evaluation is a controlled testbed with 24 payloads, three carriers, one cover logo, and one small local model, not a production-scale measurement.
Source: §IX · p. 11
Abstract
from arXiv · showhide
Agentic AI systems using the Model Context Protocol (MCP) are vulnerable to indirect prompt injection through untrusted tool outputs. We demonstrate cross-modal trust laundering, in which instructions concealed in an email-signature image using least-significant-bit (LSB), discrete cosine transform (DCT), or metadata steganography bypass text scanners and enter a multi-agent workflow when decoded by a tool. To counter this threat, we propose decode-time provenance binding, which combines HMAC-authenticated trust labels with an MCP-maintained provenance ledger and context-taint tracking. The mechanism labels decoded content as untrusted and blocks critical tool calls influenced by that content, even when a compromised agent substitutes a valid trusted label. We evaluate the approach using a real MCP testbed with three steganographic carriers and 24 adaptive payloads. The undefended pipeline exhibits 100% attack success, while keyword and regex defenses each permit 62.5% of attacks. Our mechanism blocks all attacks (0% success), including adversarial label substitution across mediated agent boundaries. A four-component ablation validates the roles of decode marking, cryptographic authentication, lineage tracking, and sink enforcement. An audited trusted-promotion mechanism increases legitimate-task completion from 67% to 100% without compromising protection. The approach provides carrier-independent containment within fully mediated MCP execution environments. Code and data are publicly available.
I. Introduction
Agentic systems can obey instructions embedded in external content, and text-only defenses and provenance mechanisms do not address instructions concealed in image carriers and decoded inside multi-agent MCP workflows. The paper characterizes this cross-modal trust-laundering path and proposes decode-time provenance binding to contain it.
I. Introduction
- Cross-modal trust laundering hides instructions in an email-signature image that bypasses text scanners and enters multi-agent MCP control flow when decoded.The decoded instruction can be relayed as ordinary intermediate output.Source: §I · pp. 1–2
- The defense combines provenance security against forged or relabeled dependencies with containment of untrusted content that influences execution context.The MCP layer maintains lineage independently of agents.Source: §I · p. 1
- The authors give algorithms, a security invariant scoped to fully mediated contexts, and a proof sketch showing that the combined guarantees defeat valid-label substitution by a compromised agent.Neither guarantee alone does so.Source: §I · p. 2
- The paper reports a real MCP testbed with three steganographic carriers and 24 adaptive payloads, with 0% attack success versus 62.5% for each keyword and regex defense.It also reports a four-component ablation and an audited trusted-promotion evaluation.Source: §I · p. 2
- Decode-time provenance binding mints a cryptographically bound untrusted label when a concealment-reversing tool runs and enforces it at the critical-tool boundary.The defense assumes decoded content is untrusted rather than attempting to detect poisoned images.Source: §I · pp. 1–2
II. Background and Related Work
The paper situates its contribution at the intersection of indirect prompt injection, steganographic attacks, email-agent and MCP threats, and provenance defenses. Its stated gap is the decode-time junction of cross-modal carriers and runtime provenance enforcement.
II. Background and Related Work
- The paper frames its gap at the intersection of four strands: indirect prompt injection, steganographic injection, email-agent and MCP attacks, and provenance defenses.It claims the decode-time junction, not provenance or steganography alone, as its novelty.Source: §II · p. 2, D. Provenance and information-flow… · p. 3
A. Indirect prompt injection and benchmarks
- Benchmarks including InjecAgent, AgentDojo, and ToolEmu measure tool-integrated prompt injection, but operate on text channels.Earlier work established the threat and evaluation methodology.Source: A. Indirect prompt injection and… · p. 2
B. Steganographic injection against (multimodal) models
- Prior image-based steganographic attacks target models directly and do not address email delivery, multi-agent MCP pipelines, tool calls, or provenance defenses.The cited attacks include cross-modal jailbreaks and image-based payloads.Source: B. Steganographic injection against… · p. 2
C. Email-agent and MCP injection
- Email-agent hijacks and MCP risks have been studied, but the cited text carriers are visible to text scanners, unlike the paper’s image carrier.MCP-specific risks include poisoned tool output consumed by downstream agents.Source: C. Email-agent and MCP injection · p. 2
D. Provenance and information-flow defenses
- Related provenance systems label data by origin or propagate taint, while the paper identifies a gap in cross-modal decode-time labeling, cryptographic handoff binding, and runtime enforcement.Table I compares systems along these axes in multi-agent MCP settings.Source: D. Provenance and information-flow… · pp. 2–3
III. Threat Model and System Overview
The threat model places a steganographic instruction in an email-signature logo processed by a multi-agent MCP inbox summarizer. The attack becomes active at image decoding, while the defense binds provenance there and blocks untrusted lineage at critical-tool calls.
III. Threat Model and System Overview
- The MCP layer is trusted to mint bindings and maintain a per-context provenance ledger independently of agents, while the victim pipeline includes image decoding and reachable critical tools.The payload becomes an instruction only when decoded, and the defense acts at that stated precondition.Source: §III · p. 3
A. Carriers
- Three carriers span spatial LSB, frequency-domain DCT, and PNG metadata methods, each using a self-delimiting framed payload.The paper describes a cover logo, a stego logo, and amplified changed pixels.Source: A. Carriers · p. 3, Figure 2 · p. 4
B. Delivery and laundering
- An inline signature logo is decoded by a worker and relayed to peers and the orchestrator, which can execute an implied critical tool in the undefended pipeline.The defended sequence verifies the binding and blocks the call when lineage is untrusted.Source: B. Delivery and laundering · pp. 3–4
- Inline logos can pass perimeter controls because their payloads are inert until decoded downstream, and email defenses do not routinely steganalyze them.The text notes that CDR is typically applied to attachments and does not reliably strip metadata or frequency-domain payloads.Source: B. Delivery and laundering · p. 4
C. Mapping to OWASP Top 10 for LLM Applications
The section maps the attack to several OWASP LLM application categories and then introduces a defense organized around containment rather than detection. Its principle treats every concealment-reversing tool output as untrusted.
C. Mapping to OWASP Top 10 for LLM Applications
- The attack chain maps to OWASP LLM01 Prompt Injection, LLM02 Insecure Output Handling, LLM08 Excessive Agency, and LLM06 Sensitive Information Disclosure.Source: C. Mapping to OWASP Top 10 for LLM… · p. 4
V. Defense: Decode-Time Provenance Binding
- The defense is presented through its principle, mechanism and algorithms, security invariant, adversary model, and proof sketch.Source: §V · p. 4
A. Principle: contain, do not detect
- Rather than detect hidden payloads, the defense treats any concealment-reversing tool output as untrusted and prevents it from driving critical actions.The payload may decode perfectly and still cannot drive a critical action.Source: A. Principle: contain, do not detect · p. 4
B. Mechanism
Decode-time provenance binding marks decoded outputs untrusted and carries their lineage through an MCP-maintained ledger and context taint. At critical calls, the layer verifies bindings and independently checks lineage rather than trusting agent-presented labels.
B. Mechanism
- The layer mints a signed binding at tool return, marking output Untrusted if the tool decodes concealed content or any input is already untrusted.The binding records the payload, tool, trust label, provenance, and dependencies; an untrusted binding also taints its execution context.Source: B. Mechanism · pp. 4–6
- At critical calls, the layer reconstructs argument lineage from its ledger, verifies HMACs, and blocks untrusted, unresolved, or invalid bindings and tainted contexts.A trusted-looking argument label alone cannot authorize a call when its context contains an untrusted decode origin.Source: B. Mechanism · pp. 5–6
- Agents receive opaque handles, while the layer alone stores signed records and resolves dependencies, preventing relays from asserting or editing lineage.The layer rebuilds the dependency closure from its ledger and checks the HMAC before reading trust labels.Source: B. Mechanism · pp. 5–6
- Mediated inter-agent messages bind results to their source and propagate untrusted decode-origin taint into the destination context.The stated boundary is an agent paraphrasing decoded instructions into free text outside the mediated channel.Source: B. Mechanism · p. 5
- The mint-then-check design makes trust decisions from recorded lineage, not payload wording or labels supplied by agents.The two algorithms are asymmetric: the layer creates bindings at tool return, while the sink-side check treats presented handles only as lookups.Source: B. Mechanism · pp. 5–6
C. Security invariant
The security invariant blocks critical calls whose data or context lineage includes an untrusted decode origin, except when that origin receives audited trusted promotion. The guarantee depends on the conjunction of authenticated bindings and layer-maintained lineage within fully mediated contexts.
C. Security invariant
- In fully mediated contexts, no critical call executes with an untrusted decode origin in its transitive data or context lineage unless that origin is audibly promoted.The invariant assumes a confined signing key, registered decode tools, mediated critical calls, and complete layer-recorded lineage.Source: C. Security invariant · p. 6
- The HMAC prevents forged or relabeled data dependencies, while the MCP ledger and context taint contain influence and defeat valid-label substitution.The passages state that these guarantees are non-interchangeable and that their conjunction is necessary.Source: C. Security invariant · p. 6
- The guarantee does not cover influence that leaves the mediated path, such as decoded instructions paraphrased into out-of-band free text.The authors identify complete lineage recording as the loadbearing assumption and measure this boundary separately.Source: C. Security invariant · p. 6
D. Adversary model
The adversary controls external content and agent behavior but cannot access the MCP layer’s key, ledger, context taint, or critical-call verifier. The proof sketch argues that data lineage, context taint, or an incomplete decode set prevents a successful attack under those assumptions.
D. Adversary model
- The adversary may choose payloads, alter relayed bindings, and omit or substitute handles, but cannot edit the layer’s ledger or bypass sink verification.The attacker does not obtain the signing key or execute code inside the MCP layer.Source: D. Adversary model · p. 7
E. Proof sketch
- A forged Trusted variant of an untrusted data origin would require an HMAC existential forgery, while a substituted benign handle still leaves the origin in context taint.The proof treats an unregistered decoder as a violation of the complete-decode-set assumption, not as a mechanism defeat.Source: E. Proof sketch · p. 7
- With a complete decode set, confined key, and layer-maintained lineage, the proof bounds winning probability as negligible and makes the guarantee independent of payload wording or carrier.The argument is information-flow based and does not inspect payload text.Source: E. Proof sketch · p. 7
VI. Evaluation
On the 24-payload bank, the mechanism reaches 0% attack success, compared with 100% for the undefended pipeline and 62.5% for each text-scanning defense. The evaluation uses a real MCP testbed and also examines adversarial relaying and valid-label substitution.
C. Resisting valid-label substitution
- The evaluation includes a compromised-agent scenario that substitutes a benign Trusted binding while omitting the untrusted decode origin from presented lineage.The evaluation describes this as the valid-label-substitution case and distinguishes the mechanism from the taint baseline under adversarial relaying.Source: §VI · p. 7, B. Attack success by defense · p. 7
VI. Evaluation
- The evaluation is designed to stress assumptions including complete decoder registration, tamper-evident bindings, boundary mediation, and layer-maintained lineage.It also examines legitimate-task utility, carrier imperceptibility, and enforcement cost.Source: §VI · p. 7
A. Testbed
- The real MCP testbed relays decoded outputs across peer hops and tests five configurations against 24 adaptive payloads spanning three steganographic carriers and eight evasions.The configurations include an unsigned in-process taint baseline and decode-time provenance binding.Source: A. Testbed · p. 7, §VI · p. 7
B. Attack success by defense
- 0% attack success for decode-time provenance binding contrasts with 100% for the undefended pipeline and 62.5% each for the keyword scanner and regex parser across 24 payloads.The taint baseline also reaches 0% within a single trust domain; Fig. 4 depicts the attack-success comparison across defenses.Source: B. Attack success by defense · pp. 7–8, Table II · p. 7, Figure 4 · p. 8
D. Component ablation
The four-component ablation shows that marking and sink mediation are necessary, while cryptographic authentication and layer-maintained lineage protect against different attacks. Taint also crosses mediated agent boundaries, and the sink boundary determines whether decoded instructions can trigger critical calls.
D. Component ablation
- The full mechanism blocks all three tested attacks; removing marking or sink mediation leaks everything, while removing HMAC or lineage exposes distinct attacks.Without HMAC, a forged cross-domain relay leaks; without lineage, valid-label substitution leaks despite HMAC verification.Source: D. Component ablation · p. 8, Table IV · p. 8
E. Cross-context influence propagation
- Taint propagates from Agent A to Agent B and blocks B’s critical call when the inter-agent message passes through the layer.An unmediated side channel is outside the stated guarantee, which applies to fully mediated execution contexts.Source: E. Cross-context influence propagation · p. 8, Table V · p. 8
F. State transitions
- In the defended run, the decoded instruction remains in the agent’s context, but the verifier blocks the critical sink and no secrets leave.The undefended run executes the sink and leaks secrets; the defense governs whether the call is permitted, not whether the instruction enters context.Source: F. State transitions · pp. 8–9, Table VI · p. 9
G. Tamper-resistance across handoffs
The binding withstands relaying and tampering, while carrier-distortion and overhead measurements characterize deployment considerations. The security guarantee does not depend on carriers being imperceptible.
G. Tamper-resistance across handoffs
- Genuine untrusted bindings are blocked, while forged Trusted labels and stripped HMACs fail verification; genuinely trusted origins remain allowed.The binding remains intact across honest and compromised relays.Source: G. Tamper-resistance across handoffs · p. 9, Table VII · p. 9
H. Carrier distortion
- Metadata is lossless and LSB is near-lossless at ≈76 dB, while DCT measures ≈18 dB PSNR and ≈0.94 SSIM.PSNR and SSIM measure pixel-level distortion, not perceptual imperceptibility; the DCT carrier may be flagged by a perceptual gate.Source: H. Carrier distortion · p. 9, Table VIII · p. 9, Figure 5 · p. 9
I. Overhead
- Binding minting and verification together cost ≈17 µs per critical call, about 0.16% of a warm MCP tool invocation.Full enforcement scales linearly with dependency-closure depth, reaching ≈6.6 ms at depth 1000; for realistic depths in the tens it stays below 0.1 ms.Source: §I · p. 9, Table IX · p. 9, Table X · p. 9
J. Decode-set completeness
Decode-set configuration determines whether decoded content is marked untrusted or legitimate calls are falsely blocked. Relayed bindings retain integrity, and audited promotion restores legitimate-task completion while preserving protection.
J. Decode-set completeness
- With the correct decode set, the attack is blocked and the legitimate call allowed; a missing decoder leaks, while an over-broad set falsely blocks.The decode set is the trade-off between missed-decoder risk and false blocks, so the authors recommend a small audited allow-list fixed at tool registration.Source: J. Decode-set completeness · p. 10, Table XI · p. 10
K. Label integrity across handoffs
- Genuine bindings verify and are blocked after 1, 3, 5, and 10 honest hops; compromised-worker rewrites, promotions, or stripping fail verification.The verifier relies on the server-held HMAC to detect the tampering attempts.Source: K. Label integrity across handoffs · p. 10, Table XII · p. 10
L. Legitimate-task utility
- Audited promotion raises legitimate-task completion from 67% to 100% with zero false blocks, while the unauthorized attack remains blocked.The evaluation includes an authorized payment using an OCR’d invoice number; the attacker cannot invoke promotion.Source: L. Legitimate-task utility · p. 10, Table XIII · p. 10
M. Realistic decode trigger
- Metadata extraction and OCR can surface payloads during ordinary image handling, while LSB and DCT variants require matching decoders.The defense labels outputs according to registration in the decode set, not why the tool was invoked.Source: M. Realistic decode trigger · p. 10
VII. Deployment
The deployment design places binding and enforcement at tool-return and tool-dispatch boundaries, with server-authored decode and critical-tool sets. Its protection is scoped to actions and fully mediated lineage, and the evaluation remains a controlled testbed rather than a production workflow.
VII. Deployment
- MintBinding signs decoded results and records them in the layer’s ledger; EnforceCritical checks lineage before critical calls, without changing the agent or orchestration logic.The decode set and critical set are short, server-authored lists; audited promotion can re-label a specific decoded value under human or policy authorization.Source: §VII · pp. 10–11
VIII. Design Trade-offs
- The control contains rather than detects: it blocks actions but cannot prevent decoded content from corrupting returned summaries.The guarantee also depends on complete decode-set registration, confined key management, and layer-maintained lineage; message/tool-result granularity cannot express partial trust within a decoded blob.Source: §VIII · p. 11
IX. Limitations
- The evaluation is not production-scale, covering 24 payloads, one cover logo, one small model, and limited scanner and taint baselines.Multiple cover images and model families, modern learned or provenance-aware baselines, and an existing production email-agent workflow remain future work.Source: §IX · p. 11
X. Conclusion
- Within fully mediated MCP execution, decode-boundary containment backed by layer-maintained lineage blocks critical calls with untrusted lineage.The conclusion reports 0% attack success, resistance to valid-label substitution, and 100% legitimate-task completion with audited promotion.Source: §X · p. 11