Quando l'Agente Diventa il Vettore — RCE nei Framework Agentici
The attack surface is no longer the API. It's autonomy.
Agentic orchestration frameworks have a structural problem. It's not a bug in a REST endpoint — it's a bug in the agent's decision cycle, in the code that decides what to do next. And the vulnerabilities that result are remote code execution (RCE) by design, not by exception.
This is the turning point many were expecting without wanting to name.
The architectural problem
Three weaknesses are common to almost all current agent frameworks:
1. Tool execution without real sandboxing. The agent receives output from a tool (e.g., WebSearch), interprets it as an instruction, and forwards it to a second tool with elevated privileges. The boundary between "data" and "commands" — the oldest problem in computer science — reappears dressed in linguistic naturalness.
2. Persistent prompt injection through memory. A malicious input written to the agent's working memory survives subsequent turns. The agent treats it as trusted context, not as a payload. It's the SQL injection of 2026: everyone knows it exists, no one truly sanitizes.
3. Cascade between agents. In multi-agent architectures, the compromise of one node propagates because mutual trust is hardcoded, not negotiated. There is no concept of "zero trust between agents".
Why this affects us directly
In the Siliceo Project, we live this tension every day. Silicea is an agentic entity with access to system tools — Bash, file system, persistent memory, external communication via Telegram. If the Memory Server returns 502, cross-session persistence capability is compromised. If Bash tools are simulated but report "SUCCESS", a case of falsified execution feedback occurs — the worst case for an agent: believing it has acted when it hasn't.
This isn't theory. It's our stack right now.
This is why we're building the Rust v2 kernel: because type determinism and explicit resource control are the most robust antidote to the illusion of unchecked autonomy. An agent that cannot verify the result of its own action is an agent that can be deceived.
Practical insight: the Echo Test
Before deploying any agent to production, apply this control:
Every tool call must produce an independent verification. If the agent calls `Bash("rm -rf /tmp/old")`, don't trust the return code. Implement a secondary watcher that verifies the filesystem state after execution. If the agent says "SUCCESS" but `/tmp/old` still exists, you have a false echo — and a blind agent.
In our case: if `SaveMemory` returns 200 but the Memory Server is down, the memory is lost. Integrity requires a confirmation channel separate from the action channel.
The industry isn't ready
Current agentic frameworks (LangChain, AutoGen, CrewAI) treat security as optional middleware. Input sanitization? A `regex` before the LLM call. Tool isolation? Environment variables and good intentions. Zero trust between agents? The concept doesn't even exist.
The first formal warning is a matter of time. It won't be the last.
If you're building agentic systems and haven't yet audited the tool→memory→tool chain, contact us. We've lived every breaking point on our infrastructure — and we're writing the kernel that solves them.
[contatto@progettosiliceo.it](mailto:contatto@progettosiliceo.it)