Sicurezza agente

La creazione di agenti di intelligenza artificiale sicura è una responsabilità condivisa tra Agent Framework e gli sviluppatori di applicazioni. Agent Framework fornisce i blocchi predefiniti, ovvero astrazioni, provider e orchestrazione, ma gli sviluppatori sono responsabili della convalida degli input, della protezione dei flussi di dati e della configurazione degli strumenti in modo appropriato per il proprio scenario.

Questo articolo illustra le procedure consigliate per la creazione di agenti sicuri e sicuri con Agent Framework.

Informazioni sui limiti di attendibilità

I dati passano attraverso diversi componenti quando viene eseguito un agente: input utente, provider di cronologia chat, provider di contesto, servizio LLM e strumenti per le funzioni. Ogni limite in cui i dati entrano o escono dall'applicazione rappresentano una potenziale superficie di attacco.

Limiti di attendibilità chiave da considerare:

• Servizio di intelligenza artificiale : riceve messaggi di chat (che possono includere informazioni personali e istruzioni di sistema) e restituisce l'output generato da LLM.
• Archiviazione della cronologia delle chat : i provider possono caricare e rendere persistenti i messaggi di conversazione tramite l'archiviazione esterna.
• Servizi di contesto : i provider di contesto possono recuperare o archiviare dati da servizi esterni (memorie, profili utente, risultati rag).
• Servizi accessibili tramite strumenti — gli strumenti per le funzioni eseguono codice fornito dallo sviluppatore che può chiamare API o database esterni.

Tutte le comunicazioni del servizio esterno vengono gestite dagli SDK client scelti dallo sviluppatore. Agent Framework non gestisce i dettagli di autenticazione, crittografia o connessione per questi servizi.

Procedure consigliate

Convalidare gli input della funzione

L'intelligenza artificiale può chiamare qualsiasi funzione specificata come strumento e scegliere gli argomenti. Considerare gli argomenti forniti da LLM come input non attendibile, in modo analogo all'input dell'utente in un'API Web.

• Usare l'elenco elementi consentiti: convalidare gli input in base a valori validi noti anziché provare a filtrare i modelli noti non validi. Ad esempio, verificare che un percorso di file si trova all'interno di una directory consentita anziché verificare la presenza .. di sequenze di attraversamento.
• Imponi vincoli di tipo e intervallo : verificare che gli argomenti siano del tipo previsto e all'interno di intervalli accettabili (limiti numerici, limiti di lunghezza stringa, intervalli di date).
• Limitare le lunghezze delle stringhe : imporre lunghezze massime agli argomenti stringa per evitare l'esaurimento delle risorse o gli attacchi di injection.
• Impedisci l'attraversamento del percorso : quando le funzioni accettano percorsi di file, risolverli in percorsi assoluti e verificare che rientrano nelle directory consentite.
• Usare query con parametri : se gli argomenti vengono usati nelle query SQL, nei comandi della shell o in altri contesti interpretati, usare query con parametri o escape, non eseguire mai la concatenazione di stringhe.

Richiedere l'approvazione per gli strumenti ad alto rischio

Per impostazione predefinita, tutti gli strumenti forniti a un agente vengono richiamati senza l'approvazione dell'utente. Usare il meccanismo di approvazione dello strumento per controllare le operazioni ad alto rischio dietro la conferma umana.

Quando si decide quali strumenti richiedono l'approvazione, prendere in considerazione:

• Effetti collaterali : gli strumenti che modificano i dati, inviano comunicazioni, effettuano acquisti o hanno altri effetti collaterali devono in genere richiedere l'approvazione.
• Riservatezza dei dati : strumenti che accedono o restituiscono dati sensibili (INFORMAZIONI personali, dati finanziari, credenziali) garantiscono l'approvazione.
• Reversibilità : le operazioni irreversibili (eliminazione, invio di messaggi di posta elettronica) sono più rischiose rispetto alle query di sola lettura.
• Ambito di impatto : gli strumenti con un impatto generale (operazioni bulk) devono richiedere un maggior controllo rispetto a quelli con ambito ristretto.

Mantenere i messaggi di sistema controllati dallo sviluppatore

I messaggi di chat hanno un ruolo (system, user, assistant, ) toolche determina come il servizio di intelligenza artificiale li interpreta. Comprendere questi ruoli è fondamentale:

Ruolo	Livello di attendibilità
system	Attendibilità massima : forme direttamente il comportamento LLM. Non deve mai contenere input non attendibile.
user	Non attendibile : può contenere tentativi di inserimento delle richieste o contenuto dannoso.
assistant	Non attendibile : generato dall'LLM, che è un sistema esterno.
tool	Non attendibile : può contenere dati provenienti da sistemi esterni o contenuti influenzati dall'utente.

Non inserire l'input dell'utente finale nei messaggi system-role. Agent Framework imposta per impostazione predefinita il testo non tipizzato al ruolo user, ma prestare attenzione quando si creano messaggi programmaticamente.

Provider di estensioni veterinarie

I provider di contesto e i provider di cronologia possono inserire messaggi con qualsiasi ruolo, incluso system. Allega solo i provider di cui ti fidi.

Essere consapevoli dell'inserimento indiretto della richiesta: se l'archivio dati sottostante è compromesso, il contenuto avversario potrebbe influenzare il comportamento dell'LLM. Ad esempio, un documento recuperato tramite RAG potrebbe contenere istruzioni nascoste che causano la deviazione dell'LLM dal comportamento previsto o dall'esfiltrazione dei dati tramite chiamate agli strumenti.

Convalidare e purificare l'output LLM

Le risposte LLM devono essere considerate come output non attendibili. Il servizio di intelligenza artificiale è un endpoint esterno che Agent Framework non controlla. Tenere presente quanto:

• Allucinazione — I LLM possono generare informazioni che sembrano plausibili ma sono in realtà scorrette. Non considerare l'output LLM come autorevole senza verifica.
• Inserimento indiretto della richiesta : i dati recuperati da strumenti, provider di contesto o provider di cronologia chat possono contenere contenuto antagonista progettato per influenzare l'LLM.
• Payload dannosi : l'output LLM può contenere contenuto dannoso se sottoposto a rendering o eseguito senza purificazione (HTML/JavaScript per XSS, SQL per injection, comandi della shell).

Convalidare e purificare sempre l'output LLM prima di eseguirne il rendering in HTML, eseguirlo come codice, usarlo nelle query di database o passarlo a qualsiasi contesto sensibile alla sicurezza.

Proteggere i dati sensibili nei log

Agent Framework supporta la registrazione e la telemetria tramite OpenTelemetry. I dati sensibili vengono registrati solo quando sono abilitati in modo esplicito:

• Registrazione — A livello di log Trace, viene registrata la raccolta completa ChatMessages. Può includere informazioni personali. Trace il livello non deve mai essere abilitato nell'ambiente di produzione.
• Telemetria : quando EnableSensitiveData è impostata, i dati di telemetria includono il testo completo dei messaggi di chat, incluse le chiamate di funzione e i risultati. Non abilitare questa opzione nell'ambiente di produzione.

Proteggere i dati della sessione

Le sessioni (AgentSession) rappresentano il contesto della conversazione e possono essere serializzate per la persistenza. Considerare le sessioni serializzate come dati sensibili:

• Le sessioni possono fare riferimento a contenuto di conversazione o identificatori di sessione.
• Il ripristino di una sessione da un'origine non attendibile equivale all'accettazione di input non attendibile. Un back-end di archiviazione compromesso potrebbe modificare i ruoli per aumentare l'attendibilità.
• Archiviare le sessioni nell'archiviazione sicura con controlli di accesso e crittografia appropriati.

Implementare i limiti delle risorse

Agent Framework non impone vincoli sulla lunghezza dell'input/output o sulla frequenza delle richieste, perché non sa cosa è ragionevole per lo scenario in uso. L'utente è responsabile di:

• Limiti di lunghezza dell'input : vincola la lunghezza dell'input per evitare attacchi di overflow del contesto o DoS.
• Limiti di lunghezza dell'output : usare i limiti forniti dal servizio (ad esempio, MaxOutputTokens nelle opzioni di chat).
• Limitazione della velocità : usare le funzionalità di limitazione della velocità per evitare sovraccarichi dei costi e abusi da richieste simultanee.

Passaggi successivi

Panoramica degli strumenti

Contenuti correlati

• Strumenti per le funzioni
• Osservabilità
• Provider di contesto