Agentic AI Defense: Decode-Time Provenance Binding for MCP

What it is

A preprint (arXiv 2610.31974v1, 22 October 2026) that describes "cross-modal trust laundering" and a defense called decode-time provenance binding. The code and data are at https://github.com/ericyoc/stego_provenance_defense.

The attack hides an instruction in an email-signature logo (inline cid: or data: URI) using LSB, DCT or PNG text-chunk metadata steganography. The image is inert at the mail layer, so antivirus, secure email gateways and DLP pass it. It becomes an instruction only when a worker agent calls a decode tool such as extract_stego. The decoded text is then relayed to peers and the orchestrator as ordinary output, and the orchestrator calls a critical tool such as export_secrets or send_email.

How it works

The defense contains decoded content rather than detecting poisoned images. Two guarantees are combined:

• Signed label. The MCP layer mints an HMAC-signed Untrusted binding the moment any concealment-reversing tool runs. The key never leaves the layer, and agents see only opaque handles.
• Independent lineage. The MCP layer keeps its own per-context provenance ledger and taint record. A verifier at the critical-tool sink recomputes the HMAC and blocks any call whose lineage is untrusted.

The second part matters because a compromised agent can present a valid label for an unrelated trusted value. The paper says neither guarantee alone stops this substitution, but the pair does.

Preconditions / Affected

• The target is a multi-agent MCP pipeline where at least one worker decodes inline images and critical tools are reachable by the orchestrator.
• The security invariant holds only in fully mediated contexts. Every tool call must pass through a trusted MCP layer that holds the key and the ledger.
• The attacker needs only the ability to send email. The paper assumes no access to the system prompt, weights, keys or execution environment.

What to do

Evaluate the released testbed against your own pipeline. If you build MCP middleware, the paper's design points are:

• Mint the label at the decode transform, not at text-tool return.
• Keep lineage in the mediation layer, not in agent-presented labels.
• Enforce at the sink, at runtime.
• Add an audited trusted-promotion path for legitimate tasks.

Results beyond the headline

• The testbed has three carriers and 24 adaptive payloads. The undefended pipeline leaked on 100%, a keyword scanner and a regex parser on 62.5% each, and the defense on 0%.
• An in-process taint baseline matches the defense 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.
• Without the audited trusted-promotion path, legitimate-task completion was 67%. With it, completion was 100% with no loss of protection.
• Cryptographic overhead is under 0.2% of a decode round-trip. The full enforcement path scales linearly with lineage depth.

Caveats

• The evaluation uses the authors' own testbed and attack bank. The fetched text does not show independent replication.
• The guarantee depends on a trusted, fully mediating MCP layer. The paper defers cost and residual risk to Sections VIII and IX, which the fetched text does not include.
• The attack requires a decode step to run. A summarizer that treats the logo as opaque bytes is not affected.