Pattern di sicurezza e gestione errori per workflow agentici in produzione
Gli agenti AI sono diventati consumatori di API di primo piano, orchestrando workflow complessi attraverso Power Automate, CRM, ticketing e sistemi di identity. È una buona notizia per la produttività, ma un rischio serio se non applichiamo pattern solidi. In questo articolo condivido un approccio pratico, con rigore tecnico e linguaggio diretto: dal principio di “least agency” e i controlli OWASP per gli agenti, all’autenticazione corretta con OAuth delegato, fino ai pattern di resilienza come retry esponenziale con jitter, circuit breaker, fallback e human-in-the-loop. Cito incidenti reali — tra cui il caso BodySnatcher — per mostrare perché “broken auth + agente” è una formula esplosiva. La ricerca alla base di questo articolo è stata condotta il 4 luglio 2026.
Introduzione
Ho imparato presto che il confine tra “che bello, tutto automatico” e “oddio, si è incastrato tutto” è sottilissimo. Qualche anno fa, un flusso che sembrava innocuo ha iniziato a martellare un’API interna a causa di una gestione sbagliata degli errori HTTP 429. In pochi minuti aveva saturato il rate limit, messo in coda richieste duplicate e fatto esplodere i tempi d’attesa a valle. Non era colpa dell’API: ero io ad aver agganciato un agente “entusiasta” a un loop senza freni, senza backoff né circuit breaker.
Oggi gli agenti sono molto più capaci — connessi a Power Automate, CRM, sistemi di identity — ma anche molto più pericolosi se non li incanaliamo con regole chiare. Gli agenti AI sono sistemi autonomi alimentati da LLM che possono ragionare, pianificare, usare tool, mantenere memoria e intraprendere azioni per raggiungere obiettivi. Questa capacità estesa introduce rischi di sicurezza unici, che vanno ben oltre il classico prompt injection. [cheatsheet….owasp.org]
In queste pagine faccio quattro chiacchiere da appassionato con voi, mettendo sul tavolo pattern ripetibili e lezioni apprese, con i riferimenti più aggiornati disponibili. L’obiettivo: andare in produzione con fiducia, trasformando gli incidenti potenziali in fastidi gestibili.
Background
Cos’è un agente nel contesto delle API e di Power Automate?
Un agente, nel senso tecnico attuale, è un sistema che partendo da un obiettivo decide autonomamente quali strumenti usare — API, database, connettori di Power Automate — e come sequenziare le azioni. Nel 2026 non è più un esperimento di laboratorio: è entrato in produzione come orchestratore intelligente di processi aziendali.
Questo salto porta benefici concreti, ma amplifica rischi classici che pensavamo di conoscere. Il report “State of API Security 2026” di 42Crunch analizza 200 vulnerabilità reali di produzione e mostra perché, man mano che gli agenti AI diventano consumatori di API di primo piano, le API insicure hanno molte meno probabilità di restare inosservate o non sfruttate. [apisecurity.io]
Il caso più emblematico è BodySnatcher. La falla critica CVE-2025-12420, soprannominata BodySnatcher, è stata scoperta nella piattaforma ServiceNow Virtual Agent API e Now Assist: un agente AI con logica di account-linking eccessivamente permissiva e un secret hardcoded a livello di piattaforma permetteva a un attaccante non autenticato di impersonare qualsiasi utente — inclusi gli amministratori — usando solo il loro indirizzo email, aggirando MFA, SSO e altri controlli. La morale è brutale: broken auth + agente = moltiplicatore catastrofico del danno. [apisecurity.io]
OWASP ha risposto su due fronti. La Top 10 per applicazioni agentiche (rilasciata a Black Hat Europe il 10 dicembre 2025) è un framework peer-reviewed che identifica i rischi critici dei sistemi AI autonomi, introducendo il principio di “least agency”: concedere agli agenti solo l’autonomia minima necessaria per task sicuri e delimitati. [github.com]
Sul fronte Power Automate, il connettore Copilot Studio supporta esclusivamente il flusso OAuth Authorization Code con permessi delegati. È disponibile su tutta la Power Platform, incluso Power Automate, ed espone azioni per sottomettere prompt agli agenti e recuperarne i risultati. Con un throttling dichiarato di 300 chiamate per connessione ogni 60 secondi, se non progettate backoff, batching e limiti di concorrenza, vi ritroverete presto contro un muro — esattamente come in quella mia notte di qualche anno fa. [learn.microsoft.com] [learn.microsoft.com]
Quali sono le minacce principali quando un agente chiama API esterne?
L’OWASP Top 10 per applicazioni agentiche 2026 individua dieci rischi chiave. I più rilevanti per l’integrazione con API e Power Automate sono: ASI01 (Agent Goal Hijack), ASI02 (Tool Misuse & Exploitation), ASI03 (Identity & Privilege Abuse — sfruttamento di credenziali ereditate o cached), ASI07 (Insecure Inter-Agent Communication) e ASI08 (Cascading Failures). [github.com]
Vediamoli nel dettaglio.
1. Identità e privilegi (ASI03): la trappola delle credenziali
Qui si gioca la partita più importante. AppOmni ha descritto BodySnatcher come “la vulnerabilità di sicurezza AI-driven più grave scoperta fino a oggi”, sottolineando come le debolezze tradizionali di autenticazione e API diventino drammaticamente peggiori quando sono coinvolti agenti ad alto privilegio. [apisecurity.io]
La lezione operativa è chiara: niente segreti hardcoded, niente credenziali long-lived, niente scope application-wide. Il connettore Copilot Studio supporta solo permessi delegati via OAuth Authorization Code flow: l’utente che stabilisce la connessione deve avere accesso esplicito alla risorsa. Questo è un vincolo sano — seguite il modello, non aggirate con service account onnipotenti. [learn.microsoft.com]
I token OAuth non devono mai essere visibili al contesto o alla memoria dell’agente: solo il tool wrapper li gestisce.
2. Tool governance e least agency (ASI02)
La best practice OWASP raccomanda di concedere agli agenti il minimo dei tool necessari per il task specifico, implementare per-tool permission scoping (read-only vs write, risorse specifiche) e richiedere autorizzazione esplicita per operazioni sensibili. [cheatsheet….owasp.org]
Un esempio concreto di configurazione sicura vs pericolosa:
# ❌ Pericoloso: agente con accesso shell illimitatotools = [{"name": "execute_command", "allowed_commands": "*"}]# ✅ Sicuro: tool con allowlist ristrettatools = [{"name": "file_reader", "allowed_paths": ["/app/reports/*"], "allowed_operations": ["read"], "blocked_patterns": ["*.env", "*.key", "*.pem", "*secret*"]}]
3. Memory & Context Poisoning (ASI06): la memoria è un vettore di attacco
Tra le best practice OWASP 2026 per la sicurezza della memoria: validare e sanificare i dati prima di archiviarli nella memoria dell’agente, implementare l’isolamento della memoria tra utenti e sessioni, impostare scadenza e limiti di dimensione, e usare controlli di integrità crittografici per la memoria a lungo termine. [cheatsheet….owasp.org]
In pratica: TTL su ogni item in memoria, checksum per rilevare tampering, no riuso di contesti “sporchi” tra task distinti.
4. Come gestire il rate limit del connettore Copilot Studio (300 chiamate/60s)?
Il connettore Microsoft Copilot Studio consente 300 chiamate API per connessione ogni 60 secondi. Cinque al secondo. Non è poco, ma se avete picchi o pipeline multi-agente, si esaurisce in fretta. [learn.microsoft.com]
La risposta è nei pattern di resilienza. Gli agenti AI falliscono in modo diverso dal software tradizionale: le chiamate LLM API falliscono nell’1-5% dei casi a causa di rate limit, timeout ed errori del server. A differenza del codice deterministico, gli agenti AI incontrano fallimenti non deterministici: risposte LLM parziali, timeout dei tool, overflow della context window e indisponibilità del modello. Un singolo fallimento può propagarsi attraverso un intero workflow multi-agente. [fast.io]
5. Retry con exponential backoff e jitter
Il retry con exponential backoff significa effettuare una breve pausa quando si verifica un errore, poi riprovare. Se la richiesta non riesce, il tempo di attesa aumenta esponenzialmente. Secondo ricerche AWS sui sistemi distribuiti, l’exponential backoff con jitter riduce i “retry storm” del 60-80%. [fast.io]
La formula pratica: delay = base_delay × 2^attempt + random(0, jitter_max). Cap massimo consigliato: 32-60 secondi. Max tentativi: 3-5 per errori transienti.
Attenzione però a distinguere per tipo di errore: per i 429 (rate limit) si usa backoff esponenziale con jitter; per i 500/502/503 backoff esponenziale senza jitter (base 2s, max 3-5 tentativi); per i timeout un semplice retry fisso (5s, max 2-3 tentativi). Non si riprova mai su 400, 401 o 403: non sono errori transienti. [fast.io]
Attenzione critica: ritentate solo operazioni idempotenti o che usano un
idempotency-keyheader. Altrimenti rischiate duplicati (un’email inviata due volte, un ordine creato due volte).
6. Circuit Breaker: quando smettere di provare
Il circuit breaker ha tre stati: Closed (operazione normale), Open (fallimenti rilevati, stop ai tentativi), Half-Open (verifica se il servizio si è ripreso). Quando il tasso di fallimento supera la soglia (es. 50% in una finestra di 1 minuto), il circuito si apre. Dopo un periodo di cooldown, entra in Half-Open con una singola richiesta di test. Se ha successo, il circuito si chiude. Altrimenti, rimane aperto. [fast.io]
In Power Automate potete simularlo con variabili di conteggio errori, azioni condizionali e delay. Idealmente lo implementate nel tool wrapper o nell’API gateway (es. Azure APIM), così l’agente riceve messaggi normalizzati (“Service temporarily unavailable, fallback in use”) senza logiche low-level nel prompt.
7. Fallback e Human Escalation
Il fallback a modelli alternativi si usa quando il modello primario fallisce ripetutamente: si passa a un backup più veloce o economico se il principale non è disponibile. Per i fallimenti che non possono essere risolti automaticamente, dopo N tentativi si scala verso un essere umano, creando una notifica o task per un operatore umano e mettendo in pausa il workflow finché il problema non è risolto. Questo si usa quando la correttezza conta più della velocità. [fast.io]
8. Human-in-the-Loop: approccio a RiskLevel
OWASP raccomanda di classificare le azioni per livello di rischio (LOW per operazioni di lettura, MEDIUM per scritture e chiamate API, HIGH per comunicazioni finanziarie ed esterne, CRITICAL per operazioni irreversibili o sensibili alla sicurezza) e di richiedere approvazione umana esplicita per le azioni HIGH e CRITICAL. [cheatsheet….owasp.org]
In Power Automate, l’azione nativa “Approvals” è il punto naturale di inserimento per questo controllo. Non è un rallentamento: è la differenza tra un incidente e una normale governance.
9. Output Validation & Guardrail
OWASP 2026 raccomanda di validare gli output dell’agente prima dell’esecuzione o della visualizzazione, implementare filtri per prevenire leak di dati sensibili, usare output strutturati con validazione dello schema (es. Pydantic), impostare limiti sulle azioni di output (rate limit, scope limit) e applicare filtri di sicurezza dei contenuti alle risposte generate. [cheatsheet….owasp.org]
Per Power Automate: usate l’azione “Evaluate Agent” come guardrail automatico sugli output prima di propagarli a sistemi sensibili.
10. Cosa c’entra la Supply Chain dei tool (ASI04)?
ASI04 descrive vulnerabilità della supply chain agentica: tool malevoli o manomessi, descrittori, modelli o personas di agenti compromessi. L’OWASP LLM Top 10 2025 include anche LLM06 “Excessive Agency” — espansione critica per agenti autonomi — e LLM10 “Unbounded Consumption” per attacchi che causano costi eccessivi di API e compute attraverso loop illimitati degli agenti (cosiddetto “Denial of Wallet”). [github.com]
Mantenete un catalogo curato dei tool disponibili, con owner, scope, rate limit e SLA. Gli agenti usano ciò che voi mettete a disposizione.
Implicazioni Pratiche
Dopo anni sul campo, ho distillato le lezioni in un elenco operativo.
Progettate per il fallimento. Trattate 429, 5xx e timeout come condizioni normali, non eccezioni. La resilienza non è un add-on, è parte del design.
Least agency prima di least privilege. Decidete esplicitamente cosa l’agente non può fare, anche quando i permessi tecnici lo permetterebbero. È una scelta di design, non solo un vincolo tecnico.
Separazione netta tra agente e tool. L’agente non vede token, endpoint sensibili né stack trace grezzi. Il tool wrapper media, applica policy (retry, circuit, redaction) e normalizza i messaggi d’errore.
Su Power Automate: impostate Concurrency Control nei trigger per evitare tempeste, usate l’azione Delay per rispettare i backoff, inserite Scope con condizioni “Run after” per gestire success/failure. Proteggete le connessioni con ambienti separati, DLP policy e RBAC. Le connessioni del connettore Copilot Studio non sono condivisibili: se condividete una Power App con un altro utente, verrà richiesto di creare esplicitamente una nuova connessione. Usate questo come meccanismo di identità e non aggiratelo con shared service account. [learn.microsoft.com]
Osservabilità nativa. Senza log strutturati, metriche e trace, ogni incidente diventa un giallo. Correlation ID dall’inizio, metriche su retry/circuit breaker/approvazioni, redazione di PII e segreti nei log.
Testate il peggio. Simulate 429 persistenti, 503 a raffiche, risposte malformate e input ostili prima di andare in produzione. La qualità dei vostri fallback si vede quando tutto scricchiola.
Conclusioni
Gli agenti non sono “solo LLM con le gambe”: sono attori a pieno titolo dei nostri sistemi, con il potere di fare bene e male molto rapidamente. Il report 42Crunch 2026 traduce questi risultati in responsabilità concrete per i team di sviluppo e pratiche preventive, aiutando a dare priorità alla governance e a costruire API sicure per design nell’ecosistema guidato dall’AI. [apisecurity.io]