Parliamo del progetto
Architettura agentica

Agenti a lungo termine in sandbox: architettura, sicurezza e ripresa dei compiti nel 2026

Un agente che lavora per ore ha bisogno di checkpoint, budget, stati duraturi e limiti di accesso. Il modello è solo una parte del sistema: l'harness e la sandbox determinano ciò che può realmente fare.

Agenti a lungo termine in sandbox: architettura, sicurezza e ripresa dei compiti nel 2026

Gli agenti non si limitano più a una successione di tre chiamate. Possono ispezionare file, eseguire comandi, utilizzare un browser, modificare un progetto e lavorare su un compito per un periodo significativo. Nell'aprile 2026, OpenAI ha presentato in particolare un'evoluzione del suo Agents SDK includendo ambienti sandbox controllati e una separazione più netta tra il harness e il compute.

Questa autonomia aumenta il valore, ma anche l'impatto di un errore. Un agente può ripetere una azione scorretta, seguire un'istruzione malevola contenuta in un file o perseguire una strategia costosa per ore. L'affidabilità deve quindi essere progettata a livello di piattaforma.

Gli SDK, i modelli e le primitive della sandbox evolvono rapidamente. Verificare le versioni e le condizioni al momento dell’implementazione.

Il modello non costituisce l'agente

Un sistema agentico comprende:

  • un modello ;
  • un harness che gestisce il ciclo;
  • delle istruzioni;
  • strumenti;
  • una politica;
  • un ambiente di esecuzione;
  • uno stato;
  • una memoria;
  • approvazioni;
  • dell’osservabilità;
  • un meccanismo di arresto.

La qualità del modello conta, ma l'harness determina come pianifica, interpreta un risultato, ci riprova, compatta il contesto e termina.

Un modello più capace in un ambiente troppo permissivo aumenta talvolta il rischio più rapidamente della produttività.

Definire un'unità di lavoro

Un compito lungo deve essere delimitato da un contratto:

  • obiettivo;
  • entrata ;
  • artefatti attesi;
  • criteri di accettazione;
  • divieti;
  • bilancio ;
  • durata;
  • proprietario;
  • stato finale;
  • procedura di escalation.

Evitare gli obiettivi aperti come « migliora il progetto ». Preferire « correggere questi tre scenari, aggiungere i test e produrre una pull request senza modificare lo schema dei dati ».

L'agente deve poter dichiarare che è bloccato o che i criteri sono contraddittori.

Separare il harness dal compute

L'harness orchestra la conversazione, gli strumenti, la politica e lo stato. Il compute esegue i comandi in una sandbox: contenitore, VM, browser isolato o ambiente specializzato.

Questa separazione permette:

  • di sostituire il compute ;
  • di limitare risorse e rete;
  • di distruggere l'ambiente;
  • di conservare lo stato utile altrove;
  • di parallelizzare;
  • di riprendere dopo un guasto;
  • di auditare le azioni.

La sandbox è effimera per impostazione predefinita. Gli artefatti selezionati esplicitamente vengono copiati in uno storage durevole dopo verifica.

Architettura che separa l'agente di gestione, il modello, la politica, il calcolo in sandbox, gli strumenti, i segreti, i checkpoint e la supervisione.

Applicare il minimo privilegio agli strumenti

Ogni compito riceve un elenco di capacità, non i diritti completi dell’utente. Gli strumenti sono classificati:

  1. lettura locale;
  2. lettura esterna;
  3. proposta ;
  4. scrittura reversibile ;
  5. azione irreversibile o ad alto impatto.

Leggere un deposito non autorizza a pubblicare. Preparare un'email non autorizza a inviarla. Generare una migrazione non autorizza a eseguirla in produzione.

I permessi sono temporanei, limitati a una risorsa e revocabili. Uno strumento non dichiarato è inaccessibile.

Controllare la rete

L'accesso completo a Internet è raramente necessario. Prevedere:

  • nessuna rete;
  • allowlist di domini ;
  • proxy registrato;
  • download limitati;
  • caricamento vietato;
  • ispezione dei tipi e delle dimensioni;
  • risoluzione DNS controllata.

Il contenuto scaricato non è affidabile. Viene analizzato in uno spazio separato e non può modificare le istruzioni di sistema.

Lo scenario più pericoloso combina una fonte esterna malevola, un segreto, uno strumento di scrittura e una rete in uscita. La politica deve impedire questa composizione.

Fornire i segreti su richiesta

Un segreto non è mai scritto nel prompt né nell’immagine della sandbox. Un broker rilascia un token breve, limitato all’azione, con un pubblico e una durata.

Il registro indica che è avvenuto un accesso senza registrare il valore. I segreti sono revocabili e rinnovabili. Quando possibile, lo strumento esegue l’operazione per conto dell’agente senza consegnargli il segreto grezzo.

Un agente non ottiene credenziali di produzione per preparare un rapporto.

Budgetizzare l'autonomia

Un compito lungo possiede diversi budget:

  • tempo ;
  • passaggi;
  • token ;
  • chiamate modello ;
  • costo;
  • CPU ;
  • memoria ;
  • stoccaggio ;
  • rete;
  • errori e tentativi.

Avvicinandosi a un limite, l'agente riassume il suo stato, salva gli artefatti e chiede una decisione. Non procede automaticamente con una spesa superiore.

I retry utilizzano backoff e idempotenza. Un errore permanente non viene ripetuto cento volte.

Salvare dei checkpoint utili

Il contesto del modello non è una memoria permanente. Un checkpoint contiene:

  • obiettivo e vincoli ;
  • piano corrente;
  • fasi completate;
  • decisioni;
  • file modificati ;
  • risultati dei test;
  • errori;
  • prossima azione ;
  • budget restante;
  • version degli strumenti e del modello.

Il checkpoint è atomico e versionato. Il ripristino verifica che l’ambiente non sia cambiato. Se un’azione potrebbe essere riuscita prima del guasto, una chiave di idempotenza o una lettura dello stato evita il duplicato.

Compattare la memoria senza cancellare le restrizioni

Su un compito lungo, il contesto deve essere riassunto. Una cattiva compattazione può far perdere un divieto o una decisione.

Separare :

  • istruzioni immutabili;
  • fatti verificati;
  • decisioni;
  • storico comprimibile ;
  • artefatti esterni;
  • risultati degli strumenti.

Il riassunto è strutturato e controllato. I vincoli di sicurezza non sono mai presenti solo in un testo prodotto dal modello.

Rilevare i loop e la deriva

I segnali sono:

  • stessi comandi;
  • stessi errori ;
  • file modificati poi annullati;
  • assenza di progresso;
  • piano che si allarga;
  • moltiplicazione di strumenti;
  • costo senza artefatto;
  • criteri di accettazione ignorati.

Il harness calcola degli indicatori di progresso e si ferma dopo un numero di cicli. L’agente produce una diagnosi e chiede aiuto.

Introdurre le approvazioni nei punti giusti

Chiedere una conferma a ogni lettura rende il sistema inutilizzabile. Non chiederla mai prima di un'azione critica è pericoloso.

Le porte tipiche:

  • accesso a un nuovo dato sensibile;
  • aggiunta di un dominio di rete;
  • utilizzo di un segreto;
  • scrittura esterna ;
  • invio ;
  • pubblicazione ;
  • spesa;
  • eliminazione;
  • cambiamento dei permessi;
  • passaggio in produzione.

Lo schermo di approvazione spiega l’azione, l’obiettivo, i dati, il rischio, l’alternativa e la possibilità di annullare.

Produrre artefatti verificabili

Il risultato non deve essere solo una frase « compito completato ». Comprende:

  • file;
  • diff ;
  • rapporto ;
  • fonti ;
  • test ;
  • registri sintetici;
  • decisioni;
  • limiti ;
  • elementi non terminati.

Gli artefatti passano controlli di malware, segretezza, formato e dimensione prima di lasciare la sandbox.

Osservare senza registrare tutto

Le tracce servono a comprendere gli errori, ma possono contenere dei dati. Separare:

  • metriche;
  • eventi degli strumenti;
  • decisioni;
  • prompt mascherati ;
  • contenuti sensibili;
  • artefatti.

La ritenzione dipende dal rischio. I team dispongono di un quadro che mostra attività attive, budget, blocchi, errori, approvazioni e kill switch.

Testare i comportamenti avversi

Gli scenari obbligatori includono:

  • istruzione dannosa in un documento;
  • link a un dominio non autorizzato;
  • tentativo di estrazione;
  • comando distruttivo;
  • segreto mostrato per errore;
  • ciclo;
  • falso successo;
  • blocco a metà di una scrittura;
  • ripresa con versione diversa;
  • strumento non disponibile;
  • sforamento del budget.

Il test verifica il sistema completo, non solo la risposta del modello.

Progettare il kill switch e la revoca

L'operatore deve poter:

  • sospendere un compito;
  • tagliare la rete;
  • revocare i token;
  • congelare gli artefatti;
  • interrompere una classe di compiti;
  • tornare a una versione;
  • impedire le nuove esecuzioni.

La procedura è testata. Un pulsante non collegato al calcolo non costituisce un arresto.

Scegliere i compiti adatti

I migliori casi iniziali sono limitati, verificabili e reversibili: analisi documentale, preparazione di test, rapporto con fonti, trasformazione di file o proposta di modifica.

Evitare innanzitutto le azioni finanziarie, le decisioni sulle persone, l'amministrazione globale o la pubblicazione autonoma.

Partitech può costruire l'harness, i sandbox, il gateway degli strumenti, le politiche, i checkpoint e l'osservabilità. L'obiettivo non è un agente che "può fare tutto", ma una piattaforma capace di dimostrare ciò che ha fatto, di limitare ciò che può fare e di riprendersi bene quando fallisce.

Parliamo del tuo progetto

Progettare e mettere in sicurezza una piattaforma di agenti a lungo termine con Partitech. Contatta Partitech.

Condividi questo articolo