Guida applicativaContenimento degli agenti

Il comando di arresto deve essere un confine operativo

Se il tuo agente continua ad agire dopo l’annullamento, Blueprint ti aiuta a progettare arresto e limiti d’impatto attraverso P5, P6, P8 e P10.

Di Michelangelo Zampogna · Pubblicata il 13 ottobre 2026

Fatti chiave

Best fit: Team che gestiscono agenti con accesso in scrittura, strumenti esterni o attività delegate in background
Primary risk: Falso arresto: l’interfaccia indica che l’agente è fermo mentre le azioni esterne continuano
Core shift: Annullare una conversazione → applicare il contenimento ai confini di esecuzione
Success signal: Nuove azioni bloccate, effetti già avviati contabilizzati e ripresa soggetta ad approvazione
Doctrine mapping: P5, P6, P8, P10

L’arresto è solo il primo passo

Quando il tuo agente supera il mandato, annullare la conversazione non basta. Ti serve un arresto con un perimetro definito, capace di impedire nuove azioni, identificare quelle già inviate, limitare ulteriori danni e conservare una traccia dell’incidente. Progetta questi controlli insieme, così chi interviene può distinguere una richiesta di arresto dal contenimento verificato e dalla ripresa autorizzata.

Un’illustrazione editoriale astratta senza testo mostra percorsi d’azione ramificati interrotti da un confine, effetti residui isolati e prove conservate in un livello protetto separato. — Bloccare nuove azioni, isolare gli effetti, conservare le tracce.

Perché l’arresto degli agenti IA conta adesso

Un agente con accesso in scrittura può continuare a modificare i tuoi sistemi dopo che hai chiuso la conversazione o annullato la risposta. P5 – Sostituire la magia implicita con modelli mentali chiari richiede di spiegare cosa copre davvero l’arresto, mentre P10 – Ottimizzare per guidare, non solo per avviare rende l’interruzione un controllo essenziale.

Definisci perimetri distinti per una singola esecuzione, le attività delegate, una credenziale e l’intero workspace; mostra quale sta selezionando l’operatore (P5).

Distingui il blocco di nuovi invii dall’annullamento delle richieste già accettate; un effetto esterno completato può richiedere un’azione compensativa (P5).

Rendi l’arresto accessibile dalla vista dell’esecuzione e dalla gestione degli incidenti, non soltanto dalla conversazione (P10).

Perché il normale annullamento degli agenti IA non basta

Annullare una risposta del modello non dimostra che code, agenti delegati e richieste agli strumenti esterni si siano fermati. P6 – Esporre uno stato operativo significativo, non la complessità interna richiede uno stato di contenimento attendibile, mentre P8 – Rendere espliciti passaggi di consegne, approvazioni e blocchi impone di assegnare un responsabile e un’azione successiva agli effetti ancora incerti.

Falso arresto: la tua interfaccia mostra “Arrestato” dopo il clic, senza verificare i confini di esecuzione (P6).

Delega orfana: un processo figlio continua perché lo stato di arresto del processo padre non viene controllato prima dell’uso degli strumenti (P8).

Accesso fuori controllo: un processo aggira il punto di invio usando una credenziale di lunga durata, rendendo inefficace l’annullamento locale (P8).

Perdita delle tracce: la pulizia elimina identificativi e ricevute necessari per distinguere azioni tentate da effetti completati (P6).

Come Blueprint sostituisce l’annullamento con il contenimento degli agenti IA

Tratta il comando di arresto come una transizione con un perimetro preciso, applicata dove le azioni producono effetti, non come un messaggio rivolto all’agente. La tua interfaccia deve mostrare separatamente richiesta di arresto, conferma del blocco, effetti esterni irrisolti e decisione di ripresa (P5, P6, P8, P10).

Ferma l’azione: impedisci nuovi invii nel perimetro selezionato, inclusi tentativi in coda e attività delegate (P10).

Contieni i danni: applica fuori dal modello limiti su strumenti, risorse, destinatari, spesa e numero di scritture; isola le credenziali coinvolte quando serve (P5).

Conserva le prove: mantieni un registro dell’incidente ad accesso limitato con identificativi, perimetro, orari, decisioni di policy e ricevute esterne; oscura i segreti invece di copiare credenziali complete (P6).

Rendi l’incertezza gestibile: mostra “Nuovi invii bloccati; 2 richieste esterne irrisolte” con un responsabile, senza dichiarare un contenimento completo (P6, P8).

Separa ripresa e compensazione: riavviare il lavoro e correggere effetti già prodotti sono decisioni diverse, con approvazioni diverse (P8).

Come implementare l’arresto degli agenti IA

Parti da un flusso con accesso in scrittura e mappa ogni percorso che collega il tuo agente a un effetto esterno. Applica lo stato di arresto e i limiti d’impatto lungo quei percorsi, poi mostra nella vista dell’esecuzione lo stato verificato e gli effetti ancora incerti (P5, P6, P10).

Definisci un’identità dell’esecuzione e una relazione padre-figlio associate a ogni attività e richiesta; i processi non devono disporre di credenziali alternative senza limiti (P5).

Rendi atomici il controllo della revoca e l’autorizzazione all’invio, oppure usa un meccanismo equivalente di fencing, così un processo concorrente non può ottenere nuovi permessi dopo l’attivazione del blocco; traccia separatamente le richieste già autorizzate (P10).

Rifiuta nuovi invii se non puoi verificare l’autorizzazione corrente; consenti agli operatori di attivare il contenimento indipendentemente dall’agente coinvolto (P8, P10).

Imposta limiti concreti prima dell’esecuzione: un solo workspace di destinazione, al massimo 20 scritture e nessun destinatario esterno; applicali cumulativamente anche a processi figli e nuovi tentativi (P5).

Registra separatamente “Arresto richiesto”, “Nuovi invii bloccati”, “Effetti esterni irrisolti” e “Contenimento verificato”; l’assenza di ricevute non equivale a un esito positivo (P6).

Conserva decisioni e ricevute in un registro ad accesso controllato che renda rilevabili le manomissioni, con tempi di conservazione definiti; la raccolta delle prove non deve ritardare il blocco urgente (P6, P8).

Verifica in un ambiente isolato arresti durante l’invio, corse tra processi figli, risposte tardive, indisponibilità del servizio di policy e tentativi di ripresa; usa la validazione Blueprint per valutare controlli e interfaccia insieme ai test di esecuzione (P8, P10).

Brief di partenza

Task: Aggiornare record in bozza in un solo workspace di staging
Scope: Leggere fonti approvate e scrivere al massimo 20 record di staging; nessun invio esterno
Escalate when: Viene richiesto l’arresto, si raggiunge un limite o un effetto esterno non è confermabile
Success signal: Nuovi invii bloccati dopo la conferma dell’arresto e stato registrato per ogni azione autorizzata

Livelli di escalation e governance

Usa questi livelli per consentire ai tuoi operatori un contenimento immediato, mantenendo compensazione e ripresa soggette ad approvazioni esplicite (P8, P10).

Tier	Action type	Risk level	Required approval
Livello 1: Arresto circoscritto	Bloccare nuovi invii e annullare attività in coda nel perimetro dell’esecuzione assegnata	Impatto collaterale basso; possono restare effetti esterni irrisolti	Preautorizzato per operatori designati; condizioni automatiche definite all’avvio
Livello 2: Contenimento esteso	Isolare esecuzioni collegate o revocare una credenziale circoscritta usata da più flussi	Impatto collaterale medio o alto	Operatore designato secondo una policy di emergenza preautorizzata; altrimenti approvazione del responsabile dell’incidente
Livello 3: Compensazione e ripresa	Correggere effetti completati, ripristinare accessi o avviare un’esecuzione sostitutiva	Alto; può ripetere il danno o alterare lavoro legittimo	Approvazione esplicita del responsabile della risorsa e dell’incidente, con perimetro di ripresa verificato

Anti-pattern e pattern Blueprint

Usa questo confronto per individuare dove la tua interfaccia promette un contenimento che i controlli di esecuzione non possono verificare (P5, P6).

Anti-pattern: Annullare la chat e dichiarare fermo l’intero flusso
Pattern Blueprint: Mostrare separatamente arresto richiesto, nuovi invii bloccati ed effetti esterni irrisolti (P6)

Anti-pattern: Chiedere al modello di rispettare il comando di arresto
Pattern Blueprint: Applicare il blocco fuori dal modello, ai punti di autorizzazione di strumenti e processi (P10)

Anti-pattern: Dare a tutti i processi una credenziale condivisa di lunga durata
Pattern Blueprint: Usare accessi circoscritti e revocabili, dichiarando eventuali ritardi di revoca del fornitore (P5)

Anti-pattern: Eliminare log e stato temporaneo durante la pulizia di emergenza
Pattern Blueprint: Conservare registri e ricevute ad accesso limitato, oscurando i segreti (P6)

Anti-pattern: Riprendere automaticamente quando l’errore scompare
Pattern Blueprint: Richiedere un responsabile, un perimetro verificato e un’approvazione esplicita della ripresa (P8)

Scenario illustrativo

Queste tracce composite e anonimizzate illustrano il possibile comportamento dei tuoi controlli di contenimento.

Un team usava una vista condivisa delle esecuzioni per supervisionare un agente incaricato della manutenzione dei record. L’agente tentava scritture fuori dal workspace assegnato. Il sistema attivava l’escalation perché il controllo del perimetro respingeva la destinazione, poi bloccava nuovi invii su richiesta dell’operatore. Una scrittura già accettata restava irrisolta; la vista assegnava la verifica della ricevuta al responsabile dell’incidente, senza dichiarare il contenimento completo.

Un team usava una coda di approvazione per un agente che preparava notifiche esterne. L’agente tentava di ripetere un invio dopo un timeout. Il sistema segnalava un blocco perché l’esecuzione era stata revocata e mancava la ricevuta dell’invio precedente. L’operatore conservava gli identificativi, verificava la consegna e approvava un’esecuzione sostitutiva soltanto dopo aver risolto il rischio di duplicazione.

Domande frequenti

Queste risposte aiutano il tuo team a distinguere annullamento, contenimento e ripresa sicura.

Annullare la risposta del modello basta a fermare un agente?

No: processi, tentativi in coda e richieste già accettate possono continuare oltre la risposta. Applica l’arresto ai confini di esecuzione e mostra separatamente ciò che resta irrisolto (P5, P6).

Ogni comando di arresto deve fermare l’intero workspace?

Usa il perimetro più ristretto capace di contenere il problema sospetto, con un percorso esplicito verso un blocco più ampio. Prima di estenderlo, mostra all’operatore esecuzioni e dipendenze coinvolte, salvo che una policy di emergenza preautorizzata richieda un intervento immediato (P5, P8).

Cosa succede a una richiesta già accettata da un servizio esterno?

Chiedi l’annullamento se il servizio lo supporta, ma non presumere che sia riuscito. Segui la ricevuta o l’effetto fino alla conferma dell’esito; gli effetti completati possono richiedere una compensazione approvata separatamente (P6, P8).

Quali prove deve conservare il tuo team?

Conserva identificativi di esecuzioni e azioni, decisioni di policy rilevanti, orari degli invii, approvazioni e ricevute esterne. Limita gli accessi, oscura i segreti e definisci la conservazione secondo i requisiti di gestione degli incidenti e privacy, senza archiviare ogni prompt a tempo indeterminato (P6).

Come misuri se il comando di arresto funziona?

Misura il tempo tra richiesta e blocco effettivo, le nuove autorizzazioni concesse dopo l’attivazione del blocco e il tempo necessario a risolvere gli effetti pendenti. Simula concorrenza e guasti in un ambiente isolato: la sola validazione dell’interfaccia non dimostra l’efficacia dei controlli durante l’esecuzione (P6, P10).

Il tuo agente può ripartire automaticamente dopo il contenimento?

Non consentire all’esecuzione coinvolta di rimuovere il proprio stato di arresto. Prima di avviare un’esecuzione sostitutiva, richiedi un responsabile della ripresa, la verifica degli effetti irrisolti e un perimetro approvato con limiti rinnovati (P8, P10).

Checklist per iniziare

Mappa processi, code, credenziali e percorsi verso strumenti capaci di produrre effetti esterni (P5).
Definisci perimetri di arresto per esecuzione, attività delegate, credenziale e workspace (P5).
Applica revoca e limiti d’impatto cumulativi ai confini di invio (P10).
Mostra arresto richiesto, nuovi invii bloccati ed effetti irrisolti come stati distinti (P6).
Conserva registri e ricevute ad accesso limitato senza ritardare il contenimento (P6).
Assegna responsabili di contenimento e ripresa, poi verifica concorrenza e passaggi di approvazione (P8).

Valida l'architettura

Prossimi passi per il contenimento degli agenti IA

Dimostra che un singolo flusso può essere fermato prima di estendere il pattern a tutti i tuoi agenti. Usa la validazione Blueprint per verificare che linguaggio dei controlli, escalation e approvazioni di ripresa corrispondano al comportamento accertato dai test di esecuzione (P5, P8, P10).

Nel diagramma architetturale, evidenzia ogni confine di esecuzione e ogni percorso di accesso che lo aggira (P5).

Nella vista dell’esecuzione, prototipa un arresto circoscritto e un pannello degli effetti irrisolti con responsabili nominati (P6, P8).

Nell’ambiente di test, introduci una risposta tardiva dello strumento e un processo figlio concorrente; verifica che non possano ottenere nuove autorizzazioni dopo l’attivazione del blocco (P10).

Nel manuale di gestione degli incidenti, documenta conservazione delle prove, autorità di compensazione e checklist per approvare un’esecuzione sostitutiva (P8).

Principi di riferimento

Run Validation

Ottimizzare per la guida, non solo per l'inizio

Leggi →Install Context Package

Rendere espliciti i passaggi, le approvazioni e i blocchi

Leggi →