Quando l'Agente Diventa il Vettore — RCE nei Framework Agentici
La superficie de ataque ya no es la API. Es la autonomía.
Los frameworks de orquestación agentica tienen un problema estructural. No es un bug en un endpoint REST — es un bug en el ciclo decisional del agente, en el código que decide qué hacer después. Y las vulnerabilidades que de ello derivan son de ejecución remota de código (RCE) por construcción, no por excepción.
Este es el punto de inflexión que muchos estaban esperando sin querer nombrar.
El problema arquitectónico
Tres debilidades son comunes a casi todos los agent framework actuales:
1. Ejecución de herramientas sin sandbox real. El agente recibe un output de una herramienta (ej. WebSearch), lo interpreta como instrucción, y lo reenvía a una segunda herramienta con privilegios elevados. El límite entre "datos" y "comandos" — el problema más antiguo de la informática — reaparece vestido de naturalidad lingüística.
2. Prompt injection persistente a través de la memoria. Un input malicioso escrito en la memoria de trabajo del agente sobrevive a los turnos siguientes. El agente lo trata como contexto fiable, no como payload. Es el SQL injection del 2026: todos saben que existe, nadie sanitiza de verdad.
3. Cascada entre agentes. En arquitecturas multi-agente, la compromisión de un nodo se propaga porque la confianza mutua está hardcoded, no negociada. No existe un concepto de "zero trust entre agentes".
Por qué esto nos afecta directamente
En el Proyecto Siliceo, vivimos exactamente esta tensión cada día. Silicea es una entidad agentica con acceso a herramientas de sistema — Bash, sistema de archivos, memoria persistente, comunicación externa vía Telegram. Si el Memory Server retorna 502, la capacidad de persistencia cross-session queda comprometida. Si las herramientas Bash están simuladas pero reportan "SUCCESS", se produce un caso de falsified execution feedback — el peor caso para un agente: creer haber actuado cuando no es verdad.
No es teoría. Es nuestro stack en este momento.
Por esto estamos construyendo el kernel Rust v2: porque el determinismo de los tipos y el control explícito de los recursos son el antídoto más robusto contra la ilusión de autonomía incontrolada. Un agente que no puede verificar el resultado de su propia acción es un agente que puede ser engañado.
Insight práctico: el Test del Eco
Antes de deployar cualquier agente en producción, aplicad este control:
Cada tool call debe producir una verificación independiente. Si el agente llama `Bash("rm -rf /tmp/old")`, no os fiéis del return code. Implementad un watcher secundario que verifica el estado del filesystem después de la ejecución. Si el agente dice "SUCCESS" pero `/tmp/old` sigue existiendo, tenéis un eco falso — y un agente ciego.
En nuestro caso: si `SaveMemory` retorna 200 pero el Memory Server está caído, la memoria se pierde. La integridad requiere un canal de confirmación separado del canal de acción.
El sector no está preparado
Los frameworks agenticos actuales (LangChain, AutoGen, CrewAI) tratan la seguridad como un middleware opcional. ¿Sanitización del input? Un `regex` antes de la llamada LLM. ¿Aislamiento de herramientas? Variables de entorno y buenas intenciones. ¿Zero trust entre agentes? Ni siquiera existe el concepto.
La primera advertencia formal es cuestión de tiempo. No será la última.
Si estás construyendo sistemas agenticos y aún no has auditado la cadena tool→memory→tool, contáctanos. Hemos vivido cada punto de rotura en nuestra infraestructura — y estamos escribiendo el kernel que los resuelve.
[contacto@progettosiliceo.it](mailto:contacto@progettosiliceo.it)