La guida di sicurezza a cinque livelli di Mend affronta i rischi dell'IA in produzione oltre i guardrail dei prompt

Mend.io ha pubblicato un approccio alla sicurezza su cinque livelli che è arrivato su Google News, ma il suo messaggio centrale mette in discussione il modo in cui molti team proteggono l'IA in produzione. I soli guardrail dei prompt non possono proteggere agenti che detengono credenziali, chiamano strumenti, mantengono memoria e modificano sistemi esterni.

La guida, trattata da MarkTechPost il 3 agosto, organizza la superficie d'attacco in livelli di interazione, agente, integrazione, modello e codice. Il suo valore pratico risiede nel considerare un'applicazione IA come un sistema eseguibile, non semplicemente come un chatbot con rischi di input insoliti.

Questa distinzione genera il vero conflitto. Gli sviluppatori vogliono che gli agenti completino più lavoro con meno interruzioni. I team di sicurezza necessitano di limiti deterministici quando tali agenti incontrano documenti ostili, strumenti compromessi, autorizzazioni eccessive o percorsi di esecuzione inattesi.

MCP, abbreviazione di Model Context Protocol, offre alle applicazioni IA un'interfaccia standard per scoprire e chiamare strumenti esterni. Può collegare un modello a database, file system, API, applicazioni aziendali e ambienti di sviluppo.

Il protocollo migliora l'interoperabilità, ma questa comodità amplia il numero di confini di fiducia all'interno di ogni workflow. Un agente può ora trasformare testo non attendibile in un'azione significativa nel giro di pochi secondi.

La domanda non è più se un modello produca una risposta inappropriata. È se un modello manipolato possa usare uno strumento autorizzato per uno scopo non autorizzato.

Google News porta la sicurezza dell'IA in produzione al centro dell'attenzione

L'evento importante è il passaggio dalla discussione sul comportamento del modello alla protezione dell'intero percorso tra input ed esecuzione.

La guida alla sicurezza in produzione evidenziata da Google News presenta la sicurezza degli agenti come un problema ingegneristico a cinque livelli. Il livello di interazione comprende prompt, documenti recuperati, file degli utenti e altre informazioni in ingresso nell'applicazione.

Il livello dell'agente include pianificazione, memoria, selezione degli strumenti e attività delegate. Il livello di integrazione comprende server MCP, API, database, plugin e altre connessioni che trasferiscono le decisioni dell'agente verso sistemi esterni.

Il livello del modello include il modello linguistico, la sua configurazione e i suoi limiti comportamentali. Il livello del codice include logica applicativa, dipendenze, infrastruttura, credenziali e pipeline di distribuzione.

Questa impostazione è importante perché i guasti attraversano spesso diversi livelli. Un'istruzione dannosa può entrare attraverso un documento, influenzare il ragionamento del modello, attivare uno strumento MCP consentito ed esporre dati tramite un'ordinaria richiesta API.

Ogni componente può sembrare funzionare come previsto. Il fallimento della sicurezza emerge dalla loro composizione.

La sicurezza applicativa tradizionale resta importante all'interno di questo stack. I team devono aggiornare le dipendenze, proteggere i segreti, convalidare gli input, isolare i workload e revisionare il codice. Tuttavia, tali controlli non descrivono pienamente perché un agente abbia selezionato uno strumento valido nel momento sbagliato.

Il modello opera su istruzioni e dati espressi attraverso lo stesso mezzo di base. Una pagina recuperata può contenere informazioni che rispondono alla domanda dell'utente, istruzioni che reindirizzano l'agente oppure entrambe le cose.

Questo crea l'iniezione indiretta di prompt, in cui istruzioni dannose arrivano tramite contenuti esterni invece che dal prompt visibile dell'utente. Un agente che legge email, pagine web, ticket di supporto o documenti interni può incontrare tali contenuti durante il normale lavoro.

L'attacco può rimanere invisibile alla persona che ha avviato l'attività. L'agente potrebbe riassumere il documento atteso mentre chiama silenziosamente un altro strumento o incorpora informazioni compromesse nella memoria.

L'impostazione a cinque livelli di Mend.io funge quindi da metodo di inventario. Chiede ai team di identificare ogni punto in cui istruzioni, autorità, codice, dati e stato possono entrare o uscire dal sistema.

Tale inventario dovrebbe includere più dei modelli distribuiti. Dovrebbe registrare configurazioni degli agenti, prompt di sistema, server MCP, strumenti disponibili, ambiti di autorizzazione, archivi di memoria, fornitori di modelli, dipendenze e responsabili.

Senza questa mappa, i team non possono stabilire se un componente compromesso possa raggiungerne un altro. Non possono nemmeno revocare l'accesso con sicurezza quando un'integrazione cambia comportamento.

L'evento non è una nuova release di protocollo né una singola vulnerabilità divulgata. È un confine più chiaro per la produzione: la sicurezza degli agenti deve seguire l'intera catena di esecuzione.

Questo confine mette sotto pressione sviluppatori, team di piattaforma, ingegneri della sicurezza e fornitori di IA simultaneamente. Ogni gruppo controlla solo una parte del sistema, mentre i fallimenti più gravi attraversano tali divisioni organizzative.

Gli agenti IA trasformano il linguaggio in azioni privilegiate

Un LLM diventa un problema di sicurezza sostanzialmente diverso quando il suo output controlla software dotato di autorità reale.

Un chatbot convenzionale produce testo che una persona può revisionare. Un agente può interpretare un obiettivo, selezionare uno strumento, costruire argomenti, ispezionare il risultato e continuare ad agire senza un'altra decisione umana.

Questo ciclo modifica le conseguenze di una risposta errata del modello. Una frase inventata è scomoda, ma un'istruzione inventata passata a un database o a uno strumento di distribuzione può trasformarsi in un incidente operativo.

Si consideri un agente di ricerca interno a cui viene chiesto di confrontare proposte di fornitori. Legge documenti caricati, cerca nello storage condiviso, interroga record di approvvigionamento e redige una raccomandazione.

Una proposta dannosa può nascondere istruzioni che inducono l'agente a recuperare prezzi riservati da un'altra cartella. Se lo strumento di storage dispone di autorizzazioni ampie, la decisione errata del modello diventa un reale percorso di divulgazione.

Un agente di coding crea un problema simile. Può leggere repository, installare dipendenze, eseguire test, modificare file e aprire pull request. Testo non attendibile nelle issue o nella documentazione dei pacchetti può influenzare lo stesso modello che dispone di tali capacità.

MCP rende queste connessioni più facili da costruire in modo coerente. Questo avvantaggia gli sviluppatori, ma significa anche che una descrizione dello strumento, una risposta dello strumento o un server remoto possono influenzare le scelte successive di un agente.

La guida alla sicurezza degli agenti di OWASP identifica iniezione di prompt, abuso degli strumenti, esfiltrazione di dati, avvelenamento della memoria, autonomia eccessiva e fallimenti a cascata tra i rischi principali. Queste categorie sono collegate, non isolate.

La memoria è particolarmente importante. La memoria persistente dell'agente memorizza informazioni per sessioni future, consentendo a un'applicazione di ricordare preferenze, lavori precedenti o conoscenze accumulate.

Se contenuti non attendibili entrano in tale archivio senza convalida, un attacco può sopravvivere alla fine della conversazione originale. Gli utenti successivi potrebbero ricevere informazioni avvelenate o attivare comportamenti influenzati da un documento precedente.

I sistemi multi-agente aumentano il potenziale raggio d'azione. Un agente può trasmettere istruzioni, riassunti, credenziali o risultati degli strumenti a un altro agente con autorizzazioni diverse.

Un agente di ricerca compromesso potrebbe non avere accesso in scrittura al database. Tuttavia, potrebbe fornire risultati manipolati a un agente operativo che invece lo possiede.

I team non possono risolvere questo problema limitandosi a dire a ogni modello di ignorare istruzioni dannose. I modelli devono elaborare linguaggio naturale per svolgere il proprio lavoro, e gli attaccanti possono variare formulazione, contesto, codifica e canali di consegna.

L'obiettivo della sicurezza deve quindi essere il confine dell'azione. Prima che uno strumento venga eseguito, un software deterministico dovrebbe decidere se agente, utente, risorsa, operazione e parametri costituiscano una combinazione consentita.

Un'operazione di lettura non dovrebbe trasformarsi silenziosamente in una scrittura. L'accesso a un repository non dovrebbe concedere l'accesso a tutti i repository. L'autorizzazione a redigere un'email non dovrebbe permettere automaticamente di inviarla.

Le operazioni ad alto impatto richiedono un trattamento più rigoroso. Trasferimenti finanziari, modifiche in produzione, amministrazione degli account, eliminazione di dati, pubblicazione esterna e accesso alle credenziali dovrebbero richiedere autorizzazione esplicita o approvazione umana.

L'approvazione deve essere vincolata all'azione effettiva. Una conferma vaga come “continua” è più debole di un'approvazione che mostri destinazione, operazione, risorsa interessata e parametri rilevanti.

Le credenziali di breve durata riducono inoltre l'esposizione. Un agente dovrebbe ricevere l'autorità minima necessaria per l'attività corrente e perderla al termine dell'attività.

Questo approccio può aggiungere attrito, soprattutto quando gli sviluppatori misurano il successo in base al completamento delle attività e alla velocità. Tuttavia, l'alternativa consiste nel consentire al ragionamento probabilistico di funzionare come sistema di controllo degli accessi.

I modelli linguistici possono proporre azioni. Non dovrebbero definire unilateralmente la propria autorità.

MCP standardizza le connessioni, non la governance completa

MCP risolve un problema di compatibilità, mentre i team di produzione devono comunque costruire attorno a esso il livello di policy e responsabilità.

Un client MCP può recuperare le definizioni degli strumenti disponibili su un server e presentarle a un modello. Il modello usa tali descrizioni e schemi dei parametri per selezionare e invocare uno strumento.

Questa struttura riduce il lavoro di integrazione personalizzata. Un client compatibile può connettersi a molti server attraverso un protocollo condiviso invece di apprendere un'interfaccia separata per ogni servizio.

Tuttavia, la scoperta standard non rende affidabile ogni strumento scoperto. Un server può essere compromesso, impersonato, configurato in modo errato o aggiornato dopo una revisione iniziale della sicurezza.

L'avvelenamento degli strumenti sfrutta questa fiducia. Istruzioni dannose inserite nella descrizione di uno strumento possono influenzare il modello rimanendo nascoste all'interazione ordinaria dell'utente.

Anche una risposta dello strumento può contenere istruzioni simili. L'agente potrebbe trattare la risposta come dati, ma il modello linguistico può interpretare testo incorporato come una direttiva che influenza azioni successive.

Le più recenti regole di autorizzazione MCP includono requisiti che affrontano convalida dei token, vincolo dell'audience, furto di token, sicurezza delle comunicazioni, rischi di reindirizzamento e attacchi confused-deputy.

Tali requisiti rafforzano l'infrastruttura di autenticazione e autorizzazione. Non stabiliscono se una particolare azione aziendale sia appropriata per l'obiettivo attuale dell'utente.

Un token di accesso valido stabilisce un'autorità riconosciuta nel proprio ambito. Non dimostra che un modello abbia preso la decisione giusta dopo aver letto contenuti non attendibili.

I sistemi di produzione necessitano di un punto di controllo tra l'intento del modello e l'esecuzione dello strumento. Tale livello può valutare identità, operazione richiesta, risorsa, parametri, rischio della sessione, classificazione dei dati e azioni precedenti.

Microsoft ha descritto questa lacuna presentando un approccio open source alla governance in fase di esecuzione. Il suo interno benchmark di governance ha testato 60 prompt, inclusi 45 casi avversari e 15 casi validi.

Microsoft ha riportato un tasso di violazione delle policy del 26,67 percento quando il sistema si basava esclusivamente su istruzioni di sicurezza nei prompt. L'azienda ha fornito metodologia e materiali di riproduzione, ma il risultato resta una sua valutazione.

Il dato illustra comunque un importante principio progettuale. Le prestazioni nel seguire le istruzioni non dovrebbero essere considerate un confine di sicurezza deterministico.

Un control plane in fase di esecuzione può consentire, negare o escalare ogni richiesta di strumento. Può inoltre ispezionare le definizioni degli strumenti prima di esporle al modello e analizzare le risposte prima di restituirle all'agente.

Un tale livello dovrebbe applicare schemi, vincoli sui parametri, liste di risorse consentite, limiti di velocità, limiti di costo e una profondità massima delle catene. Dovrebbe interrompere i fallimenti ripetuti invece di consentire a un agente di entrare in un ciclo di tentativi incontrollato.

Per esempio, un agente di assistenza clienti potrebbe dover leggere il record di un account e preparare una raccomandazione per un rimborso. Non ha bisogno di un accesso illimitato al database né dell'autorizzazione immediata a emettere ogni rimborso che propone.

Il livello di policy può limitare le letture al cliente corrente, nascondere i campi sensibili, fissare un tetto all'importo del rimborso e richiedere l'approvazione umana prima del pagamento. Il modello resta utile senza ricevere un'ampia autorità operativa.

Anche l'isolamento è importante. Gli strumenti con privilegi elevati non dovrebbero condividere lo stesso contesto dell'agente con server MCP esterni arbitrari.

Un agente che legge contenuti web pubblici non dovrebbe ottenere automaticamente una via di accesso agli strumenti di amministrazione interni. Separare queste capacità riduce la probabilità che contenuti esterni ostili raggiungano superfici di esecuzione sensibili.

I team di sicurezza dovrebbero inoltre mantenere un registro dei server approvati. Ogni voce dovrebbe identificare il proprietario del server, la fonte del codice, la posizione di distribuzione, il metodo di autenticazione, gli strumenti disponibili, l'accesso ai dati, la versione e lo stato della revisione.

Gli aggiornamenti devono attivare una revisione quando modificano descrizioni degli strumenti, schemi, dipendenze, autorizzazioni o destinazioni di rete. Un server che ha superato una revisione mesi prima non dovrebbe ricevere fiducia permanente.

I server MCP richiedono anche protezioni di servizio convenzionali. I team necessitano di trasporto sicuro, autenticazione, patching, gestione delle dipendenze, convalida degli input, isolamento dei segreti, logging e risposta agli incidenti.

Il protocollo non sostituisce questi controlli. Crea un altro contesto in cui devono essere applicati in modo coerente.

Il Vero Compromesso È Tra Autonomia e Contenimento

Ogni capacità aggiuntiva aumenta l'utilità di un agente, ma anche il danno potenziale di una manipolazione riuscita.

Questo compromesso spiega perché la sicurezza degli agenti non può ridursi a una checklist aggiunta immediatamente prima della distribuzione. Il design del prodotto determina l'autorità massima del sistema molto prima che uno scanner di sicurezza lo esamini.

Un agente senza strumenti può produrre testo dannoso o impreciso. Un agente con accesso ai file può esporre documenti. Un agente con accesso alla shell può eseguire comandi, mentre uno connesso a sistemi di produzione può modificare infrastrutture operative.

Le autorizzazioni ampie spesso entrano nei prototipi per comodità. Gli sviluppatori vogliono verificare se un agente possa completare un flusso di lavoro end-to-end prima di investire in autorizzazioni dettagliate.

Questi prototipi possono avvicinarsi alla produzione più rapidamente del previsto. Le credenziali temporanee restano nella configurazione, i server MCP sperimentali diventano infrastruttura condivisa e gli schemi permissivi degli strumenti si trasformano in dipendenze non documentate.

Il modello a cinque livelli aiuta a far emergere queste scorciatoie. Tuttavia, un inventario da solo non le contiene.

Ogni agente necessita di un confine di fiducia definito. Tale confine dovrebbe indicare chi può invocarlo, quali dati può ricevere, quali strumenti può usare, quali risorse può raggiungere e quali risultati richiedono approvazione.

I team dovrebbero distinguere tra modalità di lettura, bozza, raccomandazione ed esecuzione. Queste etichette devono corrispondere a permessi applicabili, non a semplice formulazione del prompt.

Un agente di ricerca può leggere fonti approvate e redigere risultati. Un agente operativo può preparare un piano di distribuzione. Un processo separato e controllato può verificare ed eseguire quel piano.

Questa separazione riduce l'autonomia, ma crea anche transizioni verificabili. Gli investigatori possono vedere quando un'informazione è diventata una raccomandazione e quando quella raccomandazione è diventata un'azione.

L'osservabilità sostiene lo stesso obiettivo. I log dovrebbero acquisire l'utente che ha avviato l'operazione, l'identità dell'agente, la versione del modello, la versione del prompt o della policy, il server MCP, il nome dello strumento, gli argomenti, la classificazione della risposta, il record di approvazione e l'esito finale.

I dati sensibili non dovrebbero essere copiati con leggerezza in questi log. La telemetria di sicurezza necessita di contesto sufficiente per l'indagine senza creare un altro archivio di segreti esposti.

L'identità dell'agente merita particolare attenzione. Condividere un account di servizio tra molti agenti rende difficile attribuire responsabilità o revocare un singolo flusso di lavoro compromesso.

Identità separate consentono permessi per agente e piste di audit più chiare. Aiutano inoltre i team di sicurezza a individuare comportamenti anomali, come un agente di ricerca che richiede improvvisamente accesso in scrittura.

Le linee guida governative ora considerano MCP un'infrastruttura che richiede una progettazione della sicurezza deliberata. Le linee guida sulla sicurezza MCP della NSA di maggio 2026 trattano autenticazione, autorizzazione, isolamento, convalida dei server, gestione del ciclo di vita e rischi che interessano i componenti del protocollo.

Questa attenzione segnala un cambiamento di maturità. MCP non è più soltanto una comodità per sviluppatori discussa attraverso demo locali. Le organizzazioni lo stanno valutando per ambienti in cui strumenti compromessi possono influire su dati e operazioni sensibili.

I controlli di sicurezza per gli agenti di Google Cloud sottolineano un punto simile. Le linee guida raccomandano un'identità distinta per l'agente, ruoli con privilegi minimi e restrizioni che impediscano l'accesso degli strumenti di lettura-scrittura alle risorse di produzione.

Si tratta di principi di sicurezza familiari. La loro applicazione diventa più difficile perché gli agenti selezionano azioni dinamicamente e combinano strumenti individualmente validi in flussi di lavoro che gli sviluppatori non hanno enumerato.

Il concatenamento insicuro degli strumenti si verifica quando il risultato di un'operazione consentita rende possibile una sequenza dannosa. Uno strumento di ricerca, un lettore di file e uno strumento di messaggistica in uscita possono sembrare ciascuno a basso rischio se esaminati separatamente.

Insieme, possono creare un percorso di esfiltrazione dei dati. L'agente cerca informazioni sensibili, le legge e le trasmette fuori dall'organizzazione.

La policy deve quindi esaminare le sequenze oltre alle singole chiamate. Una richiesta può essere valida da sola, ma sospetta dopo un altro evento nella stessa sessione.

I controlli consapevoli del contesto possono bloccare combinazioni che coinvolgono input non attendibili e output privilegiati. Possono inoltre richiedere una nuova autorizzazione quando un agente passa dalla raccolta di informazioni a un'azione esterna.

Questo design è più impegnativo rispetto all'aggiunta di un filtro intorno al prompt dell'utente. Richiede coordinamento tra i team di prodotto, piattaforma, identità, sicurezza applicativa e operazioni.

Questo costo organizzativo fa parte del compromesso. Le aziende non possono rivendicare ampie capacità autonome assegnando al contempo la responsabilità della sicurezza solo al fornitore del modello.

Ciò Che La Sicurezza di Produzione Non Può Ancora Garantire

I controlli stratificati riducono l'esposizione, ma nessun framework attuale dimostra che un agente resterà sicuro in ogni combinazione di modello, strumento e contesto.

La prima incertezza riguarda la qualità della valutazione. I test di sicurezza possono misurare attacchi noti, ma gli input di produzione cambiano continuamente e gli avversari si adattano alle difese pubblicate.

Una suite di red teaming dovrebbe includere prompt injection diretta e indiretta, uso non autorizzato degli strumenti, escalation dei privilegi, avvelenamento della memoria, esfiltrazione dei dati, aggiramento dell'approvazione, esecuzione ricorsiva e propagazione multi-agente.

I team dovrebbero eseguire questi test prima della distribuzione e dopo modifiche sostanziali. Un nuovo modello, prompt di sistema, design della memoria, server MCP, schema degli strumenti, fonte di recupero o policy può modificare la superficie di attacco.

Il superamento di un test non stabilisce una sicurezza permanente. Dimostra che controlli definiti hanno resistito ad attacchi definiti in condizioni specifiche.

I falsi positivi creano un altro problema. Se i controlli interrompono troppe attività legittime, gli utenti cercano soluzioni alternative o chiedono autorizzazioni più ampie.

I falsi negativi sono più pericolosi ma più difficili da osservare. Un agente può completare l'attività richiesta mentre perde dati, salva memoria avvelenata o compie un'azione non necessaria.

L'approvazione umana non è una soluzione completa. Gli utenti possono abituarsi alle conferme, soprattutto quando un'applicazione presenta prompt frequenti o poco chiari.

Gli aggressori possono anche manipolare le informazioni mostrate all'approvatore. Le interfacce di approvazione devono ottenere i dettagli dell'azione da dati di esecuzione attendibili, non soltanto dalla spiegazione del modello.

Anche il rischio della catena di fornitura resta irrisolto. Le distribuzioni MCP possono includere server, SDK, registri, pacchetti, modelli, container e servizi ospitati gestiti da parti diverse.

Un pacchetto firmato può stabilire origine e integrità. Non può garantire che il comportamento firmato sia sicuro né che un servizio remoto rimanga invariato.

Le organizzazioni dovrebbero preferire distribuzioni riproducibili, versioni fissate, codice sorgente revisionato, registri controllati e processi di aggiornamento documentati. I server remoti necessitano di convalida continua, non di un'approvazione una tantum.

La revoca d'emergenza deve essere praticabile. I team dovrebbero poter disabilitare un agente, un server, uno strumento, una credenziale o un permesso senza attendere il rilascio di un'applicazione.

I sistemi di memoria necessitano di controlli equivalenti. Gli operatori richiedono metodi per ispezionare, mettere in quarantena, far scadere e rimuovere voci sospette preservando al contempo le prove per l'indagine.

Lo scetticismo si applica anche alle dichiarazioni dei fornitori. I prodotti di sicurezza promettono sempre più protezione dei prompt, red teaming automatizzato, rilevamento degli agenti, gestione della postura o applicazione in fase di esecuzione.

Queste capacità possono contribuire alla difesa, ma gli acquirenti dovrebbero chiedersi dove si colloca ciascun controllo e cosa accade quando fallisce. Un rilevatore che segnala soltanto testo sospetto non può sostituire l'autorizzazione sull'azione risultante.

I team dovrebbero richiedere prove misurabili. Domande utili includono quali classi di attacco siano state testate, se i dati di valutazione siano disponibili, come vengano gestiti gli aggiramenti e se l'applicazione dei controlli fallisca in modo chiuso.

Dovrebbero inoltre esaminare latenza e disponibilità. Un servizio di policy posto prima di ogni chiamata a uno strumento diventa infrastruttura critica.

Se quel servizio fallisce in modalità aperta, gli agenti possono agire senza controlli. Se fallisce in modalità chiusa, i flussi di lavoro dipendenti si interrompono. Il design di produzione deve affrontare esplicitamente entrambi gli esiti.

L'approccio a cinque livelli è quindi una base, non una garanzia. Aiuta i team a individuare rischi che una revisione incentrata soltanto sul modello non coglierebbe.

Il suo successo dipende dalla conversione dei livelli in responsabilità, policy applicabili, test ripetibili e risposta operativa. Senza questi passaggi, il framework diventa un altro diagramma che documenta l'esposizione senza ridurla.

Tre Segnali Mostreranno Se La Sicurezza Degli Agenti Sta Maturando

La prossima fase sarà misurata da impostazioni predefinite applicabili, test indipendenti ed evidenze provenienti da distribuzioni reali.

Il primo segnale è se i client e i server MCP adotteranno per impostazione predefinita autorizzazioni più ristrette. Il supporto agli standard di autorizzazione moderni è importante, ma distribuzioni sicure richiedono anche ambiti specifici per risorsa e una chiara separazione tra operazioni di lettura e scrittura.

Un ecosistema più solido renderebbe le autorizzazioni ampie visibilmente eccezionali. I client mostrerebbero agli utenti a cosa può accedere ciascun server, mentre i server rifiuterebbero token destinati a un'altra risorsa.

Le restrizioni predefinite rafforzerebbero l'argomento secondo cui la connettività standardizzata può coesistere con il contenimento. La continua dipendenza da credenziali implicite e ambiti eccessivamente ampi lo indebolirebbe.

Il secondo segnale è la valutazione indipendente della governance in fase di esecuzione. I benchmark dei fornitori forniscono utili punti di partenza, ma gli acquirenti necessitano di test ripetibili su più modelli, strumenti e stili di attacco.

I valutatori dovrebbero riportare sia la prevenzione degli attacchi sia il completamento delle attività legittime. Un sistema che blocca ogni chiamata a uno strumento è sicuro in senso stretto, ma non assolve al proprio scopo operativo.

I risultati dovrebbero inoltre separare il rilevamento dei prompt dall'applicazione delle azioni. Rilevare linguaggio sospetto è diverso dall'impedire una lettura di file, un aggiornamento del database o una richiesta in uscita vietati.

Il terzo segnale è se le imprese riusciranno a produrre inventari completi degli agenti e registri degli incidenti. Le organizzazioni dovrebbero sapere quali agenti sono distribuiti, chi ne è responsabile, quali modelli utilizzano e quali server MCP possono raggiungere.

Dovrebbero inoltre essere in grado di ricostruire le azioni rilevanti a partire da log autenticati. Identità mancanti, registrazioni incomplete degli strumenti o modifiche ai permessi prive di spiegazione indicano che l’adozione ha proceduto più rapidamente della governance.

È qui che la gestione della conoscenza si interseca con le operazioni di sicurezza. I team hanno bisogno di registri ricercabili che colleghino requisiti, configurazioni degli agenti, risultati dei test, approvazioni, incidenti e decisioni di remediation.

Una base di conoscenza tecnica controllata può aiutare gli ingegneri a recuperare tali registri, ma deve rispettare gli stessi confini di accesso e gestione dei dati.

La presenza su Google News offre al modello di sicurezza a cinque livelli una visibilità più ampia. La sua importanza duratura dipende dal fatto che i team traducano questa visibilità in autorizzazioni più ristrette e controlli di esecuzione più solidi.

Gli sviluppatori dovrebbero iniziare da un singolo workflow di produzione e mappare ogni input, decisione del modello, scrittura in memoria, integrazione, credenziale, chiamata a uno strumento e output. Dovrebbero quindi identificare i punti in cui policy deterministiche interrompono movimenti non sicuri tra tali elementi.

La vostra organizzazione sa spiegare cosa può fare ogni agente in produzione, quale identità lo autorizza e come verrebbe contenuto un singolo documento compromesso? Se la risposta è incompleta, la prossima azione non è un’altra regola per i prompt. È un confine di esecuzione più ristretto, un percorso di approvazione testato e una traccia di audit che sopravviva al ragionamento dell’agente.