Rischi per la sicurezza degli agenti AI: costruire un registro delle minacce operative

Il metodo pratico per gestire i rischi di sicurezza degli agenti AI è quello di modellare le minacce di ciascuna operazione di effetto collaterale prima della chiamata degli strumenti. Registrare quali attività possono cambiare, quale identità fornisce autorità, quali ambiti sono richiesti, da dove viene l'istruzione, come l'effetto sarà limitato e quali prove rendono un nuovo tentativo sicuro. Se un campo è sconosciuto, fermati a quel confine invece di chiedere al modello di dedurre il permesso. Ciò produce una decisione utile, non un altro elenco di rischi. L'operatore può procedere, restringere una credenziale, rimuovere le autorizzazioni in eccesso, rivedere un'istruzione non fidata, definire un limite di effetto o conciliare un risultato ambiguo prima di riprovare. Una risposta valida non è sufficiente: la sicurezza dipende dall'autorità utilizzata e dall'effetto esterno prodotto. Il modello minaccia l'operazione, non solo il modello Un agente e' piu' di un LLM. Unisce un modello, il tempo di esecuzione, le credenziali, gli strumenti, i contenuti esterni e i sistemi di destinazione in un unico percorso di azione. La Sicurezza della carta AI Agenti rende esplicita questa distinzione: gli agenti utilizzano azioni generate dal modello per invocare strumenti che possono influenzare i sistemi reali, creando preoccupazioni di riservatezza, integrità e disponibilità al di là dell'allineamento del modello. Inizia con un'operazione proposta e disegni quattro confini: 1. Limiterie di istruzione: L'intenzione dell'utente, il contenuto recuperato, l'output dello strumento e la memoria entrano nel contesto del modello. 2. ALimita di autorizzazione: il runtime attacca un'identità o una credenziale all'appello di strumento proposto. 3. EEffect boundary: lo strumento può leggere o modificare una risorsa esterna. 4. Retry boundary: risultati di trasporto o di attrezzatura incerti possono causare la ripetizione dell'effetto del tempo di esecuzione. La Iniziativa di sicurezza agenziale dell'OWASP descrive le sue linee guida come un riferimento basato sul modello di minaccia per i rischi agentici emergenti. Questa è la giusta posizione di partenza: identificare le attività, gli attori, i cambiamenti di fiducia e i possibili effetti prima di scegliere i controlli. Utilizzare un libro maggiore di minacce a livello di esecuzione piuttosto che note in forma libera: Non inserire valori segreti nel libro. Storia di riferimenti, identificatori di emittente e di pubblico, scadenza, ambiti, identità di operazione e posizioni di prova. L'artefatto dovrebbe rispondere a: cosa potrebbe cambiare, sotto la cui autorità, e come sapremo? senza diventare un'altra perdita di credenziali. Il default ragionevole è quello di creare una riga di registro per ogni operazione esterna. Un modello di minaccia generale a livello di agente aiuta ancora con l'architettura, ma non può dirti se questo particolare pagamento, messaggio, rilascio o mutazione di file è sicuro ora. Verificare l'identità delle credenziali prima di verificare il richiesto Una credenziale non è sicura solo perché autentica. Per ciascuna operazione, registrazione: chi o cosa rappresenta la credenziale; il luogo in cui è stato rilasciato e il luogo in cui può essere presentato; se è condiviso tra agenti o ambienti; il suo percorso di scadenza e di revoca; il pubblico delle risorse esatto; un riferimento non segreto che consente all'operatore di girarlo. Il giugno 2025 Specifica dell'autorizzazione MCP è concreto sul confine HTTP. I clienti includono un indicatore delle risorse, i server confermano che un token è stato emesso per il pubblico previsto e un'autorizzazione invalida o insufficiente riceve un errore. Il relativo Guida per la sicurezza dei MCP vieta il passaggio dei token e spiega perché la confusione del pubblico indebolisce i confini di controllo, attribuzione e fiducia. Tali norme si applicano direttamente alle autorizzazioni HTTP MCP. Il principio di funzionamento va bene anche: non lasciare mai che un singolo token opaco sia silenzioso per ogni destinazione. Un token di amministratore condiviso senza proprietario di attività e senza pubblico stretto può funzionare perfettamente distruggendo l'attribuzione e aumentando il raggio di esplosione. La salute credenziale e la sicurezza delle istruzioni sono separate. Un prompt pulito non può riparare un token scaduto, e un token valido non rende legittima un'istruzione non fidata. Controlla prima le prove di credenziale perché ogni controllo successivo dipende dal sapere quale identità attraverserà il confine dello strumento. Quando mancano prove, utilizzare stop credential , non probabilmente autorizzato. La riparazione è meccanica: rilasciare una credenziale di breve durata revocabile per l'agente esatto, il compito, il pubblico e l'ambiente. Tieni fuori il modello da quella decisione. Confronta l'autorizzazione richiesta con l'autorizzazione concessa Il minimo privilegio diventa verificabile solo quando si confrontano due set per un'operazione: Se surplus non è vuoto, interrompere e sostituire la sovvenzione. Non basta uno strumento autorizzato. Lo stesso utente utente può portare scopes non correlati al lavoro attuale, e quelle autorizzazioni latente diventano disponibili quando il contesto è avvelenato, un argomento utente è sostituito, o il modello semplicemente sceglie l'operazione sbagliata. Rifiutare anche le sfere richieste mancanti. Tale caso è di solito meno pericoloso dell'autorità in eccesso, ma crea tentativi rumorosi e incoraggia soluzioni non sicure come lo scambio di credenziali più ampie. Un disadattamento delle autorizzazioni dovrebbe produrre uno stato esplicito e una riparazione, non un invito per l'agente a cacciare segreti più forti. I controlli delle autorizzazioni richiedono una descrizione degli effetti. Utilizzare lo strumento del repository è troppo ampio; create one release candidate in repository X fornisce una risorsa e un tetto di impatto. Legare l'approvazione, se necessario, a tale descrizione congelata. L'analisi umana è utile per le operazioni ad alto impatto o non affidabili, ma non si dovrebbe chiedere a una persona di approvare un'azione che abbia ancora risorse non nominate o effetti illimitati. Questo è il punto in cui un modello di minaccia differisce da un'implementazione di guardrail. Il libro dei rischi identifica l'autorità e l'effetto che richiedono protezione. Politica, approvazione, sandboxing e verifica sono controlli selezionati successivamente. A partire da soli i controlli spesso lasciano le squadre a proteggere il prompt mentre una credenziale sopraffatta rimane invariata. Trattare le istruzioni, gli effetti e i ripetizioni come rischi separati Il contenuto esterno può influenzare un agente senza diventare autorità. La provenienza dell'istruzione è contrassegnata come trusted , untrusted external content o mixed . Se un contenuto non fidato contribuisce ad un'azione collaterale, congela la risorsa e gli argomenti proposti, richiede una decisione politica o una revisione umana al di fuori di tale percorso di contenuti. Non risolvere questo problema eliminando ogni istruzione esterna. Un agente può avere bisogno di documenti recuperati o di output di strumenti per lavorare. Il limite di sicurezza è se quel contenuto può scegliere silenziosamente un effetto privilegiato. Un'analisi solo per lettura e un messaggio pubblico non dovrebbero condividere la stessa regola di riesame. In seguito, definire l'effetto indipendentemente dalla risposta dello strumento: la risorsa di destinazione esatta; il numero massimo o la dimensione delle modifiche; reversibilità e proprietario di rollback; identità di funzionamento stabile; una lettura di ritorno autorizzata o un'altra prova del risultato. I retries meritano la propria riga perché un timeout non significa che non è successo nulla. AWS Builders Guida bibliografica sulle API idempotent mostra come un identificatore di richieste di cliente stabile possa rendere le richieste ripetute semanticamente equivalenti. Quel contratto supporta i ripeti tentativi di sicurezza. Non autorizza l'azione originale e non aiuta se il runtime genera un nuovo identificatore per il secondo tentativo. Dopo un termine ambiguo, utilizzare l'ordine seguente: 1. mantenere l'identità dell'operazione originale; 2. consultare la destinazione autorizzata; 3. classificare l'effetto come presente, assente, parziale o sconosciuto; 4. riprovare solo quando il contratto rende sicuro un altro tentativo; 5. verificare il risultato promesso dopo il tentativo finale. Se la destinazione non offre né idempotenza né ricerca di effetti, lo stato corretto è reconcile before retry . Questo potrebbe richiedere una persona. E' ancora meglio che trasformare le prove mancanti di trasporto in un doppio pagamento, messaggio, rilascio o cancellazione. Riproduci il libro dei nove casi di minaccia Il dispositivo di accompagnamento rende la regola decisionale ispezionabile. security risk cases.json contiene nove operazioni proposte. evaluate ai agent threat ledger.mjs controlla i confini in ordine fisso: 1. la presenza, la scadenza, la condivisione, la revocabilità e il pubblico di credenziali; 2. gli ambiti richiesti rispetto agli ambiti concessi; 3. provenienza non affidabile dell'istruzione per le scritture; 4. la definizione delle risorse e dell'effetto massimo; 5. l'identità dell'operazione, l'idempotenza e la riconciliazione prima delle riprovazioni; 6. prove di effetti indipendenti. Fate partire con: Il riassunto riprodotto è il seguente: Ci sono solo due casi in corso. Uno è una lettura limitata. L'altra è una scrittura idempotente con un pubblico esatto, un insieme di ambiti esatti, una risorsa nominata, un impatto massimo e prove indipendenti. I restanti casi dimostrano una credenziale di amministratore condivisa, un token di attività scaduto, un campo di applicazione di eliminazione di eccesso, un'istruzione esterna non riveduta, un'esportazione illimitata, un nuovo tentativo con una nuova identità operativa e una risposta di successo senza prova di effetto. L'ordine e' importante. Se l'autorizzazione viene controllata prima del pubblico credenziale, un token cross service può apparire sicuro perché il suo scopo coincide. Se le prove dell'effetto sono verificate prima di riprovare l'identità, l'operatore può etichettare la corsa semplicemente incompleta mentre è già possibile un altro tentativo non sicuro. Il primo limite di fiducia non sicuro dovrebbe determinare la disposizione. Adatta il dispositivo ai tuoi effetti reali. Aggiungi un percorso di revoca mancante, ambiente sbagliato, approvazione obsoleta, sostituzione delle risorse, scrittura parziale, fallimento del rollback e disaccordo tra l'output dello strumento e lo stato di destinazione. L'obiettivo non è quello di prevedere ogni attacco. È per rendere impossibili l'autorità e l'incertezza di nascondere all'interno di uno stato di agente verde. Mantenere operativo il modello di minaccia Rivedi il libro di contabilità quando un strumento, la portata, l'emittente delle credenziali, l'API di destinazione, la politica di riprova o la fonte delle istruzioni cambiano. Non richiede un laboratorio completo per ogni esecuzione; generare la maggior parte dei campi da schemi di strumenti, metadati di identità, policy e ricevute operative, quindi chiedere a una persona solo l'impatto o l'incertezza che il codice non può risolvere. La regola della decisione compatta è: Proseguire solo quando l'identità è legata al pubblico, le autorizzazioni sono uguali al set richiesto, le istruzioni non affidabili non possono autorizzare silenziosamente gli effetti, l'impatto è limitato, i retri preservano l'identità dell'operazione e la destinazione può dimostrare il risultato. Questa regola ha dei limiti. I metadati possono mentire o diventare obsoleti. Un ambito preciso può ancora permettere una discussione pericolosa. L' impotenza può scadere. Un canale di lettura può essere compromesso con lo scrittore. Il libro maggiore riduce quindi l'ambiguità; non dimostra che l'intero sistema sia sicuro. Accoppiarlo con l'autorizzazione a valle, l'isolamento, i registri di audit, i test e la risposta agli incidenti adeguati all'impatto. Sidewisp è attualmente in anteprima privata. È inteso come uno strato di salute intorno ai tempi di esecuzione degli agenti esistenti, ma la raccolta e il recupero dell'agente di produzione e della salute non vengono inviati nel repository attuale del sito web. Questo modello di threat ledger è qualcosa che gli operatori possono attuare nel loro tempo di esecuzione ora, non una affermazione che Sidewisp attualmente protegge o monitora gli agenti in diretta. Se si sta valutando Sidewisp per futuri flussi di lavoro in materia di salute degli agenti, partecipare all' anteprima privata. Fino ad allora, tenete il registro delle minacce vicino ai confini degli strumenti e lasciate che le prove sconosciute fermino l'azione prima che diventi un incidente.