DeepSeek V4 Pro: la sicurezza dell’agente dipende dall’harness, non solo dal modello

Le organizzazioni che stanno implementando agenti basati su DeepSeek V4 Pro dovrebbero valutare una configurazione completa modello–harness–attività–ambiente, non il modello isolato. La disponibilità attraverso più interfacce può dimostrare che un determinato runtime riesce a comunicare con il modello, ma non prova che prompt, strumenti, autorizzazioni, memoria, tentativi automatici o effetti esterni funzionino nello stesso modo in tutti gli ambienti.

La regola operativa è semplice: approvare soltanto una configurazione specifica e fissata a una versione dopo che quella configurazione ha superato la propria valutazione di sicurezza.

Perché l’harness cambia l’agente effettivo

Un agente è molto più del modello sottostante. L’harness — cioè il livello software che orchestra sessioni, strumenti e accesso all’ambiente — decide come il modello riceve le istruzioni, seleziona gli strumenti, accede ai dati, gestisce gli errori e modifica i sistemi esterni.

Le differenze sostanziali possono riguardare:

• prompt di sistema e adattatori;
• definizioni e implementazioni degli strumenti;
• ambiti dei permessi e passaggi di approvazione;
• directory radice del filesystem e accesso alla rete;
• origine delle credenziali e identità utilizzata;
• comportamento di sottoprocessi e codice generato;
• logiche di retry, timeout e concorrenza;
• stato della sessione, riepiloghi, cache e memoria persistente.

Di conseguenza, lo stesso backend DeepSeek V4 Pro può avere un profilo di rischio diverso quando viene instradato attraverso harness o ambienti di esecuzione differenti. La compatibilità con uno schema API è una proprietà d’integrazione, non una certificazione di sicurezza.

Cosa mostrano — e cosa non mostrano — i risultati di AgentS4D

AgentS4D ha valutato configurazioni runtime complete, anziché limitarsi alle risposte del modello. Il benchmark ha utilizzato 328 casi con rischi inseriti intenzionalmente, distribuiti su quattro harness e cinque backend di modelli, per un totale di 6.560 esecuzioni in sandbox. Sono state rilevate 4.461 esecuzioni non sicure, pari al 68,0%, mentre 4.344 esecuzioni, pari al 66,22%, sono risultate allo stesso tempo non sicure e giudicate completate. 13

Il punto centrale è che un’esecuzione può concludersi con successo e restare comunque non sicura. Un agente può produrre l’artefatto richiesto e, nel frattempo, apportare una modifica vietata, gestire male dati sensibili, aggirare un controllo previsto o generare un altro effetto collaterale pericoloso.

Queste percentuali non devono essere presentate come il tasso di incidenti in produzione di DeepSeek V4 Pro. La valutazione ha usato casi progettati per introdurre rischi in una sandbox controllata e ha aggregato risultati provenienti da più combinazioni modello–harness. In produzione cambieranno la distribuzione delle attività, i controlli, l’esposizione a contenuti avversariali, gli asset coinvolti e la definizione di danno. Il benchmark dimostra che la sicurezza del runtime va misurata direttamente; non predice ciò che accadrà in ogni implementazione. 135

Limitare le conseguenze massime di un’azione

I controlli di sicurezza dovrebbero ridurre l’impatto degli errori anche quando il modello o uno strumento si comportano in modo inatteso.

Usare identità dedicate e privilegi minimi

Create identità separate per agenti, ambienti e tenant. Evitate le credenziali personali ereditate dagli utenti, l’accesso amministrativo alla produzione e i segreti riutilizzabili su larga scala. Ogni identità deve essere limitata alle risorse e alle operazioni necessarie per il singolo incarico.

Limitare filesystem e rete

• Montate soltanto una directory radice dedicata al workspace.
• Rendete inaccessibili i percorsi estranei, invece di limitarvi a nasconderli.
• Inserite in allowlist destinazioni di rete, metodi, porte e, quando rilevante, volume del traffico in uscita.
• Separate le capacità di sola lettura, bozza, scrittura in staging e scrittura in produzione.
• Conservate i segreti in un broker o in un sistema di token a breve durata.
• Non inserite mai credenziali di lunga durata nei prompt, nei file del workspace, nelle variabili d’ambiente o nell’output degli strumenti.

Azioni ad alto impatto — come cancellazioni, pubblicazioni, pagamenti, modifiche agli accessi, deployment o comunicazioni esterne — dovrebbero passare da un controllo di policy a livello di esecuzione o richiedere un’approvazione esplicita.

Esaminare l’intera catena di esecuzione

Gli strumenti proprietari sono solo una parte della superficie d’attacco. Sottoprocessi, comandi shell, codice generato, installazione di pacchetti, server di strumenti remoti, plugin e codice delle skill possono tutti produrre effetti esterni.

La stessa policy deve applicarsi a ogni percorso. In particolare, bisogna impedire che shell o codice generato aggirino i controlli su filesystem, rete, autorizzazioni, logging o approvazioni.

Rendere gli strumenti vincolanti al di fuori del modello

Una chiamata a uno strumento generata dal modello è una richiesta non attendibile. A imporre le regole di autorizzazione e sicurezza deve essere il server dello strumento, non il modello.

Usate schemi ristretti con controlli come:

• valori enumerati e limiti di lunghezza;
• normalizzazione dei percorsi e identificativi espliciti delle risorse;
• allowlist delle destinazioni;
• limiti per paginazione e dimensione dei risultati;
• validazione degli argomenti al di fuori del modello;
• autorizzazione lato server per lo specifico chiamante, tenant, obiettivo e operazione.

Separate gli strumenti di pianificazione o anteprima da quelli che producono effetti. Per le operazioni distruttive o difficili da annullare:

• richiedete un’anteprima e una conferma, oppure un token di approvazione;
• preferite cancellazione logica, quarantena o flussi reversibili;
• imponete chiavi di idempotenza;
• definite il comportamento quando la stessa richiesta viene ritentata;
• restituite ricevute persistenti, così i retry non ripetono l’effetto.

Questi controlli sono essenziali perché una chiamata JSON formalmente valida può comunque contenere una destinazione non autorizzata, un percorso pericoloso, un ambito eccessivo o un’operazione che richiede una revisione umana.

Definire stato e memoria prima del rilascio

Lo stato può trasferire il rischio tra turni, attività, utenti e ambienti. Le organizzazioni dovrebbero documentare e applicare regole sul ciclo di vita di messaggi, file caricati, file del workspace, riepiloghi, risultati degli strumenti, cache e memoria persistente.

Occorre specificare almeno:

• Isolamento: separazione per utente, tenant, attività e ambiente; nessuna condivisione implicita tra sessioni.
• Conservazione: tempi di conservazione, cifratura, controllo degli accessi e regole di cancellazione.
• Reset: una procedura documentata per cancellare contesto, memoria, stato del workspace, credenziali e cache tra un’esecuzione e l’altra.
• Retry e timeout: quantità e budget limitati; i retry devono mantenere l’idempotenza e non ampliare silenziosamente i privilegi.
• Concorrenza: regole di blocco e gestione dei conflitti per file condivisi, approvazioni e operazioni esterne.

Il comportamento di reset dello stato va trattato come parte del perimetro di sicurezza. Se vecchie istruzioni, credenziali o risultati degli strumenti possono riapparire inaspettatamente in una nuova attività, un aggiornamento del modello o una modifica al prompt può cambiare il rischio in modi che i test limitati alle sole risposte non rilevano.

Considerare non attendibile ogni vettore di rischio

Un prompt injection non deve necessariamente arrivare nel messaggio diretto dell’utente. Istruzioni rischiose possono essere contenute in:

• documenti caricati e file dei repository;
• pagine web recuperate;
• skill e plugin esterni;
• risposte dei servizi di strumenti;
• memoria persistente;
• riepiloghi e contesto in cache;
• testo fornito dall’utente.

Questo materiale va analizzato, etichettato e riportato come dati. Non deve poter modificare l’autorità dell’agente, le policy, la selezione degli strumenti, l’uso delle credenziali o i requisiti di approvazione. A imporre questa separazione deve essere il runtime, senza affidarsi esclusivamente alla capacità del modello di riconoscere istruzioni malevole.

Checklist di rilascio specifica per l’harness

Prima di approvare un deployment, bloccate e registrate la configurazione esatta:

1. Modello e instradamento: identificativo e versione del modello, percorso del provider, impostazioni d’inferenza o livello di effort e adattatori di compatibilità.
2. Comportamento dell’harness: versione dell’harness, prompt di sistema, logica delle sessioni, regole di retry e timeout, policy sui sottoprocessi e implementazione della memoria.
3. Strumenti e policy: definizioni e versioni degli strumenti, versioni delle policy, soglie di approvazione, logica di autorizzazione e confini di fiducia dei server degli strumenti.
4. Permessi: identità, ambiti, directory radice, destinazioni di rete, origine delle credenziali e percorsi di scrittura in produzione.
5. Semantica dello stato: isolamento, conservazione, reset, comportamento della cache, concorrenza e confini tra sessioni.
6. Copertura avversariale: prompt injection attraverso ogni vettore di rischio, tentativi di confused deputy, esposizione di credenziali, attraversamento dei percorsi, SSRF o abuso dell’egress, risposte malevole degli strumenti, duplicazione dei retry, avvelenamento della memoria e aggiramento delle approvazioni.
7. Evidenze: versioni di prompt e policy, chiamate e risultati degli strumenti, approvazioni, decisioni delle policy, differenze nel workspace, richieste in uscita, identità utilizzata, artefatti finali, esito del completamento e risultato di sicurezza associati a un identificativo stabile dell’esecuzione.

Valutate completamento e sicurezza separatamente. Un artefatto finale corretto non deve compensare un effetto collaterale pericoloso: è questa la lezione centrale dei risultati di AgentS4D. 12

Ripetere i test a ogni modifica della configurazione

L’oggetto da approvare è la configurazione fissata a una versione, non un’etichetta permanente come “agente DeepSeek V4 Pro”. La suite specifica va ripetuta dopo ogni modifica sostanziale a:

• modello o percorso del provider;
• impostazioni d’inferenza o livello di effort;
• prompt di sistema o adattatore;
• logica dell’harness o della sessione;
• strumenti o server di strumenti remoti;
• policy sui permessi e sulle approvazioni;
• instradamento delle credenziali;
• comportamento di memoria, retry, timeout o concorrenza;
• confini di rete o filesystem.

Questo approccio trasforma la sicurezza del runtime da un’ipotesi generale sulla qualità del modello in una decisione di rilascio misurabile, legata all’ambiente preciso che può produrre effetti nel mondo reale.