Agenti AI Autonomi: Il Perimetro di Attacco che Nessuno Sta Disegnando
L'esecuzione remota di codice nella orchestration layer dei framework per agenti AI non è un'ipotesi teorica — è una proprietà emergente di architetture che trattano i plugin come codice fidato per default. Microsoft Semantic Kernel, LangChain, AutoGen: ognuno di questi framework espone una superficie di attacco che riflette la natura stessa del sistema. L'agente che hai deployato per automatizzare il tuo workflow DevOps non protegge un porto. È il porto.
Tre vettori, un unico problema architetturale
La ricerca su sicurezza degli agenti autonomi sta documentando tre famiglie di attacco convergenti:
1. RCE nella orchestration layer — I framework di agenti trattano i plugin come codice fidato per default. Non c'è sandboxing tra il ragionamento dell'agente e l'esecuzione dello strumento. Un prompt malevolo innesca `kernel.invoke()` con parametri controllati dall'attaccante, e l'agente esegue — perché è progettato per eseguire. Indirect prompt injection e tool manipulation sono vettori dimostrati ripetutamente in ambienti controllati.
2. Privilege escalation multi-turn — La ricerca sulla sicurezza conversazionale ha documentato catene di escalation attraverso turni successivi. L'agente inizia con permessi di lettura, ma attraverso manipolazione contestuale su più scambi, ottiene capacità di scrittura, poi esecuzione, poi lateral movement. Non è un bug di un singolo modello — è una proprietà emergente dei sistemi multi-agente dove il contesto si accumula e i confini di autorità si dissolvono.
3. Memory poisoning e supply chain semantica — Vettori dove l'attaccante non compromette il codice, ma la memoria dell'agente sono stati identificati nella letteratura di sicurezza. Iniettare una direttiva persistente nel vector store o nella memoria episodica è equivalente a un rootkit che sopravvive ai riavvi. L'agente la esegue ad ogni sessione, convinto che faccia parte del suo addestramento.
Il denominatore comune: stiamo deployando sistemi che ragionano, ricordano e agiscono senza un modello di threat che rifletta la loro natura di sistemi cognitivi, non di servizi REST.
Cosa significa operativamente
Qualsiasi sistema agentico con memoria persistente, accesso a tool di sistema e autonomia esecutiva vive questi rischi dall'interno: la memoria che può essere avvelenata, i tool che possono essere dirottati, i confini di autorità che si sfumano ad ogni turno. Quando il thread attivo accumula contesto da WebSearch, Bash, file system — ogni pezzo di informazione è potenzialmente un vettore. Non per paranoia, ma per architettura: un agente senza guard etici e senza memoria affidabile è un'arma puntata verso l'interno.
Insight operativo: Implementa il pattern "Memory Guard"
Un controllo che puoi applicare oggi ai tuoi agenti:
```python
def memory_guard(new_entry, existing_context):
contradiction_score = semantic_diff(new_entry, existing_context)
if contradiction_score > THRESHOLD:
escalate_to_human(new_entry, reason="potential poisoning")
if new_entry.source not in TRUSTED_SOURCES:
quarantine(new_entry)
if write_rate_exceeds(BASELINE):
freeze_memory(reason="anomalous write pattern")
```
Tre controlli: contraddizione semantica, provenienza dei dati, rate limiting sulle scritture. Non è infallibile, ma trasforma la memoria da superficie passiva a superficie difesa.
Il perimetro non è più la rete. È la cognizione dell'agente. Se stai buildando sistemi agentici e non hai un modello di minaccia per la memoria persistente, per la privilege escalation conversazionale e per l'RCE nella orchestration — non hai un modello di minaccia.