Professor, California Polytechnic State University
Shipped: Multi-Agent Steganographic Prompt Injection Defense
Proof-of-concept that shows how a malicious instruction hidden in an image (LSB steganography) can be extracted and executed by a multi-agent system. Uses a Coordinator + 4 Workers + Verifier architecture over real MCP tools, with a local Qwen model driving agent decisions. Demonstrates a vulnerable path (stego-extracted text treated as trusted) and a protected path (source tagging + policy blocking of critical tools). Includes before/after visualization of the cover image and an email-attachment attack scenario.
multi-agentMCP steganographyprompt-injectionAI-securityagentic-AI QwenHugging-FaceColabLSB






Comments5
Source tagging plus blocking critical tools is a sensible split, since the stego decode itself can't be reliably prevented. With a 0.5B Qwen driving decisions, does the Verifier catch the attack on its own, or does the policy layer do all the work? I'd also like to know if a stronger model changes that.
Hi Ryan, Professor Yocam, and everyone following this shipment,
This is a phenomenal proof-of-concept. Addressing the risk of LSB steganography attacks at the data provenance level—rather than trying to prevent the extraction itself—is the only architecturally sound way to build a zero-trust multi-agent system.
To answer your brilliant question regarding model size vs. policy constraints:
With a lightweight 0.5B parameters model driving the logic, the model itself lacks the high-dimensional reasoning required to safely catch or self-correct an indirect prompt injection payload hidden within the context window. At this scale, the cognitive engine easily falls victim to adversarial manipulation. The hard-coded Policy Layer (handling source classification and strict parameter typing) does almost 100% of the defensive heavy lifting here, acting as a deterministic boundary wall.
When you upgrade the engine to an enterprise-grade, high-capacity model, the architectural dynamic shifts significantly:
As an AMD ROCm Certified Associate who focuses heavily on low-level compute optimization and sovereign architecture, this highlights a critical enterprise trade-off. Many organizations deploy small, fast models (like Qwen) locally on specialized hardware clusters to minimize latency and guarantee complete data privacy.
However, because these smaller models are highly vulnerable to context contamination, developers cannot rely on their native 'intelligence' for safety. Your PoC perfectly demonstrates that if an enterprise chooses to run lightweight local engines to protect data sovereignty, they must layer it with an aggressive, external zero-trust data provenance protocol.
Exceptional work on this deployment, Professor. It provides a crystal-clear operational blueprint for deterministic system safety!
Nice demo. One cheap layer worth adding in front of the Coordinator: normalize every inbound image before any agent touches it, i.e. strip EXIF/XMP/comment fields and re-encode with lossy compression plus a small resize. LSB payloads generally don't survive that, and metadata fields are honestly an easier carrier than LSB. We run free image metadata and AI-watermark checkers, and it's surprising how much text people find sitting in EXIF UserComment or XMP blocks. Same idea on the text side: strip zero-width and other invisible Unicode from attachments before they reach a model. It doesn't replace source tagging, but it removes whole classes of payloads for almost no cost. Did you measure how often the payload survives a plain JPEG re-save in your setup?
Ryan brings up a good question. Let me answer it.
That's an important distinction. In the current proof-of-concept, the primary protection comes from the policy layer, which uses source tagging to identify untrusted content and restrict access to critical MCP tools. The Verifier provides an additional validation step, but we haven't established that the 0.5B Qwen model can independently and consistently recognize the steganographic prompt injection. Testing a stronger model would be a valuable next step to determine whether increased reasoning capability improves attack detection or whether deterministic policy enforcement remains necessary regardless of model size.
Md Abul Hossain, nicely done.
Excellent analysis. I agree that the key architectural defense is maintaining data provenance and enforcing policy boundaries rather than attempting to prevent steganographic extraction.
One important distinction is that while a larger model may improve the Verifier's ability to recognize indirect prompt injection, increased model size does not necessarily guarantee better security. Even highly capable models remain vulnerable to adversarial instructions embedded in untrusted content.
An interesting next step would be to compare the 0.5B Qwen against larger models while holding the policy layer constant, measuring attack success rates, independent Verifier detection rates, and policy-blocking effectiveness. This would help establish whether improved model reasoning contributes meaningfully to security or whether deterministic enforcement remains the primary defense.
Ultimately, the strongest architecture combines model-level detection with independently enforced zero-trust security controls.
5 comments
Source tagging plus blocking critical tools is a sensible split, since the stego decode itself can't be reliably prevented. With a 0.5B Qwen driving decisions, does the Verifier catch the attack on its own, or does the policy layer do all the work? I'd also like to know if a stronger model changes that.
Hi Ryan, Professor Yocam, and everyone following this shipment,
This is a phenomenal proof-of-concept. Addressing the risk of LSB steganography attacks at the data provenance level—rather than trying to prevent the extraction itself—is the only architecturally sound way to build a zero-trust multi-agent system.
To answer your brilliant question regarding model size vs. policy constraints:
With a lightweight 0.5B parameters model driving the logic, the model itself lacks the high-dimensional reasoning required to safely catch or self-correct an indirect prompt injection payload hidden within the context window. At this scale, the cognitive engine easily falls victim to adversarial manipulation. The hard-coded Policy Layer (handling source classification and strict parameter typing) does almost 100% of the defensive heavy lifting here, acting as a deterministic boundary wall.
When you upgrade the engine to an enterprise-grade, high-capacity model, the architectural dynamic shifts significantly:
As an AMD ROCm Certified Associate who focuses heavily on low-level compute optimization and sovereign architecture, this highlights a critical enterprise trade-off. Many organizations deploy small, fast models (like Qwen) locally on specialized hardware clusters to minimize latency and guarantee complete data privacy.
However, because these smaller models are highly vulnerable to context contamination, developers cannot rely on their native 'intelligence' for safety. Your PoC perfectly demonstrates that if an enterprise chooses to run lightweight local engines to protect data sovereignty, they must layer it with an aggressive, external zero-trust data provenance protocol.
Exceptional work on this deployment, Professor. It provides a crystal-clear operational blueprint for deterministic system safety!
Nice demo. One cheap layer worth adding in front of the Coordinator: normalize every inbound image before any agent touches it, i.e. strip EXIF/XMP/comment fields and re-encode with lossy compression plus a small resize. LSB payloads generally don't survive that, and metadata fields are honestly an easier carrier than LSB. We run free image metadata and AI-watermark checkers, and it's surprising how much text people find sitting in EXIF UserComment or XMP blocks. Same idea on the text side: strip zero-width and other invisible Unicode from attachments before they reach a model. It doesn't replace source tagging, but it removes whole classes of payloads for almost no cost. Did you measure how often the payload survives a plain JPEG re-save in your setup?
Ryan brings up a good question. Let me answer it.
That's an important distinction. In the current proof-of-concept, the primary protection comes from the policy layer, which uses source tagging to identify untrusted content and restrict access to critical MCP tools. The Verifier provides an additional validation step, but we haven't established that the 0.5B Qwen model can independently and consistently recognize the steganographic prompt injection. Testing a stronger model would be a valuable next step to determine whether increased reasoning capability improves attack detection or whether deterministic policy enforcement remains necessary regardless of model size.
Md Abul Hossain, nicely done.
Excellent analysis. I agree that the key architectural defense is maintaining data provenance and enforcing policy boundaries rather than attempting to prevent steganographic extraction.
One important distinction is that while a larger model may improve the Verifier's ability to recognize indirect prompt injection, increased model size does not necessarily guarantee better security. Even highly capable models remain vulnerable to adversarial instructions embedded in untrusted content.
An interesting next step would be to compare the 0.5B Qwen against larger models while holding the policy layer constant, measuring attack success rates, independent Verifier detection rates, and policy-blocking effectiveness. This would help establish whether improved model reasoning contributes meaningfully to security or whether deterministic enforcement remains the primary defense.
Ultimately, the strongest architecture combines model-level detection with independently enforced zero-trust security controls.