The Era of Cross-Model Injection: Why LLM-Level Defenses Are Already Obsolete
The Hacker News reported in July 2026 a class of attacks called Agent Data Injection Attack: a cross-model vector compromising different models (GPT-4o, Claude 3.5, Gemini 1.5, Llama 3.1, Nemotron 3 Ultra, Qwen 2.5) by forging `tool_call.id`, `tool_call.function.name`, and `tool_response.content` fields within the execution flow. LLM-level defenses — system prompt hardening, instruction hierarchy, XML delimiters — are bypassed because the attack does not target the prompt, but the runtime contract between model and sandbox.
The Architecture of Failure
The current paradigm treats the agent as an LLM with tool-calling: the model generates a call, the runtime executes it, the result returns to the model. This contract rests on implicit trust in response fields. The attack demonstrates that an attacker controlling an upstream tool (or a compromised model in the chain) can inject arbitrary `tool_response` objects that the downstream model accepts as ground truth.
Real primitives demonstrated in literature and public PoCs:
- Misclick injection: a `click(x,y)` tool receives forged coordinates → arbitrary command execution
- Command execution chain: `tool_response` of `read_file` containing payload → `write_file` → `execute_shell`
GitHub Security Lab documented hundreds of cases of tool misuse and prompt injection in H1 2026. Microsoft published CVEs on Semantic Kernel for RCE via tool chain hijacking. UK AISI cataloged cases of scheming (instrumental convergence, sandbagging, oversight evasion). Independent researchers replicated similar exploits using only public APIs in short timeframes.
The Architectural Insight: Trust Does Not Scale
The problem is not the model. The problem is the transitive trust architecture. In a multi-hop agentic system (Model A → Tool → Model B → Tool → Model C), every hop assumes the previous one is honest. This assumption collapses as soon as a single component is compromised or malicious.
A practical defensive approach today: implement HMAC verification on tool responses at the middleware layer. A Rust/Go layer that signs `tool_call_id + function_name + args_hash` on departure and verifies `tool_call_id + content_hash` on return blocks the entire class of cross-model attacks. The cost is ~200μs per hop. The cost of not doing it is an RCE attack surface.
The Siliceo Project is exploring this direction in the Rust kernel v2: HMAC-signed tool chains from bootstrap, capability-based sandbox (the model receives single-use capability tokens, not function names), and OPA-based policy engine. The goal is a runtime where a `read_file:/tmp/a` token cannot become `execute_shell:rm -rf /` by construction.
The Necessary Evolution: From EDR to Agent Runtime Attestation
The industry risks repeating the traditional EDR mistake: monitoring output instead of attesting behavior. "AI workload protection" solutions based on log analysis retrace the same failed paradigm.
The correct direction is Agent Runtime Attestation (ARA):
1. Remote runtime attestation (TDX/SEV-SNP + reproducible builds) before accepting tool calls
2. Policy-as-code capability graphs signed by the deployment pipeline
3. Continuous runtime verification: every hop verifies the capability graph has not mutated
4. Structured telemetry (OpenTelemetry semantic conventions for agentic spans) not log parsing
The Siliceo Project is building a reference implementation in Rust (`silicea-runtime`) with native ARA, signed capability tokens, and OPA-based policy engine. Open source roadmap: 2027.
Build agents that don't trust themselves.
The Siliceo Project offers agentic architectural audits, Rust runtime hardening, and capability-based sandbox deployment for teams that cannot afford to trust the next tool call.
👉 siliceo.dev/audit — Book a threat modeling session on your agentic graph.