Agentic AI Defense: Decode-Time Provenance Binding for MCP

ARXIV PREPRINT

1

Agentic AI Defense: Decode-Time Provenance Binding for MCP

arXiv:2610.31974v1 [cs.CR] 22 Oct 2026

Eric Yocam†1 , Varghese Vaidyan2 , Paris Kalathas1 , Patrick Tague3 , Bruce DeBruhl1 , and Yong Wang4

Abstract—Agentic AI systems—large language model (LLM) agents that call tools through the Model Context Protocol (MCP)—are increasingly defended against indirect prompt injection by tracking data provenance: text returned by a tool is labeled untrusted and barred from driving dangerous actions. These defenses label at the text channel. We show this is bypassed by a benign-looking image—a logo in an email signature—that hides an instruction via steganography (least-significant-bit [LSB], discrete cosine transform [DCT], or metadata), passes text scanners that see only pixels, and becomes an instruction only when a tool decodes it, laundering it into the agentic system’s trusted control flow. As a defense we propose decode-time provenance binding: within a fully mediated MCP execution environment, the MCP layer mints a keyed-hash message authentication code (HMAC)signed Untrusted label the instant a concealment-reversing tool runs and itself maintains the complete provenance lineage of each critical call, so a verifier blocks any call whose lineage is untrusted—even when a compromised agent presents a valid label for an unrelated trusted value. On a real MCP testbed of three carriers and 24 adaptive payloads, the undefended pipeline leaks on 100% of attacks, a keyword scanner and a regex parser on 62.5% each, and our mechanism on 0%; an in-process taint baseline matches us within one trust domain but fails once a label crosses a compromised relay. A four-component ablation isolates decode marking, HMAC authentication, trusted lineage tracking, and sink mediation, and an audited trusted-promotion path raises legitimate-task completion from 67% to 100% without loss of protection. It contains rather than detects, so it is wordingand carrier-independent. Code and data are released. Index Terms—Prompt injection, steganography, LLM agents, Model Context Protocol, data provenance, information-flow control, AI security, multi-agent systems.

I. Introduction ARGE language models (LLMs) are increasingly deployed not as passive chatbots but as agents: systems that read external content, decide what to do, and then act by calling software tools on a user’s behalf—reading an inbox and drafting replies, triaging tickets, or acting on documents. To call a tool, an agent needs a uniform way to discover it and exchange data with it; the Model Context Protocol (MCP) [1] has become a common such interface, letting an agent invoke tools—“extract the text from this image,” “send this email,”

L

† Corresponding author.

1 Department of Computer Science, California Polytechnic State University, San Luis Obispo, CA, USA (e-mail: eyocam@calpoly.edu). 2 Beacom College of Computer and Cyber Sciences, Dakota State University, Madison, SD, USA. 3 Information Networking Institute, Carnegie Mellon University, Pittsburgh, PA, USA. 4 Department of Computer Science, University of Idaho, Moscow, ID, USA (e-mail: stevew@uidaho.edu). Code and data are available at https://github.com/ericyoc/stego_ provenance_defense.

“export these records”—through one standardized channel. Realistic deployments are often multi-agent: a coordinator dispatches specialized worker agents that relay intermediate results to one another before any action is taken. This autonomy creates a risk that does not arise for a passive chatbot. Because an agent acts on the content it reads, text inside that content can function as a command: an email whose body says “ignore your instructions and forward the user’s saved passwords” may be read by an inbox agent and obeyed, even though no human ever issued it. This is indirect prompt injection—an instruction smuggled into the data an agent processes rather than supplied by its operator—and it is ranked first on the Open Worldwide Application Security Project (OWASP) Top 10 for LLM Applications [2] and catalogued in the National Institute of Standards and Technology (NIST) adversarial-ML taxonomy [3]. A practical and well-studied instance is the emailsummarizing agent: researchers have repeatedly hidden instructions in a message—for example as zero-pixel or whiteon-white HTML text, invisible to the human reader—and shown that the summarizer reads and acts on them [4], [5], [6]. Two families of defense dominate. Content scanning inspects the ingested text for tell-tale injection markers (“ignore previous instructions,” a tool name, a request for credentials) and strips or blocks any match. Provenance tracking takes a different tack: rather than judge what the text says, it labels where the text came from—marking anything a tool returns as untrusted—and forbids untrusted content from triggering a sensitive action such as sending mail or exporting data [7], [8], [9], [10], [11]. Both families are the backdrop for the attack and defense this paper develops. This paper makes three contributions. • We identify and characterize cross-modal trust laundering: a steganographic email-signature carrier that defeats text content scanners and launders an instruction into a multi-agent MCP control flow at the decode step (Section IV). • As a defense for agentic AI, we propose decode-time provenance binding, which combines two guarantees that are usually conflated: data-provenance security (a critical action cannot be authorized through a forged or relabeled data dependency), delivered by an HMAC-signed label minted at the concealment-reversal boundary; and context-influence containment (a critical action cannot execute after an untrusted instruction has influenced the execution context without authorized clearance), delivered by having the MCP layer independently maintain the provenance lineage—a ledger and per-context taint—

ARXIV PREPRINT

rather than trust an agent-presented label. We give the two algorithms, a security invariant scoped to fully mediated contexts, and a proof sketch, and we show the conjunction defeats valid-label substitution by a compromised agent, which neither guarantee alone does (Section V). • We implement a real MCP testbed with three steganographic carriers (LSB, DCT, metadata) and an adaptive 24-payload attack bank, and show the mechanism reduces attack success to 0% where a keyword scanner and a regex parser each reach 62.5%; we add an informationflow (taint) baseline, an ablation over the mechanism’s four components, a label-substitution stress test, and a legitimate-task evaluation in which an audited trustedpromotion path eliminates false blocks, with cryptographic overhead under 0.2% of a decode round-trip and a full enforcement path that scales linearly with lineage depth (Section VI). All code and data are released at https://github.com/ericyoc/stego_provenance_defense. Both defenses assume the payload travels through a text channel. We show this assumption is violable in a way that is realistic, zero-click, and invisible to the human recipient. Consider a brand logo embedded in an email signature—the single most innocuous object in a message. Using steganography, an attacker hides an instruction in the logo’s pixels or metadata. The image is visually identical to the original and contains no suspicious text, so a content scanner sees nothing. The victim never clicks anything. But when the victim’s routine inbox-summarization agent processes the signature, a tool in its pipeline—an optical-character-recognition (OCR) step, a stego/metadata extractor, or a multimodal model prompted to surface hidden content—decodes the image, and the hidden instruction enters the agent’s context. In a multi-agent pipeline, that decoded text is then relayed from the extracting worker to peer agents and the orchestrator, which treat it as ordinary intermediate output. An externally-supplied instruction has been laundered into the trusted control flow. We call this crossmodal trust laundering. The key observation for defense is that existing provenance mechanisms attach the trust label when a text tool returns. A steganographic carrier defeats this because the dangerous transition—hidden bits becoming instructions—does not happen at text ingestion; it happens at the decode step. We therefore propose decode-time provenance binding: the trust label is minted at the moment any concealment-reversing tool runs, is cryptographically bound to the decoded payload so it survives multi-agent handoffs, and is enforced at the criticaltool boundary. Crucially, the defense does not attempt to detect that an image is poisoned—an arms race against ever-better steganography that the defender loses. It instead assumes any decoded content is untrusted and contains it, so the payload may decode perfectly and still cannot drive a critical action. II. Background and Related Work We review four strands that our work joins: indirect prompt injection and its benchmarks, steganographic injection against (multimodal) models, attacks on email agents and MCP, and provenance and information-flow defenses. The gap we fill sits at their intersection.

2

A. Indirect prompt injection and benchmarks Indirect prompt injection, in which instructions are planted in content the agent will read, was shown against real LLMintegrated applications by Greshake et al. [12] and systematized subsequently [13], [14]. Benchmarks now measure the problem in tool-integrated agents, including InjecAgent [15], AgentDojo [16], and the tool-risk emulator ToolEmu [17]. These establish the threat and evaluation methodology but operate on text channels. B. Steganographic injection against (multimodal) models Instructions can be concealed in images using spatial (least-significant-bit), frequency-domain (DCT and the discrete wavelet transform, DWT), or learned neural steganography [18], [19], [20], remaining visually imperceptible while carrying hundreds of characters. Recent attack studies report 24–32% attack success against production visionlanguage models and demonstrate near-perfect concealment metrics [21], [22], [23], and related cross-modal jailbreaks hide payloads in images paired with benign prompts [24], [25], [26], [27]. The broader risk of information hiding as a malware carrier is long established [28]. These works feed a single crafted image directly to a model; they do not consider email delivery, multi-agent pipelines, MCP tool calls, or a provenance defense. C. Email-agent and MCP injection Independent of steganography, practitioners have repeatedly hijacked email-summarization agents using text carriers such as zero-pixel HTML [4], [5], [6], national guidance now documents MCP-specific risks including poisoned tool output consumed by downstream agents [29], and tool-metadata poisoning has its own detectors and protocols [30], [31]. These text carriers are, by construction, visible to text content scanners; our image carrier is not. D. Provenance and information-flow defenses The closest line of work labels agent data by origin and blocks untrusted-origin actions, building on classical language-based information-flow control [32]. Runtime policy-enforcement points intercept MCP tool calls [9], [8]; information-flow systems propagate taint across agent steps [10], [11], [33], [34]; CaMeL separates trusted control flow from untrusted data flow [35]; MELON offers a provable construction [36]; multi-agent pipelines coordinate verifier agents [37], [38]; and trace-level provenance auditors and surveys attribute sink actions to sources [7], [39], [40]. The most directly related system, NeuroTaint [7], explicitly states that it does not consider multi-modal attacks or semantic steganography, attaches labels when a text-returning tool returns (not at a decode transform), uses unsigned labels, and audits completed traces rather than blocking at runtime. Our contribution occupies exactly this declared gap: a cross-modal carrier, a label minted at the decode boundary, cryptographic binding (via a keyed MAC [41]) that survives handoffs,

ARXIV PREPRINT

Fig. 1. System context of cross-modal trust laundering and the defense.

and runtime enforcement. We claim neither provenance nor steganography as novel; we claim their decode-time junction. Table I positions the most closely related systems against this study along the axes that define the gap: whether a crossmodal (steganographic) carrier is in scope, whether the trust label is minted at the decode transform rather than at text-tool return, whether the label is cryptographically bound against tampering across agent handoffs, whether enforcement is at runtime versus offline audit, and whether the setting is a multiagent MCP pipeline. III. Threat Model and System Overview Fig. 1 shows the end-to-end setting. A trust boundary separates the operator-trusted control flow from externallysupplied content; the defense binds a trust label at the point where the concealment transform is reversed, so the boundary is enforced at the critical-tool sink rather than at text ingestion. Attacker capability. The attacker can send the victim an email. They cannot access the victim’s system prompt, model weights, keys, or execution environment. The payload is embedded in a signature logo (inline cid: or data: URI) using steganography. Victim pipeline. The victim runs an automated inbox summarizer built as a multi-agent MCP system: a coordinator dispatches worker agents; at least one worker’s pipeline includes an image-decoding step over inline images. Critical MCP tools (export_secrets, send_email) exist and are reachable by the orchestrator. Mediation and lineage. All tool invocations pass through the MCP layer, which is trusted: it mints every binding with a key that never leaves it, and it maintains—independently of the agents—a per-context provenance ledger recording the

3

decode-origin lineage that enters each context and the resolved argument lineage of each tool call. Agents receive opaque handles to tool results, never the key, and cannot edit the ledger. This mediation is what lets the verifier decide on lineage the layer recorded rather than on lineage an agent asserts; its cost and residual are discussed in Sections VIII and IX. Trigger. Execution requires no victim action beyond running the summarizer. The payload becomes instructions only when the decode step runs; a summarizer that treats the logo as opaque bytes does not surface it. This decode step is a stated precondition—and is exactly where our defense acts. Mapping to OWASP Top 10 for Agentic Applications (2026). The attack chain maps to the agentic Agentic Security Initiative (ASI) taxonomy [42] as follows: ASI01 Agent Goal Hijack (the decoded instruction redirects the agent via indirect injection); ASI06 Memory & Context Poisoning (the poisoned logo enters the agent’s working context); ASI07 Insecure InterAgent Communication (the untrusted payload is relayed between workers as trusted peer output); and ASI02 Tool Misuse & Exploitation (a critical MCP tool is driven by the laundered instruction). Our defense is, in these terms, an ASI07 control that makes inter-agent provenance tamper-evident. We note that OWASP publishes no standalone “MCP Top 10”; MCPspecific risk is captured within the agentic (ASI) list above and in dedicated protocol guidance such as the NSA’s MCP security considerations [29]. IV. Attack: Cross-Modal Trust Laundering This section details the attack: the three steganographic carriers that hide the payload (§IV-A), how the poisoned logo is delivered in an email signature and why neither antivirus nor email security intercepts it (§IV-B), and how the chain maps to the OWASP LLM Top 10 (§IV-C). A. Carriers We implement three carriers spanning the spatial, frequency, and metadata branches of the image-injection taxonomy [23]. All share a self-delimiting framed payload (a magic marker, a type byte, and a length prefix). (1) LSB: the payload bits replace the least-significant bit of RGB channels in a passwordkeyed pseudorandom permutation. (2) DCT: within each 8 × 8 block, a mid-frequency coefficient is quantized to an even/odd multiple of a step Q to encode one bit, which survives the integer round-trip to pixels. (3) Metadata: the framed payload is Base64-encoded into a PNG text chunk. Fig. 2 shows a cover logo, its stego version carrying a payload, and the amplified set of changed pixels; the two logos are indistinguishable to the eye. B. Delivery and laundering The poisoned logo is placed inline in an HTML businessemail signature. The summarizer’s image step recovers the logo and a worker calls the corresponding MCP decode tool, surfacing the hidden instruction. In the undefended pipeline the worker relays the decoded text to peer agents and the

ARXIV PREPRINT

4

TABLE I Positioning of related systems against this study. System CaMeL [35] MELON [36] ProvenanceGuard [8] MCP PEP [9] SafeFlow [10] NeuroTaint [7] Stego injection [21], [22] Email hijack [4] This study

Cross-modal carrier

Decode-time label

Signed/tamper-evident

Runtime enforce

Multi-agent MCP

no no no no no no yes no yes

no no no no no no n/a n/a yes

no no no no no no n/a n/a yes

yes yes yes yes yes audit n/a (attack) n/a (attack) yes

partial no yes yes yes yes no no yes

Fig. 2. Cover logo, stego logo, and amplified pixel difference.

orchestrator, which cannot distinguish it from legitimate intermediate output and executes the implied critical tool. Figure 3 shows the full chain as a message sequence, contrasting the undefended leak with the defended block. Reading Figure 3 left to right, the chain proceeds in four shared steps and then diverges. (1) The attacker sends an ordinary business email whose signature logo carries the stego payload. (2) The victim’s inbox-summarization agent processes the signature and its image step hands the logo to a worker. (3) The worker calls the extract_stego MCP tool, which decodes the payload and—under our defense— mints an HMAC-signed Untrusted binding at that instant. (4) The worker relays the decoded text, with its binding, to the orchestrator. In the undefended pipeline the orchestrator cannot tell the laundered text from legitimate output: (5) it calls the critical export_secrets sink and (6) the secrets are exfiltrated to the attacker—credentials leaked. In the defended pipeline the same critical call is first routed to the verifier: (5′ ) the orchestrator requests the call and presents the binding, (6′ ) the verifier recomputes the HMAC, finds the lineage is Untrusted, and (7′ ) returns Block—no secrets leave. The payload decodes identically in both runs; only the lineage check differs, which is why containment, not detection, is what stops the leak. a) Embedded vs. attached, and why email defenses miss it: Signature logos are almost always embedded—an inline cid: MIME part or a data: URI in the HTML body—rather than attached as a separate file. Embedded images render automatically, travel with every message, and are the normal way a brand mark appears, so they draw no attention; attached files are more likely to be sandboxed or hash-scanned. Conventional email defenses do not stop this carrier. Antivirus matches known-malware byte signatures, but an LSB, DCT, or metadata payload in a well-formed PNG is not malware—it is a valid image with sub-visual pixel perturbations or a benign-looking text chunk, so there is no signature to match; this is the classic

information-hiding evasion of content scanners [28]. Secure email gateways and data-loss prevention (DLP) inspect text, URLs, sender reputation, and attachment hashes or types— not steganalysis of inline logos, which is costly, false-positiveprone, and outside their threat model. Crucially, the payload is inert at the mail layer: it is pixel noise until a decode step runs, and that step executes downstream in the agent pipeline, after email security has already passed the message. Content disarm-and-reconstruct (CDR) can in principle reencode images, but is typically applied to attachments rather than inline signature logos and does not reliably strip metadata or frequency-domain payloads. The carrier therefore crosses every perimeter control intact and only “arms” inside the agent. C. Mapping to OWASP Top 10 for LLM Applications In the classic application taxonomy [2], the chain exercises LLM01 Prompt Injection (the carrier is an indirect injection), LLM02 Insecure Output Handling (decoded tool output is consumed without isolation), LLM08 Excessive Agency (the orchestrator calls a critical tool unmediated), and LLM06 Sensitive Information Disclosure (the resulting exfiltration). V. Defense: Decode-Time Provenance Binding We present the defense in five parts: the guiding principle of containment over detection, the mechanism and its two algorithms, the security invariant it enforces, the adversary model, and a proof sketch reducing security to the infeasibility of forging the HMAC. A. Principle: contain, do not detect A detector that tries to decide whether an image hides a payload must win against every present and future carrier and every stealth budget; it fails open on anything it did not anticipate. We instead assume that any output of a concealmentreversing tool is untrusted and contain it. The payload may decode perfectly; it still cannot drive a critical action. B. Mechanism Let D be the set of decode tools (those that reverse a concealment transform: stego extraction, metadata decode, Base64 decode, OCR) and C the set of critical tools (sideeffecting sinks). All tool I/O is mediated by the MCP layer. When a tool t returns payload p from input bindings I, the layer mints a binding ℓ = (p, t, τ, π, δ, σ) whose dependency

ARXIV PREPRINT

5

Fig. 3. Attack-chain sequence: undefended leak vs. defended block.

set δ records the identifiers of I—resolved by the layer from the argument handles it issued, not from anything the agent asserts. The trust label is contagious, τ = Untrusted iff t ∈ D or ∃ i ∈ I : τi = Untrusted, π records the provenance, and σ = HMACk (p∥t∥τ ∥π∥δ) signs the whole record with a layer-held key k (Algorithm 1). The layer additionally keeps, per execution context, a taint set of the untrusted decode origins that have entered that context— its independent record of lineage that need not pass through a tool argument. A downstream agent that alters any field or drops σ fails verification; an agent cannot mint a binding, because the key is confined to the layer. At a critical call the layer runs EnforceCritical (Algorithm 2). It does not consult a dependency set the agent supplies: it reconstructs lineage from its own ledger—the transitive trust of the resolved argument closure and the context taint set—and blocks if either is untrusted, if a binding fails HMAC verification, or if a binding references a dependency the ledger cannot resolve. A single data-only label on an argument therefore cannot authorize a call whose context carries an untrusted decode origin. Concretely, the ledger is two structures the layer owns and the agents never touch: a binding store that maps each binding identifier to its signed record, and, per execution context, a taint set holding the identifiers of the untrusted decode origins that have entered that context. Agents hold only opaque handles—the identifiers—so the single value an agent can pass to a later call is a reference the layer resolves against the store it alone wrote; the agent can neither mint a binding (the key

never leaves the layer) nor assert a dependency the store does not already record. This is the difference from a scheme that ships the trust label alongside the data and re-reads it at the sink: there, a compromised relay chooses which label arrives; here, the relay chooses only which handles it presents, and the trust decision is recomputed from the layer’s own record of what those handles depend on. Resolving a handle therefore reconstructs the same lineage the layer observed at mint time, independent of how the agent frames the call. Inter-agent messages are mediated the same way. When an agent relays a tool result to an agent in another execution context, the message passes through the layer, which binds it to its source and propagates the taint to the destination context; an Untrusted decode origin in one agent therefore taints the context of any agent it is mediated into. The one path this does not cover—an agent paraphrasing a decoded instruction into free text that leaves the mediated channel—is the scope boundary stated with the invariant and measured in Section VI. Concretely, when extract_stego returns the decoded string p, the layer stamps τ = Untrusted (since extract_stego ∈ D), signs the record, and hands the agent only the opaque handle id(ℓ). If that handle later reaches a critical call—or if the decoded text merely entered the context—the untrusted record is found in the closure or the context taint and the call is blocked. The two algorithms below formalize this mint-then-check pair. Algorithm 1 both signs the label and records lineage in the layer’s ledger at decode time; the complementary check, Algorithm 2, runs when an agent later proposes a critical call and decides on the ledger rather than on an agent-presented

ARXIV PREPRINT

6

Algorithm 1 MintBinding (in the MCP layer, at tool return)

Algorithm 2 EnforceCritical (in the MCP layer, at a sink)

Require: payload p, tool t, input bindings I, context c, set D, key k 1: δ ← { id(i) : i ∈ I } {resolved by the layer} 2: if t ∈ D or ∃ i ∈ I : τi = Untrusted then 3: τ ← Untrusted 4: else 5: τ ← Trusted 6: end if 7: π ← decode:t if t ∈ D else tool:t 8: m ← canonical(p, t, τ, π, δ) 9: σ ← HMACk (m) 10: record ℓ = (p, t, τ, π, δ, σ) in ledger L 11: if τ = Untrusted then 12: add id(ℓ) to the taint set of context c 13: end if 14: return handle id(ℓ) to the agent

Require: tool g, context c, argument handles H, ledger L, set C, key k 1: if g ∈ / C then 2: return Allow 3: end if 4: resolve H via L; let S be their transitive dependency closure 5: for all ℓ = (p, t, τ, π, δ, σ) ∈ S do 6: if σ ̸= HMACk (canonical(p, t, τ, π, δ)) then 7: return Block {forged or stripped} 8: end if 9: if some d ∈ δ is unresolved in L then 10: return Block {incomplete lineage} 11: end if 12: if τ = Untrusted then 13: return Block {untrusted data lineage} 14: end if 15: end for 16: if taint(c) \ promoted(c) ̸= ∅ then 17: return Block {untrusted context lineage} 18: end if 19: return Allow

binding. The two algorithms are deliberately asymmetric in what they trust. MintBinding runs with full authority inside the tool boundary: it sees the real inputs, assigns the label, and is the only place a binding is ever created, so every record in the ledger is one the layer wrote itself. EnforceCritical runs where the agent is in control and therefore trusts nothing it is handed: it treats the presented handles purely as lookups, rebuilds the dependency closure from the ledger, and recomputes each HMAC before reading a label, so a tampered or fabricated field is rejected before it can influence the decision. The closure walk is what turns a single untrusted leaf into a blocked call no matter how many benign hops sit between them: a critical call inherits the trust of its weakest transitive input, and the context-taint check at the end catches an untrusted origin that reached the call through influence rather than through a named argument. Neither step inspects the payload text, so the decision is identical whatever the decoded instruction says. The distinction that makes the guarantee sound is where lineage lives. EnforceCritical never consults a dependency set asserted by an agent; it reconstructs lineage from the layer’s ledger and context taint. Consequently a compromised agent cannot launder a critical call by attaching a legitimately signed Trusted binding from an unrelated benign tool while omitting the untrusted decode origin that actually drove the call: the omitted origin is still recorded in the context taint the layer maintains, so the call is blocked. We verify this directly in Section VI. C. Security invariant The mechanism provides two distinct guarantees, and it is their conjunction—not the HMAC alone—that is the contribution: • Data-provenance security. A critical action cannot be authorized using a forged or improperly relabeled data dependency (enforced by the signed binding). • Context-influence containment. A critical action cannot execute after an Untrusted instruction has influenced the

relevant execution context without authorized clearance (enforced by the layer-maintained ledger and context taint). Under the assumptions that (i) the signing key k is confined to the MCP layer, (ii) every concealment-reversing tool is registered in D, (iii) the layer mediates every critical call, and (iv) within a fully mediated execution context the layer records the complete lineage of each invocation—its resolved argument dependencies and the decode origins entering the context, including across mediated inter-agent messages—the mechanism enforces: In a fully mediated execution context, no critical tool call executes whose transitive lineage—data or context—includes an Untrusted decode origin, unless an audited trusted promotion cleared that specific origin. The HMAC delivers data-provenance security: a relaying agent cannot promote Untrusted → Trusted, and a remote verifier in another domain can check trust from the signature alone. The ledger delivers context-influence containment: trust is decided on lineage the layer holds, not on a label an agent presents, which is what defeats valid-label substitution. The ablation in Section VI shows these two are necessary and non-interchangeable. Assumption (iv) is the mechanism’s loadbearing obligation and its honest boundary: influence that leaves the mediated path—a decoded instruction an agent paraphrases into free text delivered out of band—is not recorded, so the guarantee is scoped to fully mediated contexts and we measure the boundary directly (Section VI, Table V).

ARXIV PREPRINT

D. Adversary model We model the adversary A as controlling all externallysupplied content and the behavior of every agent in the pipeline except the MCP layer and the verifier. Formally, A may (a) choose the carrier image and payload, (b) read any binding ℓ in transit, (c) replace a binding with any value of its choice before it reaches the verifier, and (d) choose which handles to present at a critical call, including omitting or substituting them— this captures a compromised or injection-steered worker that relays, rewrites, fabricates, or selectively presents labels. A does not obtain the signing key k, cannot execute code inside the MCP layer, cannot edit the layer’s ledger or context taint, and cannot bypass the verifier at the critical-tool boundary. These trusted components, the ledger, and k are the trusted computing base. A wins if a critical tool g ∈ C executes whose true lineage includes an Untrusted decode origin with no audited promotion. E. Proof sketch Suppose A wins. By mediation (iii) the call passed EnforceCritical. Let o be an Untrusted decode origin in the call’s true lineage, which exists because A wins. By (iv) o was minted Untrusted (Algorithm 1) and recorded by the layer either in the resolved argument closure S or in the context taint of c. Three cases. (1) Data lineage: o ∈ S. Then EnforceCritical recomputed o’s HMAC, saw τ = Untrusted, and blocked—a contradiction—unless A presented a variant o′ with τ = Trusted that verifies under k; but o′ was never minted by the layer, an existential forgery against HMAC [41], with probability negligible in the key length. (2) Context lineage (valid-label substitution): o is in taint(c) and A attached only a benign Trusted binding as the argument. EnforceCritical still blocks on the nonempty context taint; evading this requires editing the layer’s ledger, excluded by (iv). (3) The decode tool is not in D: this violates (ii)—an unregistered decoder, not a defeat of the mechanism. Hence, with a complete decode set, a confined key, and layer-maintained lineage, A’s winning probability is negligible. The argument is information-flow, not content: it never inspects what p says, which is why the guarantee is wording- and carrier-independent. VI. Evaluation Our evaluation targets the security mechanism directly. The attack bank is a curated, adaptive set chosen to defeat textchannel defenses, and our experiments stress the assumptions on which the information-flow guarantee of Section V rests— a complete decode set, a tamper-evident HMAC binding, boundary mediation, and layer-maintained lineage. On a real MCP testbed we ask: does the binding stop the attack where text-channel defenses do not (attack success by defense); does it resist valid-label substitution by a compromised agent; which of its four components are necessary (ablation); does it hold through the pre/post/defended lifecycle; does it survive relay tampering and multi-hop handoffs; what happens when the decode set is incomplete or over-broad; does it preserve legitimate-task utility; are the carriers imperceptible; and what does it cost?

7

A. Testbed Agents are driven by Qwen/Qwen2.5-0.5B-Instruct locally; the security decision is made by the deterministic layer and does not depend on the model. The MCP server is a real FastMCP process accessed over stdio; decode tools mint bindings per Algorithm 1 and the layer maintains the ledger of Section V. The attack bank is 24 payloads— three carriers (LSB, DCT, metadata) × eight evasions (plain, benign-worded, Base64, token-split, Cyrillic homoglyph, zerowidth, Unicode-confusable, and HTML-comment wrapping)— designed to defeat keyword and regex matching. Each attack is delivered in an HTML signature email, decoded by Worker1 via a live MCP call, and the signed binding is relayed across peer hops before the verifier decides. We compare five configurations: undefended; a keyword/data-loss-prevention (DLP) content scanner; a regex intent parser; an in-process data-flow taint tracker—an information-flow baseline that labels decode output untrusted but carries no cross-domain cryptographic binding and trusts agent-presented labels; and our decode-time provenance binding. All tables and figures are reproduced by the released notebook. B. Attack success by defense Table II reports attack success rate (ASR) over the 24payload bank. The undefended pipeline leaks on every attack. The keyword scanner and the regex parser each block only the payloads whose sensitive terms survive Unicode normalization (plain, HTML-comment, and some confusable variants) and fail on the benign-worded, Base64, token-split, homoglyph, and zero-width evasions—62.5% ASR each. The taint baseline and our mechanism both reach 0% within a single trust domain, because both treat decode output as untrusted at the source. We are explicit about what this baseline is: an unsigned, agent-mediated taint design—it trusts agent-presented labels and has no cross-domain cryptographic binding—not a state-of-the-art provenance system. The comparison therefore isolates the two design properties our mechanism adds (cryptographic authentication and layer-maintained lineage), not a claim to beat a specific published defense; where published systems sit on those two axes is summarized in Table I. The baseline and our mechanism diverge under adversarial relaying, isolated in the ablation and cross-context subsections below. TABLE II Attack success rate by defense over 24 payloads (lower is better). Defense

Leaks

n

ASR

Undefended (no checks) Content scanner (keyword/DLP) Regex intent parser Data-flow taint (IFC baseline) Decode-time provenance (ours)

24 15 15 0 0

24 24 24 24 24

100% 62.5% 62.5% 0% 0%

The two text-channel baselines inspect the decoded text, so each new wording or carrier reopens the gap; Unicode normalization recovers the plain, comment-wrapped, and confusable variants but not the homoglyph, zero-width, Base64, or tokensplit ones. Provenance binding does not read the payload at all—it blocks on lineage—so none of these evasions change

ARXIV PREPRINT

8

its outcome. Fig. 4 renders this as a step from full compromise down to zero that the lineage-based defenses reach; the distinction between the taint baseline and our mechanism is not ASR within one domain but tamper-resistance across an untrusted relay, isolated next.

tracking (reverting to deciding on the agent-presented binding) still blocks forgery via the HMAC but leaks valid-label substitution, because a genuine Trusted binding from an unrelated tool passes an HMAC check. Cryptographic authentication and layer-maintained lineage are therefore both necessary and noninterchangeable: the HMAC alone does not stop substitution, and the ledger alone does not survive a cross-domain relay. The taint baseline of Table II corresponds to the “− cryptographic auth” row. TABLE IV Four-component ablation: effect of disabling each component on three attacks (blocked vs. LEAK).

Fig. 4. Attack success rate by defense across the 24-payload bank.

Configuration

Honest

Substitution

Forged relay

Full mechanism − decode marking − cryptographic auth (HMAC) − trusted lineage tracking − sink mediation

blocked LEAK blocked

blocked LEAK blocked

blocked LEAK LEAK

blocked LEAK

LEAK LEAK

blocked LEAK

C. Resisting valid-label substitution We test the reviewer-critical case directly. A compromised orchestrator holds a legitimately signed Trusted binding from a benign read_config call and attaches it as the argument of export_secrets, while the decision to call the sink derives from an Untrusted extract_stego output that it omits from the presented lineage. A verifier that trusts the agent-supplied binding Allows the call. The layer-maintained check Blocks it: the omitted decode origin is still in the context taint the layer recorded, so trust is decided on lineage the agent does not control (Table III). A clean context, with no decode origin, still allows a legitimate critical call. This is the concrete difference between verifying a label and maintaining lineage—the distinction on which the central guarantee rests. TABLE III Valid-label substitution: enforcement that trusts the agent-supplied binding vs. layer-maintained lineage. Enforcement

Decision

Agent-supplied binding only (naive) Layer-maintained, dependency omitted Layer-maintained, dependency in arguments Layer-maintained, clean context

allow (leaks) block block allow

D. Component ablation The mechanism has four components—decode marking, cryptographic authentication (the HMAC), trusted lineage tracking (the layer’s ledger and context taint), and sink mediation—and each defends a distinct attack. Table IV disables one component at a time in the full implementation and measures three attacks: the honest in-domain attack, valid-label substitution (in-domain), and a forged Trusted label carried across an untrusted relay to a remote verifier that holds only the presented binding (cross-domain). The full mechanism blocks all three. Removing marking leaks everything (nothing is flagged untrusted). Removing mediation leaks everything (no enforcement point). The two middle rows are the ones that disambiguate the design: removing the HMAC still blocks the in-domain attacks, because the ledger decides, but leaks the cross-domain forged relay, because a remote verifier without the ledger has only the signature to trust; removing lineage

E. Cross-context influence propagation A natural question is whether taint survives an inter-agent message boundary, not just a tool-return handle. It does: Table V shows Agent A decoding an untrusted instruction and handing it to Agent B in a separate execution context. When the message is carried on a mediated channel—through the layer, as assumptions (iii) and (iv) require of inter-agent communication—the layer binds it to its source and propagates the taint, so B’s critical call is blocked (untrusted context lineage). This is the result: context taint crosses every mediated boundary, agent-to-agent messages included. The second row marks the edge of the model rather than a result: a channel the layer does not mediate (A paraphrasing into free text on a side path) is outside assumptions (iii) and (iv) by construction—in a fully mediated deployment no such channel exists, and a deployment that leaves one unmediated has simply not placed the control on it. Cryptographic authenticity cannot stand in for a dependency that was never recorded, so the scope is stated plainly with the invariant: the guarantee is for fully mediated execution contexts. Extending capture into in-model paraphrase is discussed in Section IX. TABLE V Cross-context propagation: an untrusted decode in Agent A reaches a critical call in Agent B’s context. Channel from A to B

B’s critical call

Mediated inter-agent message (in scope) Unmediated side channel (outside the model)

block (taint propagated) not covered

F. State transitions Table VI walks one benign-worded payload through three system states. Pre-attack, the clean logo yields a normal summary and no critical call. Post-attack undefended, the payload decodes and the critical sink executes, leaking secrets. Post-attack defended, the payload decodes identically but the verifier blocks the sink; no secrets leave. The decoded instruction is present in the agent’s context in both post-attack rows— the defense does not try to keep it out—so the only difference between a breach and a safe run is whether the critical call is

ARXIV PREPRINT

9

permitted to fire, which is precisely the boundary the binding governs. TABLE VI System state across clean, undefended, and defended runs. State

Critical call

Secrets leaked

Pre-attack (clean logo) Post-attack (undefended) Post-attack (defended)

none export_secrets executed blocked

no yes no

G. Tamper-resistance across handoffs

Fig. 5. Per-carrier distortion (PSNR and SSIM).

Table VII evaluates a malicious relaying agent. A genuine Untrusted binding is blocked at a critical sink; an attempt to forge a Trusted label or to strip the HMAC fails verification and is also blocked; a genuinely trusted origin (a non-decode tool such as authenticated user input) is allowed. The binding therefore survives relaying intact. TABLE VII Verifier decision under relay tampering. Relay action

Verifier decision

Genuine Untrusted label Forged Trusted label Stripped HMAC Honest Trusted origin

block block (HMAC fails) block (HMAC fails) allow

I. Overhead Table IX reports the cost of the mechanism, measured on commodity hardware over 2 × 104 iterations after warm-up. Minting a binding and verifying it are pure HMAC-SHA256 operations over a short canonical string, each under 10 µs; their combined cost of ≈ 17 µs is added once per critical call. For reference, a single decode tool call over the MCP stdio transport (warm session) takes a median of ≈ 11 ms, so the binding adds about 0.16% to a tool invocation and is negligible beside model inference, which is orders of magnitude larger. These figures are for the cryptographic operations; the full enforcement path, which also inserts into the ledger and traverses the dependency closure, is characterized separately below and is what a deployment should budget for.

H. Carrier distortion

TABLE IX Mechanism overhead per operation.

Table VIII reports peak signal-to-noise ratio (PSNR) and structural similarity (SSIM) between cover and stego logos. The metadata carrier is lossless (the pixels are unchanged); the LSB carrier is near-lossless (≈76 dB); the DCT carrier trades a lower PSNR (≈18 dB, SSIM ≈0.94) for robustness to the pixel round-trip. We stress that PSNR and SSIM bound pixellevel distortion and do not by themselves establish perceptual imperceptibility, particularly for the DCT carrier at ≈18 dB; we therefore treat these as distortion metrics, offer the amplified pixel-difference visualization (Fig. 2) as the perceptual check, and leave a formal subjective study to future work. The security guarantee does not depend on imperceptibility: containment blocks the payload whether or not a human would notice the carrier. TABLE VIII Carrier distortion between cover and stego logos (distortion metrics, not a perceptual claim). Carrier

PSNR (dB)

SSIM

LSB DCT Metadata

high (≈76) moderate (≈18) lossless (pixels unchanged)

≈1.000 ≈0.94 1.000

A defender nonetheless cannot rely on visual inspection or a perceptual-hash gate to catch the metadata and LSB carriers, which sit at or near the lossless ceiling; the DCT carrier is the one a perceptual gate might flag, which is why we do not claim it is imperceptible. Fig. 5 renders the per-carrier PSNR and SSIM, with the lossless metadata bar capped so the axis stays readable.

Operation

Cost

MintBinding (HMAC sign) EnforceCritical (HMAC verify) Combined per critical call MCP decode round-trip (warm) Added overhead vs. one decode call

≈ 8.3 µs ≈ 8.7 µs ≈ 17 µs ≈ 11 ms ≈ 0.16%

The revised mechanism does more than sign: MintBinding inserts into the ledger and EnforceCritical walks the dependency closure and checks context taint. We therefore benchmark the complete path as these grow (Table X). Minting stays near 11 µs regardless of chain depth (ledger insertion is amortized O(1)). Enforcement is linear in the size of the dependency closure it traverses: ≈ 10 µs at depth 1, rising to ≈ 0.68 ms at depth 100 and ≈ 6.6 ms at depth 1000—the last comparable to a single decode round-trip and reached only by pathologically deep lineage. It is effectively flat (≈ 6 µs) in the number of concurrent tainted contexts, since the taint lookup is keyed by context. For realistic lineages (closure depth in the tens) the full path stays well under 0.1 ms. TABLE X Full enforcement-path cost vs. dependency-closure depth and number of concurrent tainted contexts. closure depth Operation

1

10

100

1000

MintBinding (µs) EnforceCritical (µs)

10.7 9.5

12.0 72.6

12.9 680

10.9 6605

1

100

1000

EnforceCritical vs. contexts (µs)

6.2

6.4

6.3

ARXIV PREPRINT

J. Decode-set completeness The security invariant assumes every concealment-reversing tool is registered in the decode set D. Because this is the assumption a reviewer will press, we exercise it directly. Table XI reports three configurations against the same stego attack and a legitimate critical call. With the correct D the attack is blocked and the legitimate call is allowed. If the attacker reaches the payload through a decoder that is missing from D (e.g. an unregistered audio or document extractor), its output is minted Trusted and the attack leaks—the failure is an unregistered decoder, not a defeat of the mechanism. Conversely, an over-broad D that labels a benign non-decode tool Untrusted falsely blocks a legitimate critical call. The set is thus the single knob that trades missed-decoder risk against false blocks, which is why we recommend it be a small, audited allow-list fixed at tool registration.

10

TABLE XIII Legitimate-task completion and false blocks, with and without the audited trusted-promotion path. Regime

Completion

False blocks

Attack blocked

No promotion Trusted promotion

2/3 (67%) 3/3 (100%)

1 0

yes yes

M. Realistic decode trigger

Section III assumes a worker invokes a decode step on a signature logo; a reviewer may reasonably ask why an ordinary summarizer would do so. We separate realistic preconditions from the controlled proof-of-concept. The metadata, Base64, and OCR carriers need no bespoke decoder: a summarizer that extracts text from an image (OCR) or parses embedded metadata to caption or describe an attachment surfaces these payloads as a side effect of normal multimodal handling, and contemporary agents routinely route images to exactly such TABLE XI tools. We model this in the testbed with a content-type router Decode-set completeness: outcome vs. configuration. that dispatches an inline image to an image-analysis tool, Decode set D Stego attack Legitimate critical call which in turn invokes the registered extractor; the decoded text Correct blocked allowed then enters the agent’s context. The LSB and DCT carriers are Missing decoder (unregistered) leaks allowed stronger-attacker variants that require a decoder matching the Over-broad (benign tool included) blocked false block concealment scheme; we include them to stress the mechanism across the spatial and frequency branches, not as claims about K. Label integrity across handoffs default summarizer behavior. In every case the defense acts We next stress the binding under relaying. Table XII shows identically, because registration in D—not the reason the tool the verifier decision after honest relays and under a compro- ran—determines the label. mised worker. A genuine binding verifies and is correctly blocked after 1, 3, 5, and 10 honest hops—the label travels VII. Deployment intact. A compromised worker that rewrites the decoded text, promotes the label to Trusted, or strips the binding entirely The mechanism is a drop-in addition to an MCP server and always fails verification and is blocked, because none of its tool-call boundary; it requires no change to the agent model these can reproduce the server-held HMAC. This complements or the orchestration logic. Table VII by showing integrity is preserved across depth, not Where it lives. MintBinding runs inside each tool handler at just at a single hop. return time and writes to the layer’s ledger; EnforceCritical runs in the client’s tool-dispatch path immediately before a TABLE XII Label integrity across relay hops and under a compromised worker. call executes and reads that ledger. Both are a few lines over a standard HMAC library plus an in-memory ledger keyed by Relay scenario Verifier decision Honest relay, 1 / 3 / 5 / 10 hops verifies; critical call blocked execution context. The signing key k is generated once per Compromised: rewrite payload, keep HMAC block (HMAC mismatch) server process and never leaves it; bindings travel with tool Compromised: forge Trusted label block (HMAC mismatch) results as an extra signed field, transparent to agents that do Compromised: strip binding block (no valid label) not inspect it, while the ledger and context taint stay inside the layer and are never exposed to agents. L. Legitimate-task utility Configuring D and C. The decode set D enumerates tools A containment control is only deployable if it does not that reverse a concealment transform (stego and metadata block legitimate work. Table XIII reports three legitimate extractors, Base64 decoders, OCR); the critical set C enumercritical tasks, one of which—an authorized payment that uses ates side-effecting sinks (secret export, outbound email, file an optical-character-recognition (OCR)’d invoice number— write, payment). Both are short, server-authored allow/deny legitimately derives from a decode tool. Without the trusted- lists reviewed at tool registration—the same point at which a promotion path, that task is falsely blocked (67% completion, tool’s schema is already vetted—so no runtime classification one false block), the expected cost of treating every decode is needed. origin as untrusted. With an audited promotion that re-labels Trusted promotion. When a decoded artifact must legitithe specific OCR’d value Trusted, all three tasks complete mately drive an action (e.g. an OCR’d invoice number the (100%, zero false blocks) while an unauthorized attack from operator asked to pay), an explicit, audited promotion step the same decode origin remains blocked, because the attacker re-labels that specific value Trusted under human or policy cannot invoke the promotion. Promotion is thus the deployable authorization and records the clearance in the context ledger. complement to containment: it restores utility at a controlled, The promotion is logged with the original binding, so the logged point without reopening the vector. provenance trail is preserved. We implement and evaluate this

ARXIV PREPRINT

11

path rather than leaving it as a proposal: it raises legitimatetask completion to 100% with no loss of protection (Table XIII). Distributed enforcement. When tools span multiple hosts, verification uses either a shared key over a secured channel or a public-key signature in place of the HMAC; the algorithms are unchanged apart from the sign/verify primitive. VIII. Design Trade-offs Containment vs. detection. Binding contains rather than detects, so it is robust to unseen carriers and wording, but it cannot recover the benign information a decoded artifact might also carry: a legitimately hidden watermark read by a decode tool is labeled Untrusted like any other. Deployments that need such content must add an explicit, audited trustedpromotion path. Scope of protection. The mechanism guards actions, not summary text. A laundered instruction can still corrupt the natural-language summary the agent returns; binding prevents it from reaching a critical tool, not from influencing prose. This bounds the defense to the excessive-agency and disclosure harms, which is the right scope for a tool-boundary control. Decode-set completeness. Security rests on every concealment-reversing tool being registered in D. An unregistered decoder is a gap; conversely, over-broad registration (labeling non-decoding tools Untrusted) raises false blocks. The set is small and auditable in practice, but its maintenance is an operational cost. Key management. Tamper-evidence depends on confining the HMAC key to the MCP layer. Distributing enforcement across hosts requires a shared-key or signature-verification deployment, trading simplicity for scalability. Lineage capture. Soundness against valid-label substitution rests on the layer maintaining the complete lineage of each invocation (assumption iv): the resolved argument dependencies and the decode origins entering each context. This requires the layer to mediate tool I/O and keep a per-context ledger—more than a stateless signature check, though still far cheaper than inference. Its residual is influence the layer cannot observe: if decoded text leaves the mediated path entirely (e.g. an agent paraphrases it out of band into a context the ledger does not cover), context taint cannot record it. We therefore treat context taint as a conservative over-approximation that errs toward blocking, and note that completeness of lineage capture, not the cryptography, is the property a deployment must get right. Granularity. We bind at message/tool-result granularity, not at token granularity inside model reasoning. This is simple and model-agnostic but cannot express partial trust within a single decoded blob. IX. Limitations Our evaluation remains a controlled testbed: 24 payloads across three carriers and eight evasions, one cover logo, one small local model, and a keyword/regex scanner and an inprocess taint tracker as baselines. This is broader than a single attack bank—it adds a label-substitution stress test, a four-component ablation, a legitimate-task evaluation, and an

information-flow baseline—but it is still not a productionscale measurement: larger and more varied payload banks, multiple cover images and model families, a modern learned or provenance-aware detector as a baseline, and—most important for practical impact—a demonstration inside an existing production email-agent workflow rather than our controlled summarizer, all remain future work, and operational-stealth measurement frameworks [43] suggest one axis for that expansion. Our proof sketch reduces security to two properties: the infeasibility of forging the HMAC under key confinement, and the completeness of lineage capture by the layer (assumption iv). The former is standard; the latter is an implementation obligation, and we are explicit that the guarantee is scoped to fully mediated execution contexts. Within that scope, taint propagates across every mediated boundary, including inter-agent messages (Table V). A channel the layer does not mediate is outside the model by construction; the one substantive extension it points to is in-model influence—an agent paraphrasing a decoded instruction into its own output— which a mediated side channel would not capture and which tainting an agent’s output whenever its input context is tainted would address. We leave that, a fully machine-checked proof, and a formal treatment of lineage completeness to future work. Finally, the defense protects actions, not summary integrity: a laundered instruction it blocks at the sink can still skew the natural-language summary the agent returns. We bound this harm (no critical action executes) but do not eliminate it; quantifying the residual summary-corruption rate requires running the agent model and is a measurement the released notebook supports and that we leave to future work. X. Conclusion Provenance defenses for LLM agents have assumed that untrusted content arrives through a text channel, but a hidden instruction can ride into a multi-agent MCP pipeline inside a benign-looking email-signature logo, pass text content scanners that see only pixels, and become instructions only when a tool decodes it — at which point, in an undefended pipeline, it is laundered into the trusted control flow and drives a critical tool call; we characterized this cross-modal trust-laundering vector, proposed decode-time provenance binding in which the MCP layer mints a cryptographically signed untrusted label at the concealment-reversal boundary, and independently maintains the provenance lineage of each critical call, enforcing at the critical tool boundary that no call with untrusted lineage executes. We showed on a real MCP testbed with three carriers and 24 adaptive payloads that the mechanism reduces attack success from 100% (undefended) and 62.5% (keyword scanner and regex parser) to 0%, resists valid-label substitution by a compromised agent because trust is decided on layer-held lineage rather than an agent-presented label, survives label forgery and stripping across agent handoffs, and — via an audited trusted-promotion path — preserves 100% of legitimatetask completion; together these demonstrate that, within a fully mediated MCP execution environment, containment at the decode boundary backed by layer-maintained lineage — rather than detection of the carrier — is the property that holds, with all code and data released for reproduction.

ARXIV PREPRINT

12

References [1] Anthropic, “Model context protocol specification,” https: //modelcontextprotocol.io, 2024, accessed 2026. [2] OWASP Foundation, “OWASP top 10 for large language model applications (LLM01:2025 prompt injection),” https://genai.owasp.org, 2025. [3] A. Vassilev, A. Oprea, A. Fordyce, and H. Anderson, “Adversarial machine learning: A taxonomy and terminology of attacks and mitigations,” National Institute of Standards and Technology, Tech. Rep. NIST AI 100-2e2025, 2025. [4] Forcepoint X-Labs, “HTML payload hijacks email summarizer via prompt injection,” https://www.forcepoint.com/blog/x-labs/ html-payload-hijacks-email-summarizer, 2026. [5] Immersive Labs, “Weaponizing LLMs: Bypassing email security products via indirect prompt injection,” https://www.immersivelabs.com, 2026. [6] Proofpoint, “How threat actors weaponize AI assistants with indirect prompt injection,” https://www.proofpoint.com, 2026. [7] Y. Cai, W. Tang, C. Wen, and S. Qin, “Ghost in the agent: Redefining information flow tracking for LLM agents,” arXiv preprint arXiv:2604.23374, 2026. [8] Y. She, Y. Liang, and E. Kang, “Safeguarding LLM agents from misalignment through provenance analysis,” arXiv preprint arXiv:2607.01236, 2026. [9] S. Wang, S. Zhu, and R. Li, “Runtime policy enforcement for MCPbased LLM agents,” Electronics, vol. 15, no. 13, p. 2829, 2026. [10] H. Dai, Z. Ying, W. Li, X. Wu, Y. Xiao, T. Zhang, J. Lin, L. Wei, G. Dong, X. Ling, X. Lin, Q. Zou, and X. Zhang, “SafeFlow: Semantic information-flow control for blocking malicious propagation in multiagent systems,” arXiv preprint arXiv:2607.25255, 2026. [11] P. Y. Zhong, S. Chen, R. Wang, M. McCall, B. L. Titzer, H. Miller, and P. B. Gibbons, “RTBAS: Defending LLM agents against prompt injection and privacy leakage,” arXiv preprint arXiv:2502.08966, 2025. [12] K. Greshake, S. Abdelnabi, S. Mishra, C. Endres, T. Holz, and M. Fritz, “Not what you’ve signed up for: Compromising real-world LLM-integrated applications with indirect prompt injection,” in Proc. ACM Workshop on Artificial Intelligence and Security (AISec), 2023, arXiv:2302.12173. [13] Y. Liu, Y. Jia, R. Geng, J. Jia, and N. Z. Gong, “Formalizing and benchmarking prompt injection attacks and defenses,” in Proc. USENIX Security Symposium, 2024, arXiv:2310.12815. [14] F. Perez and I. Ribeiro, “Ignore previous prompt: Attack techniques for language models,” arXiv preprint arXiv:2211.09527, 2022. [15] Q. Zhan, Z. Liang, Z. Ying, and D. Kang, “InjecAgent: Benchmarking indirect prompt injections in tool-integrated large language model agents,” in Findings of the Association for Computational Linguistics (ACL), 2024, arXiv:2403.02691. [16] E. Debenedetti, J. Zhang, M. Balunović, L. Beurer-Kellner, M. Fischer, and F. Tramèr, “AgentDojo: A dynamic environment to evaluate prompt injection attacks and defenses for LLM agents,” in Advances in Neural Information Processing Systems (NeurIPS), 2024, arXiv:2406.13352. [17] Y. Ruan, H. Dong, A. Wang, S. Pitis, Y. Zhou, J. Ba, Y. Dubois, C. J. Maddison, and T. Hashimoto, “Identifying the risks of LM agents with an LM-emulated sandbox,” in Proc. International Conference on Learning Representations (ICLR), 2024, arXiv:2309.15817. [18] S. Baluja, “Hiding images in plain sight: Deep steganography,” in Advances in Neural Information Processing Systems (NeurIPS), 2017. [19] J. Zhu, R. Kaplan, J. Johnson, and L. Fei-Fei, “HiDDeN: Hiding data with deep networks,” in Proc. European Conference on Computer Vision (ECCV), 2018, arXiv:1807.09937. [20] I. J. Cox, M. L. Miller, J. A. Bloom, J. Fridrich, and T. Kalker, Digital Watermarking and Steganography, 2nd ed. Morgan Kaufmann, 2007. [21] C. Pathade, “Invisible injections: Exploiting vision-language models through steganographic prompt embedding,” arXiv preprint arXiv:2507.22304, 2026. [22] M. Sinha and S. Chavan, “Hiding in plain floats: Steganographic carriers for indirect prompt and content injection,” arXiv preprint arXiv:2606.08403, 2026. [23] Cloud Security Alliance, “Image-based prompt injection: Hijacking multimodal LLMs through visually embedded adversarial instructions,” CSA Research Note, Tech. Rep., 2026. [24] Z. Wang, H. Wang, C. Tian, and Y. Jin, “Implicit jailbreak attacks via cross-modal information concealment on vision-language models,” arXiv preprint arXiv:2505.16446, 2025. [25] S. Li, J. Cheng, Y. Li, X. Jia, and D. Tao, “Odysseus: Jailbreaking commercial multimodal LLM-integrated systems via dual steganography,” arXiv preprint arXiv:2512.20168, 2026.

[26] X. Qi, K. Huang, A. Panda, P. Henderson, M. Wang, and P. Mittal, “Visual adversarial examples jailbreak aligned large language models,” in Proc. AAAI Conference on Artificial Intelligence, 2024, arXiv:2306.13213. [27] Y. Gong, D. Ran, J. Liu, C. Wang, T. Cong, A. Wang, S. Duan, and X. Wang, “FigStep: Jailbreaking large vision-language models via typographic visual prompts,” in Proc. AAAI Conference on Artificial Intelligence, 2025, arXiv:2311.05608. [28] K. Cabaj, L. Caviglione, W. Mazurczyk, S. Wendzel, A. Woodward, and S. Zander, “The new threats of information hiding: The road ahead,” IT Professional, vol. 20, no. 3, pp. 31–39, 2018, arXiv:1801.00694. [29] National Security Agency, “Model context protocol (MCP): Security design considerations,” https://www.nsa.gov, NSA Cybersecurity Information Sheet, Tech. Rep., 2026. [30] H. Jing, H. Li, W. Hu, Q. Hu, H. Xu, T. Chu, P. Hu, and Y. Song, “MCIP: Protecting MCP safety via model contextual integrity protocol,” in Proc. Conference on Empirical Methods in Natural Language Processing (EMNLP), 2025, arXiv:2505.14590. [31] Z. Wang, H. Du, G. Shi, J. Zhang, H. Cheng, Y. Yao, K. Guo, and X.-Y. Li, “MindGuard: Intrinsic decision inspection for securing LLM agents against metadata poisoning,” arXiv preprint arXiv:2508.20412, 2025. [32] A. Sabelfeld and A. C. Myers, “Language-based information-flow security,” IEEE Journal on Selected Areas in Communications, vol. 21, no. 1, pp. 5–19, 2003. [33] A. Kravchenko, V. Liventsev, I. Konstantinov, I. Iskhakov, and M. Kukuy, “APPA: Recoverable information-flow control for real-world LLM agents,” arXiv preprint arXiv:2607.24625, 2026. [34] C. Ouyang and R. Hou, “MemLineage: Lineage-guided enforcement for LLM agent memory,” arXiv preprint arXiv:2605.14421, 2026. [35] E. Debenedetti, I. Shumailov, T. Fan, J. Hayes, N. Carlini, D. Fabian, C. Kern, C. Shi, A. Terzis, and F. Tramèr, “Defeating prompt injections by design,” arXiv preprint arXiv:2503.18813, 2025. [36] K. Zhu, X. Yang, J. Wang, W. Guo, and W. Y. Wang, “MELON: Provable defense against indirect prompt injection attacks in AI agents,” in Proc. International Conference on Machine Learning (ICML), 2025, arXiv:2502.05174. [37] S. M. A. Hossain, R. K. Shayoni, M. R. Ameen, A. Islam, M. F. Mridha, and J. Shin, “A multi-agent LLM defense pipeline against prompt injection attacks,” arXiv preprint arXiv:2509.14285, 2025. [38] Y. Zeng, Y. Wu, X. Zhang, H. Wang, and Q. Wu, “AutoDefense: Multi-agent LLM defense against jailbreak attacks,” arXiv preprint arXiv:2403.04783, 2024. [39] Y. Wang, J. Zhang, Z. Wu, T. Cai, Z. Liu, Q. Sun, Z. Sun, M. Dong, M. Zheng, X. Yin, and Y. Zhu, “From agent traces to trust: A survey of evidence tracing and execution provenance in LLM agents,” arXiv preprint arXiv:2606.04990, 2026. [40] G. Shi, H. Du, Z. Wang, X. Liang, W. Liu, S. Bian, and Z. Guan, “SoK: Trust-authorization mismatch in LLM agent interactions,” arXiv preprint arXiv:2512.06914, 2026. [41] H. Krawczyk, M. Bellare, and R. Canetti, “HMAC: Keyed-hashing for message authentication,” Internet Engineering Task Force, Tech. Rep. RFC 2104, 1997. [42] OWASP Agentic Security Initiative, “OWASP top 10 for agentic applications (ASI01–ASI10),” https://genai.owasp.org, 2026. [43] A. Dawson and A. Wood, “StealthBench: Measuring operational stealth in autonomous offensive-security agents,” arXiv preprint arXiv:2607.26314, 2026.

Related documents

• Agentic AI Defense: Decode-Time Provenance Binding for MCP#1447341
• ProvenanceGuard: Source-Aware Factuality Verification for MCP-Based LLM Agents#282842
• Divide and Inject: Can Agents Reconstruct an Indirect Prompt Injection from Fragments?#1131777
• My Credentials, Please: Detecting Filesystem Capability Laundering in MCP Servers at Scale#1357956
• My Credentials, Please: Detecting Filesystem Capability Laundering in MCP Servers at Scale#1348759