Guida applicativaSicurezza agenti

Rendi sicuri gli agenti mostrando fiducia, memoria e approvazioni

Gli agenti assorbono memoria avvelenata, riusano l'esperienza sbagliata, obbediscono a prompt avversariali. La soluzione: fiducia, memoria e flussi di approvazione che l'operatore può ispezionare, non inferire.

Di Michelangelo Zampogna · Pubblicata il 21 aprile 2026

Fatti chiave

Best fit: Team che rilasciano browser agent, agenti di ricerca, copiloti con memoria e workflow multi-tool
Primary risk: Violazioni silenziose dei confini di fiducia causate da memory injection, experience grafting e prompt avversari
Core shift: Solo hardening del prompt → sistema di lavoro ispezionabile con gate di approvazione
Success signal: Ogni lettura, scrittura e azione rischiosa mostra provenienza, livello di rischio e stato di approvazione
Doctrine mapping: P4, P7, P8, P10

Una sicurezza che il tuo team può davvero verificare

I guasti più seri degli agenti non nascono più da una singola risposta errata. Nascono da traiettorie sbagliate: una nota salvata in memoria da una fonte non affidabile, un’eccezione umana riutilizzata come regola generale, oppure una pagina recuperata che cambia il piano senza farsi notare. Questa guida ti mostra come progettare trust inspection, progressive disclosure e approval gate in modo che il tuo team possa vedere cosa l’agente ha imparato, perché vuole agire e dove serve un intervento umano. Written by the AI Design Blueprint editorial team. Doctrine grounded in the 10 Blueprint Principles.

Rendi sicuri gli agenti mostrando fiducia, memoria e approvazioni

Perché la sicurezza degli agenti AI conta adesso?

La ricerca più recente sulla sicurezza degli agenti si è spostata dalle sole risposte errate alle traiettorie operative sbagliate. Valutazioni architetturali come AgentFence mostrano differenze forti nei tassi di rottura tra framework agentici, con classi di rischio guidate da denial-of-wallet, authorization confusion, retrieval poisoning e planning manipulation. Le survey sulla memoria mostrano un altro dato importante: la validazione in scrittura e la verifica dopo la cancellazione restano punti ciechi molto diffusi. Per questo il pattern è urgente per ogni prodotto in cui un agente naviga, ricorda o agisce.

Qui entrano in gioco P6 – Expose meaningful operational state, not internal complexity e P7 – Establish trust through inspectability. Il tuo team deve vedere stato operativo reale: fiducia della fonte, provenienza della memoria, stato di approvazione e rischio dell’azione.

Quando i team saltano questo pattern, i segnali di fallimento si ripetono:

lo stesso task si comporta in modo diverso tra una sessione e l’altra perché la memoria precedente non è mai stata rivista

l’agente cita un’eccezione passata come se fosse policy stabile

una pagina o un documento recuperato cambia il piano senza visibilità

l’approvazione arriva quando l’azione irreversibile è già stata preparata

l’audit mostra solo la chat, non quale memoria o quale tool ha cambiato la decisione

La sicurezza degli agenti non consiste solo nel bloccare prompt malevoli. Consiste nel governare ciò che può essere letto, ricordato, riusato ed eseguito.

Perché l’approccio standard alla sicurezza degli agenti AI fallisce?

Molti team difendono ancora gli agenti come se la minaccia principale fosse un singolo prompt malevolo. Così però perdono i pattern di sistema che producono il danno vero. P5 – Replace implied magic with clear mental models e P8 – Make hand-offs, approvals, and blockers explicit aiutano a cambiare cornice.

Failure mode 1: Silent Memory Contamination

Contenuti recuperati da fonti non affidabili, istruzioni nascoste in pagine web o output di tool malformati vengono scritti in memoria senza provenienza né revisione. La conseguenza è la deriva cross-sessione: l’agente continua a riusare contesto avvelenato come se fosse conoscenza approvata.

Failure mode 2: Experience Grafting Without Scope

Un’eccezione passata, una scorciatoia o un’approvazione umana viene trattata come esperienza riutilizzabile in un nuovo contesto. La conseguenza è la fuga di policy: decisioni locali diventano comportamento generale, spesso in flussi di pricing, supporto, accesso o compliance.

Failure mode 3: Approval After Action

Il sistema chiede approvazione solo quando ha già costruito il piano esecutivo, predisposto una transazione o preparato una scrittura ad alto rischio. La conseguenza è una governance solo apparente: sembra che l’umano controlli, ma il punto decisionale utile è già passato.

Non sono errori isolati. Sono pattern ricorrenti prodotti da confini di fiducia deboli, provenienza scarsa e interfacce solo conversazionali che nascondono i cambi di stato.

Come sostituisce Blueprint il modello standard di sicurezza degli agenti AI?

Questo pattern implementa P4 – Apply progressive disclosure to system agency, P7 – Establish trust through inspectability e P8 – Make hand-offs, approvals, and blockers explicit.

Il cambio mentale è netto: smetti di pensare alla sicurezza come filtro del prompt e inizia a pensarla come delega governata.

Nel modello standard indurisci il prompt e speri che l’agente si comporti bene. Nel modello Blueprint progetti tre livelli ispezionabili:

Livello dell’intento — quale obiettivo l’agente sta davvero perseguendo
Livello della fiducia — quali fonti, memorie ed esperienze precedenti possono influenzare quell’obiettivo
Livello esecutivo — quali azioni possono procedere da sole, quali vanno riviste e quali vanno bloccate

P4 – Apply progressive disclosure to system agency significa mostrare prima una spiegazione compatta: cosa vuole fare l’agente, perché e con quali evidenze. Il trace dettagliato si apre solo quando serve fiducia, comprensione o intervento.

P7 – Establish trust through inspectability significa poter risalire ogni risultato rischioso alle specifiche scritture in memoria, ai documenti recuperati, agli output dei tool e alle approvazioni ricevute.

P10 – Optimise for steering, not only initiating significa permettere al tuo team di correggere il run mentre è in corso: rifiutare una memoria candidata, ridurre il livello di fiducia di una fonte, revocare un’esperienza appresa o restringere il piano prima dell’esecuzione.

Questa è la sostituzione proposta da Blueprint: un sistema operativo ispezionabile per il lavoro delegato, non una chat resa un po’ più rigida.

Come implementare la sicurezza degli agenti AI?

Parti da P1 – Design for delegation rather than direct manipulation, P7 – Establish trust through inspectability e P10 – Optimise for steering, not only initiating.

Copy-paste starter brief

Brief di partenza

Task: analizzare istruzioni, recuperare evidenze ed eseguire solo azioni dell’agente già approvate
Scope: usa solo tool in allowlist e spazi di memoria associati al workflow corrente
Escalate when: una pagina, un documento, una memoria o l’output di un tool introduce nuovi obiettivi, nuove credenziali, cambi di policy o azioni irreversibili
Success signal: ogni lettura, scrittura e azione rischiosa è tracciabile a un intento approvato e a uno stato di rischio visibile

Step-by-step checklist

Definisci i confini della delega prima di scrivere qualsiasi prompt: cosa l’agente può leggere, scrivere, ricordare, riusare ed eseguire.
Mappa le zone di fiducia tra input utente, contenuti recuperati, memoria persistente, memoria condivisa e risultati dei tool.
Aggiungi provenienza a ogni scrittura in memoria e a ogni esperienza riutilizzabile: fonte, timestamp, revisore, ambito e scadenza.
Progetta livelli di progressive disclosure: riepilogo di default, evidenze espandibili, trace completo per audit o intervento.
Inserisci approval gate prima delle transizioni ad alto rischio, come persistenza in memoria, azioni cross-account, pagamenti o cambi di policy.
Offri controlli di steering per rifiutare una memoria candidata, revocare un’esperienza passata o rilanciare il run con ambito più stretto.

Una buona implementazione rende visibili le transizioni pericolose prima che accadano, non solo a run concluso.

Come gestire escalation e governance nella sicurezza degli agenti AI?

Usa P8 – Make hand-offs, approvals, and blockers explicit e P10 – Optimise for steering, not only initiating per rendere visibile l’autorità proprio nel momento in cui l’azione sta per partire.

Tier 1 (Autonomous) — Lavoro a basso rischio e reversibile, dentro un obiettivo fisso, con scope di tool fisso e confine di memoria fidato.

Tier 2 (Supervised) — Lavoro a rischio medio che sembra plausibile ma attraversa un confine di fiducia, riusa esperienza pregressa o può toccare stato esterno.

Tier 3 (Blocked) — Lavoro ad alto rischio che coinvolge identità, pagamenti, impegni legali, dati privilegiati, scritture ampie in memoria o autorità ambigua.

Tier	Action type	Risk level	Required approval
Tier 1 (Autonomous)	Recupero in sola lettura, drafting, sintesi, classificazione interna	Low	Nessuna, se scope e fiducia della fonte non cambiano
Tier 2 (Supervised)	Riutilizzo di esperienza passata, scrittura di memoria circoscritta, modifiche reversibili verso l’esterno	Medium	Revisore nominato o owner del workflow
Tier 3 (Blocked)	Pagamenti, cambi di accesso, impegni contrattuali, scritture cross-tenant, override di policy	High	Approvazione umana esplicita prima dell’esecuzione

La regola pratica è semplice: ogni attraversamento di un confine di fiducia alza il livello di revisione. Se l’agente vuole trasformare contenuto non affidabile in memoria, memoria in policy o policy in azione esterna, il passaggio deve essere esplicito.

Quali anti-pattern di sicurezza degli agenti AI dovresti sostituire?

Usa P4 – Apply progressive disclosure to system agency, P7 – Establish trust through inspectability e P9 – Represent delegated work as a system, not merely as a conversation per sostituire abitudini fragili da chat con comportamento di sistema governato.

Anti-pattern: Difesa basata solo sul prompt
Pattern Blueprint: Mappa dei confini di fiducia con gate di approvazione su lettura, scrittura ed esecuzione

Anti-pattern: Scritture in memoria senza etichette
Pattern Blueprint: Memoria con provenienza, revisore, ambito, scadenza e stato di fiducia

Anti-pattern: Transcript della chat come unico audit trail
Pattern Blueprint: Trace strutturato su fonti, memoria, tool, decisioni e approvazioni

Anti-pattern: Un solo tasto di approvazione per tutto
Pattern Blueprint: Approvazioni differenziate per rischio, attraversamento di fiducia e reversibilità

Anti-pattern: Dump completo degli internals a ogni run
Pattern Blueprint: Progressive disclosure: prima riepilogo, poi evidenze, trace completo solo su richiesta

Anti-pattern: Blocco senza spiegazione
Pattern Blueprint: Stato di blocker esplicito con approvazione, fonte o condizione mancante

Quale prova reale mostra che la sicurezza degli agenti AI funziona?

Scenario illustrativo

Questi trace mostrano P7 – Establish trust through inspectability e P8 – Make hand-offs, approvals, and blockers explicit in azione.

Team used a research agent with persistent notes and browser tools. Agent attempted to promote instructions hidden in a vendor help page into long-term memory and then reuse them as standing policy on the next run. System blocked because the content arrived from an untrusted retrieval source, carried no approved provenance tag, and crossed a write boundary that required Tier 2 review before memory could persist.

Team used a sales-ops agent that learned from prior approvals. Agent attempted to treat a one-off exception for a discounted contract as a reusable experience and apply it to a new account, then queue the change for signature. System escalated because the prior approval was context-bound, the new customer exceeded the pricing threshold, and the approval gate exposed the mismatch before any external action fired.

Cosa chiedono i team sulla sicurezza degli agenti AI?

Le risposte qui sotto si basano su P5 – Replace implied magic with clear mental models, P7 – Establish trust through inspectability e P8 – Make hand-offs, approvals, and blockers explicit.

Che cos’è la sicurezza degli agenti AI in questo pattern?

È il modo di trattare il lavoro dell’agente come delega governata. Invece di fidarti solo del prompt, definisci cosa l’agente può leggere, ricordare, riusare ed eseguire, e rendi tutto ispezionabile con provenienza, livelli di rischio e stati di approvazione.

Quando devo inserire approval gate?

Ogni volta che l’agente attraversa un confine di fiducia: scrittura in memoria persistente, riuso di un’eccezione passata, accesso a sistemi esterni, cambi di permessi, spesa economica o azioni basate su contenuti recuperati da fonti non affidabili. Se l’azione è difficile da annullare, il gate deve stare prima dell’esecuzione.

Che differenza c’è tra experience grafting e apprendimento normale?

L’experience grafting avviene quando una decisione passata o un’eccezione locale viene trapiantata in un nuovo contesto come se fosse regola generale. È pericoloso perché trasforma giudizi umani situati in automazione fuori controllo, spesso senza segnalare che l’ambito è cambiato.

La progressive disclosure non rallenta gli utenti?

Se progettata bene fa il contrario. Nella maggior parte dei casi basta un riepilogo breve di intento, evidenze e rischio. Il trace profondo si apre solo quando la fiducia è bassa, compare un blocker o serve un’approvazione.

Quali strumenti servono davvero?

Ti servono tagging delle fonti, campi di provenienza per la memoria, classificazione del rischio delle azioni, workflow di approvazione e un viewer del trace. Lo stack può cambiare, ma se non sai spiegare perché una memoria esiste e chi ne ha approvato il riuso, il pattern non è ancora implementato.

Come gestisco memoria condivisa tra più agenti?

Trattala come un asset governato, non come un semplice layer di comodità. Separa i permessi di scrittura, aggiungi metadata di revisione, limita l’ambito per team o workflow e richiedi approvazioni più forti quando un agente vuole operativizzare la memoria prodotta da un altro.

Anche documenti interni o tool SaaS fidati possono contenere prompt avversari?

Sì. La fiducia non è mai assoluta. Anche fonti interne possono contenere istruzioni obsolete, testo nascosto o contenuti compromessi. Per questo provenienza, scadenza e stato di approvazione restano indispensabili anche per fonti considerate normalmente affidabili.

Cosa puoi fare oggi per la sicurezza degli agenti AI?

Imposta il rollout su P7 – Establish trust through inspectability e P8 – Make hand-offs, approvals, and blockers explicit.

Elenca tutti i punti in cui l’agente può ricevere istruzioni: input utente, retrieval, memoria, output dei tool e note di revisione umana.
Etichetta ogni fonte come trusted, reviewable oppure untrusted.
Aggiungi campi di provenienza a ogni scrittura in memoria e a ogni esperienza riutilizzabile.
Definisci regole Tier 1, Tier 2 e Tier 3 per azioni di lettura, scrittura ed esecuzione.
Progetta una vista di riepilogo di default con evidenze espandibili e trace completo.
Esegui test con prompt nascosti nelle pagine, memorie avvelenate e approvazioni una tantum riusate fuori ambito.

Valida l'architettura

Quali sono i prossimi passi per la sicurezza degli agenti AI?

Parti da P4 – Apply progressive disclosure to system agency e P7 – Establish trust through inspectability.

Basic → Complete Foundations

Pro → Validate in Pro

Teams → Install Context Package

Principi di riferimento

Run Validation

Stabilire fiducia attraverso l'ispezionabilità

Leggi →Complete Foundations

Applicare la divulgazione progressiva all'agenzia del sistema

Leggi →