Thales Google Cloud AI Security aggiunge controlli, ma l'autonomia alza la posta

Thales ha ampliato la partnership con Google Cloud il 28 settembre, aggiungendo controlli di sicurezza per gli agenti AI nonostante restino aperti interrogativi su quanto affidabilmente le protezioni possano contenere i sistemi autonomi. L'integrazione di sicurezza AI Thales Google Cloud collega Thales AI Security Fabric a Gemini Enterprise. Punta alle interazioni tra utenti, agenti, modelli, dati aziendali e strumenti esterni.

L'annuncio riflette un cambiamento più ampio nell'AI aziendale. Gli assistenti generavano principalmente risposte da sottoporre alla revisione delle persone. Ora gli agenti possono selezionare strumenti, recuperare record sensibili, chiamare API e modificare sistemi aziendali. Un'istruzione malevola o un'autorizzazione eccessiva può quindi produrre un incidente operativo, non soltanto una risposta errata.

Google Cloud presenta già Agent Gateway come punto di controllo per le connessioni tra agenti e strumenti. Thales aggiunge ispezione, applicazione delle policy e rilevamento delle minacce attorno a tali connessioni. Ciò colloca la partnership sullo stesso terreno strategico di Microsoft, Zscaler, Palo Alto Networks e altri fornitori che cercano di definire il livello di sicurezza per gli agenti aziendali.

La domanda centrale non è più se gli agenti AI richiedano una protezione aggiuntiva. Le linee guida governative e la ricerca indipendente sulla sicurezza hanno chiarito questo punto. La vera domanda è se un livello runtime integrato possa vincolare gli agenti con coerenza senza renderli troppo lenti, costosi o limitati da non giustificarne l'implementazione.

Cosa cambia con l'integrazione di sicurezza AI Thales Google Cloud

La partnership avvicina la sicurezza degli agenti al momento in cui un sistema AI legge dati, sceglie uno strumento o tenta un'azione.

Secondo l'annuncio sulla sicurezza, Thales AI Security Fabric si integrerà con Google Cloud Gemini Enterprise. Thales afferma che il sistema combinato può applicare visibilità, governance e policy di sicurezza alle comunicazioni che coinvolgono utenti, agenti, modelli, strumenti e informazioni aziendali.

La copertura prevista comprende diverse fasi di un flusso di lavoro agentico. Il sistema può ispezionare il traffico in ingresso a un agente, osservare gli scambi tra l'agente e il suo modello e monitorare le chiamate a strumenti esterni. Mira inoltre ad applicare limiti alle informazioni a cui un agente può accedere e alle azioni che può eseguire.

Queste distinzioni contano perché un agente non è una singola sessione isolata di un modello. È una catena di decisioni, credenziali, fonti dati e interfacce software. Ogni passaggio crea un ulteriore punto in cui un aggressore, un errore di configurazione o una decisione inaffidabile del modello può alterare il risultato.

Thales identifica prompt injection, fuga di dati, output non sicuro, azioni non autorizzate e comunicazione tra agenti come rischi principali. La prompt injection si verifica quando istruzioni ostili incorporate nei contenuti manipolano il comportamento di un modello. Un'email, un documento, un sito web o la risposta di uno strumento possono contenere tali istruzioni senza che l'utente se ne accorga.

La risposta proposta dalla partnership è un livello di applicazione unificato. Thales afferma che la sua fabric può rilevare minacce specifiche dell'AI, mantenere visibilità sul comportamento degli agenti e bloccare azioni che violano le policy organizzative. L'azienda presenta inoltre i record centralizzati come supporto per le revisioni di conformità e le indagini sugli incidenti.

Si consideri l'esempio assicurativo fornito da Thales. Un agente autorizzato ad assistere nella liquidazione dei sinistri potrebbe attingere a informazioni personali da fonti non approvate. Anche se il calcolo del rimborso appare ragionevole, il flusso di lavoro può creare problemi di privacy, equità e conformità.

Un controllo runtime potrebbe esaminare la fonte dati richiesta, il ruolo assegnato all'agente e l'azione proposta prima di consentire la prosecuzione del flusso di lavoro. Potrebbe negare la richiesta, registrare il tentativo di accesso o richiedere l'approvazione umana. Si tratta di un modello di sicurezza diverso dal filtrare soltanto il prompt inviato da un utente.

L'integrazione si basa inoltre sulla più ampia architettura per agenti di Google Cloud. Il suo ecosistema Agent Gateway offre connettività governata nel traffico da utente ad agente, da agente ad agente e da agente a strumento. Google ha descritto il gateway come un punto di controllo aperto in grado di lavorare con diversi fornitori di sicurezza.

Thales non sta quindi sostituendo i controlli nativi di Google Cloud. Sta fornendo un livello specializzato di ispezione e applicazione all'interno di un'architettura più ampia. Il valore dipende dalla quantità di contesto aggiuntivo che può analizzare e dall'affidabilità con cui può intervenire prima che un'attività rischiosa raggiunga un sistema aziendale.

Perché gli agenti AI necessitano di controlli oltre le protezioni del modello

Una risposta sicura del modello non garantisce un flusso di lavoro sicuro quando il sistema può detenere credenziali e agire senza revisione umana immediata.

La sicurezza tradizionale dell'AI generativa si concentra spesso sui contenuti. Le organizzazioni cercano di prevenire risposte dannose, esposizione di dati riservati o prompt inappropriati. Queste preoccupazioni restano importanti, ma gli agenti introducono un'altra categoria di rischio: azioni software con conseguenze reali.

Un agente può ricevere un'istruzione, creare un piano, selezionare uno strumento ed eseguire una transazione. Potrebbe inviare un messaggio, modificare un record cliente, approvare un rimborso, cambiare codice sorgente o avviare una modifica dell'infrastruttura. Un errore può propagarsi prima che una persona veda il ragionamento intermedio.

Questa differenza spiega perché l'autorizzazione runtime sta diventando centrale. Una policy dovrebbe valutare non solo ciò che l'agente dice, ma anche quale identità utilizza, quale risorsa richiede e se quell'azione rientra nel compito assegnato. Potrebbe essere necessario prendere nuovamente la decisione ogni volta che il flusso di lavoro cambia direzione.

Il problema diventa più difficile quando gli agenti collaborano. Un agente potrebbe raccogliere informazioni mentre un altro formula una raccomandazione e un terzo esegue un'azione. Un componente compromesso può trasmettere contesto o richieste manipolati al resto della catena.

Thales afferma che i suoi controlli copriranno queste interazioni da agente ad agente. Questa promessa affronta un divario importante, ma i dettagli dell'implementazione ne determineranno il valore. I team di sicurezza devono sapere come vengono verificate le identità, come vengono rappresentate le autorizzazioni delegate e come le policy seguono un'attività attraverso più agenti.

NIST ha identificato lo stesso problema. La sua analisi sulla sicurezza degli agenti del maggio 2026 ha rilevato un ampio consenso sul fatto che gli agenti introducano minacce nuove. I partecipanti hanno inoltre affermato che le pratiche di cybersecurity consolidate restano utili, ma richiedono un adattamento ai sistemi agentici.

L'identità illustra tale adattamento. Un'applicazione convenzionale opera spesso tramite un account di servizio stabile con funzioni prevedibili. Un agente può assemblare dinamicamente un piano e scegliere tra vari strumenti in base a un contesto mutevole.

Assegnare a quell'agente credenziali estese lo rende utile, ma aumenta i danni derivanti dalla manipolazione. Limitare preventivamente ogni autorizzazione riduce il rischio, ma può impedire all'agente di completare un lavoro legittimo. I team di sicurezza devono bilanciare un'autonomia utile con un raggio d'impatto strettamente limitato.

I record di audit rappresentano un'altra sfida. Registrare una chiamata a uno strumento non basta se gli investigatori non riescono a determinare quale utente abbia avviato l'attività, quali informazioni abbiano influenzato l'agente o perché un'azione abbia ricevuto autorizzazione. Record utili devono collegare l'intento umano, l'identità dell'agente, l'accesso ai dati e la conseguente modifica del sistema.

L'approccio alla sicurezza AI Thales Google Cloud affronta questo problema tramite visibilità sull'intero flusso di lavoro. In linea di principio, un livello condiviso può correlare attività che altrimenti appaiono in log separati di modello, identità, API e applicazioni.

Questa visibilità può aiutare i team di operazioni di sicurezza a riconoscere comportamenti insoliti. Un agente che normalmente legge dati sulle vendite regionali dovrebbe attirare attenzione se improvvisamente richiede record dei dipendenti o un endpoint esterno non familiare. Il contesto comportamentale è prezioso quando le regole statiche non possono anticipare ogni sequenza valida.

Tuttavia, la visibilità non è contenimento. Una dashboard può spiegare un incidente dopo che il danno si è verificato. L'affermazione più forte è che le policy possano fermare l'azione non sicura in tempo reale, senza bloccare le variazioni legittime che rendono utili gli agenti.

L'applicazione runtime diventa il principale terreno di competizione

La competizione strategica è tra la sicurezza integrata in una piattaforma cloud e controlli indipendenti che promettono policy coerenti tra modelli, agenti e strumenti.

Google Cloud sta costruendo un ecosistema di partner attorno ad Agent Gateway invece di affidarsi a un unico fornitore di sicurezza. Tra i partecipanti pubblicati figurano Thales, Zscaler, Exabeam, Silverfort, Cisco, CrowdStrike, Palo Alto Networks e altri. Ogni fornitore affronta una parte diversa del flusso di lavoro degli agenti.

Thales porta in questa struttura la sicurezza di applicazioni e API di Imperva. La sua copertura dichiarata include il traffico da client ad agente, gli scambi da agente a modello e le interazioni con strumenti che utilizzano interfacce come Model Context Protocol. MCP è un protocollo che consente alle applicazioni AI di connettersi a dati esterni e funzionalità software.

Questo approccio offre flessibilità agli acquirenti aziendali. Un'azienda può utilizzare l'infrastruttura di Google e selezionare controlli aggiuntivi compatibili con le proprie operazioni di sicurezza esistenti. Può inoltre ridurre la pressione a dipendere interamente dalle protezioni fornite da un fornitore di modelli.

Il compromesso è la complessità. Diversi prodotti possono ispezionare lo stesso flusso di lavoro da prospettive diverse. I team di sicurezza devono decidere quale componente gestisca identità, protezione dei dati, analisi comportamentale, autorizzazione e risposta agli incidenti.

Controlli sovrapposti possono produrre lacune con la stessa facilità con cui aggiungono profondità. Un prodotto potrebbe approvare una richiesta in base all'identità dell'agente, mentre un altro non dispone del contesto dell'attività necessario per riconoscere un uso improprio. Un terzo potrebbe registrare la chiamata allo strumento senza comprendere i dati sensibili restituiti.

Microsoft sta perseguendo una strada più integrata verticalmente. La sua strategia di sicurezza per gli agenti collega identità, policy di accesso, governance dei dati e applicazioni di produttività. Microsoft Entra può assegnare identità agli agenti, mentre le policy Purview regolano le informazioni sensibili nell'ambiente Microsoft.

Questo modello offre un percorso amministrativo più chiaro per le organizzazioni già incentrate sui servizi Microsoft. Solleva inoltre le familiari preoccupazioni sulla dipendenza dalla piattaforma. I controlli ottimizzati per le applicazioni di un fornitore possono offrire una copertura meno coerente quando i flussi di lavoro attraversano cloud, modelli e strumenti di terze parti.

L'architettura basata sui partner di Google rende l'apertura parte della proposta. Tuttavia, l'apertura trasferisce il lavoro di integrazione alla piattaforma e ai suoi clienti. Una policy è utile solo se sopravvive a ogni passaggio e produce una decisione abbastanza rapidamente per il traffico di produzione.

I fornitori indipendenti affrontano una sfida correlata. Devono dimostrare che il loro livello aggiuntivo offre più di un'altra console di monitoraggio. Gli acquirenti si aspetteranno policy applicabili, indagini utilizzabili e prove che i controlli riducano il rischio senza interrompere il lavoro di routine.

Thales ha una posizione credibile perché Imperva opera già nell'ambito delle applicazioni web e delle API. I flussi di lavoro degli agenti utilizzano molte delle stesse interfacce. L'ispezione del traffico esistente, la gestione dei bot e la protezione delle API possono fornire una base per riconoscere i client e controllare le richieste.

Il comportamento degli agenti continua a differire dal traffico delle applicazioni convenzionali. Un agente valido può effettuare una richiesta API tecnicamente valida per uno scopo inaccettabile. Rilevare questa distinzione richiede contesto sull’intento dell’utente, l’autorità delegata, la sensibilità dei dati e la sequenza delle azioni precedenti.

È qui che la pressione competitiva va oltre la sicurezza web consolidata. I fornitori devono interpretare il contesto operativo di un agente senza dipendere dalla spiegazione dell’agente stesso. Un modello manipolato può produrre una motivazione convincente per una chiamata non sicura.

I provider cloud dispongono inoltre di un vantaggio informativo. Gestiscono il servizio del modello, il piano delle identità, la rete e la piattaforma degli agenti. Un partner deve ricevere telemetria sufficiente per prendere decisioni accurate, rispettando al contempo la privacy dei clienti e le prestazioni del sistema.

L’architettura più solida potrebbe quindi essere a livelli. I controlli nativi del cloud possono imporre identità e isolamento fondamentali, mentre prodotti specialistici ispezionano il comportamento dell’applicazione e il movimento dei dati sensibili. L’approvazione umana rimane appropriata per decisioni irreversibili o ad alto impatto.

Questa competizione non sarà decisa dall’elenco di funzionalità più lungo. Le imprese valuteranno quanto bene ciascuna architettura gestisce ambienti misti, identità delegate e contesto incompleto. Esamineranno inoltre se i responsabili della risposta agli incidenti possono ricostruire un flusso di lavoro senza dover assemblare diversi log incompatibili.

La promessa di sicurezza richiede ancora prove in produzione

Thales e Google Cloud descrivono i giusti punti di controllo, ma l’annuncio non dimostra con quale accuratezza o coerenza tali controlli operino sotto pressione avversaria.

Nell’annuncio, le aziende non hanno pubblicato numeri di implementazione, misurazioni della latenza, valutazioni indipendenti o tassi dettagliati di falsi positivi. Non identificano inoltre casi di studio di clienti che mostrino l’integrated fabric mentre blocca attacchi in produzione.

Questa assenza non invalida la direzione del prodotto. Limita ciò che si può concludere dal lancio. L’integrazione dovrebbe essere considerata un’architettura di sicurezza ampliata, non la prova che i flussi di lavoro agentici siano ora sicuri.

La prompt injection rimane un test impegnativo. I risultati di red teaming del NIST di marzo 2026 descrivono la prompt injection indiretta come dirottamento dell’agente. Gli aggressori inseriscono istruzioni ostili in contenuti esterni che un agente elaborerà successivamente.

Questi attacchi sfruttano un’ambiguità fondamentale. Un modello riceve sia istruzioni legittime sia informazioni non attendibili in forme testuali simili. Deve distinguere i dati da analizzare dai comandi da seguire, anche quando il contenuto malevolo è progettato per offuscare tale confine.

Le policy in fase di esecuzione possono ridurre il danno. Un’istruzione iniettata potrebbe convincere un agente a richiedere record riservati, ma un livello di autorizzazione separato può comunque negare la richiesta. Il controllo non deve necessariamente determinare con precisione perché il modello abbia preso la decisione errata.

Questa separazione è una delle idee più solide della partnership. Limiti deterministici sull’accesso ai dati e sull’uso degli strumenti possono contenere i fallimenti che le protezioni a livello di modello non rilevano. Credenziali con privilegi minimi e approvazioni umane possono ridurre ulteriormente l’impatto.

Tuttavia, il motore delle policy necessita di contesto accurato. Deve sapere quale utente ha autorizzato l’attività, quale scopo svolge l’agente e quali risorse sono necessarie. Policy ampie o mantenute in modo inadeguato possono trasformare un livello di controllo tecnicamente avanzato in un gateway permissivo.

I falsi positivi creano il fallimento opposto. Se un agente si ferma ripetutamente per ottenere approvazioni o perde l’accesso a dati di routine, i dipendenti potrebbero evitarlo. Gli amministratori potrebbero allentare le policy fino a quando l’applicazione non offrirà più una protezione significativa.

Anche la latenza conta. Ogni fase di ispezione aggiunge tempo di elaborazione. L’effetto può essere modesto per una singola interazione, ma significativo nei flussi di lavoro che contengono decine di richieste al modello e chiamate di strumenti. Le organizzazioni necessitano di misurazioni provenienti da implementazioni realistiche multi-agente.

Crittografia e privacy aggiungono un’altra tensione. Gli strumenti di sicurezza richiedono visibilità sufficiente per identificare informazioni sensibili e istruzioni malevole. I clienti vorranno spiegazioni chiare su quali contenuti vengano ispezionati, dove siano elaborati, per quanto tempo vengano conservati e chi possa accedervi.

Il problema va oltre un singolo prodotto. I rischi degli agenti di OWASP includono dirottamento degli obiettivi, uso improprio degli strumenti, abuso delle identità, avvelenamento della memoria, comunicazione insicura tra agenti e fallimenti a cascata. Nessun singolo filtro del traffico risolve ogni categoria.

L’avvelenamento della memoria è un esempio utile. Un aggressore potrebbe inserire informazioni false o malevole che un agente memorizza per un uso successivo. Un controllo in fase di esecuzione potrebbe ispezionare l’input originale, ma l’effetto dannoso potrebbe manifestarsi giorni dopo in un diverso flusso di lavoro.

I fallimenti a cascata sono altrettanto difficili. Un agente può generare un risultato errato che appare affidabile a un altro. Ogni singola chiamata di strumento può rispettare la policy, mentre il flusso di lavoro complessivo procede verso un esito dannoso.

Le organizzazioni necessitano quindi di una difesa in profondità. Dovrebbero combinare permessi limitati, sandboxing, identità firmate, memoria protetta, strumenti convalidati, monitoraggio continuo e revisione umana. I test di sicurezza devono coprire flussi di lavoro completi anziché risposte isolate del modello.

Le linee guida governative rafforzano questa posizione. Le linee guida australiane sull’adozione degli agenti raccomandano punti di controllo umani, monitoraggio continuo, permessi minimi e molteplici difese sovrapposte. Consigliano inoltre aumenti graduali dell’autonomia.

Thales AI Security Fabric può diventare una di queste difese. L’annuncio non giustifica il suo trattamento come intero programma di sicurezza. Gli acquirenti dovrebbero chiedere come interagisca con i sistemi di identità, i controlli di sviluppo, la risposta agli incidenti e le procedure di approvazione già in essere.

Chi subisce pressione mentre la sicurezza degli agenti entra nel flusso di lavoro

I fornitori di sicurezza, le piattaforme cloud e gli acquirenti enterprise subiscono ora pressione per trasformare la governance degli agenti da policy scritta a software applicabile.

I provider cloud affrontano l’aspettativa più immediata. Vogliono che i clienti spostino gli agenti dagli esperimenti alle operazioni aziendali, ma l’adozione si blocca quando i team legali e di sicurezza non riescono a definire confini accettabili. Una piattaforma che non riesce a rispondere a domande basilari su identità, accesso e verificabilità avrà difficoltà con le implementazioni sensibili.

La risposta di Google Cloud è costruire Agent Gateway come punto comune di applicazione e circondarlo di partner specializzati. Thales rafforza questa strategia coprendo le interazioni tra applicazioni, API, modelli e strumenti attraverso un’unica security fabric.

Thales deve dimostrare che questa portata più ampia rimane gestibile. La sua proposta di valore dipende dal fornire ai clienti una visione coerente attraverso diversi livelli tecnici. Policy frammentate o avvisi duplicati indebolirebbero il beneficio dell’integrazione.

I fornitori di sicurezza concorrenti affrontano la pressione di dimostrare una copertura altrettanto ampia. Proteggere solo i prompt non è più sufficiente. Gli acquirenti necessitano di controlli per credenziali, esecuzione degli strumenti, movimento dei dati, memoria, messaggi tra agenti e azioni esterne.

Anche i provider di identità affrontano un nuovo carico di lavoro. Gli agenti necessitano di identità distinte, permessi limitati, proprietà tracciabile e cicli di vita gestibili. Gli agenti temporanei non dovrebbero lasciare credenziali permanenti al termine delle loro attività.

I proprietari delle applicazioni hanno un ulteriore onere. Devono definire quali azioni un agente possa eseguire e a quali condizioni. I team di sicurezza non possono creare policy utili senza il contributo operativo delle persone che comprendono il flusso di lavoro.

Gli sviluppatori dovranno esporre un contesto più strutturato. Un livello di sicurezza può prendere decisioni migliori quando le chiamate degli strumenti dichiarano l’attività, l’utente, la risorsa richiesta e l’effetto previsto. I prompt non strutturati da soli forniscono una base debole per l’autorizzazione.

Gli acquirenti enterprise dovrebbero resistere alla tentazione di considerare l’approvvigionamento come la fine della governance. Installare una security fabric non determina un’autonomia accettabile. Le organizzazioni devono comunque classificare i casi d’uso, assegnare responsabili, definire punti di escalation e testare scenari di fallimento.

I casi d’uso a basso rischio offrono un punto di partenza sensato. Un agente che redige un report a partire da documenti interni approvati ha un raggio d’impatto minore rispetto a uno che invia messaggi o modifica account clienti. I permessi dovrebbero espandersi solo dopo che la valutazione dimostra che il flusso di lavoro rimane controllato.

Le azioni ad alto impatto meritano un’approvazione esplicita. Trasferimenti finanziari, modifiche alla produzione, comunicazioni legali, decisioni sul personale e divulgazione di dati sensibili non dovrebbero dipendere esclusivamente dalla fiducia di un modello. La revisione umana può rallentare il flusso di lavoro, ma tale attrito riflette la conseguenza dell’errore.

I knowledge worker dovrebbero interessarsene perché questi controlli modellano ciò che gli agenti sul posto di lavoro possono vedere e fare. Una sicurezza migliore può consentire agli agenti di raggiungere informazioni interne utili. Controlli progettati male possono invece esporre troppi dati o bloccare il contesto necessario per un lavoro accurato.

Anche i dipendenti necessiteranno di trasparenza. Dovrebbero sapere quando un agente agisce con la loro identità, quali record ha consultato e se i suoi output attivano modifiche esterne. L’automazione nascosta rende difficile l’attribuzione delle responsabilità quando si verifica un incidente.

Il cambiamento più ampio è organizzativo. La sicurezza dell’AI si sta spostando da un’attività di valutazione dei modelli alla gestione quotidiana delle identità e delle applicazioni. Ciò porta gli agenti sotto le stesse discipline operative usate per dipendenti, servizi, fornitori e distribuzioni software.

La partnership di sicurezza AI tra Thales e Google Cloud è importante perché rende esplicita questa transizione. Il suo successo dipenderà meno dall’annuncio che dalla capacità delle imprese di applicare i controlli senza creare un ulteriore livello di governance scollegato.

Tre segnali mostreranno se i controlli funzionano

Il prossimo test consiste in prove misurabili di implementazione, seguite da identità interoperabili e valutazioni avversarie credibili.

Il primo segnale è l’adozione in produzione con risultati divulgati. Thales o Google Cloud dovrebbero pubblicare esempi di clienti che spieghino il flusso di lavoro, i permessi, il comportamento bloccato e l’onere operativo. Le prove utili includerebbero accuratezza di rilevamento, frequenza delle approvazioni, latenza e risultati della risposta agli incidenti.

Una dichiarazione vaga secondo cui un cliente ha implementato agenti sicuri rivelerebbe poco. Il caso di studio più solido mostrerebbe come un controllo abbia bloccato una prompt injection realistica o una chiamata di strumento non autorizzata. Dovrebbe inoltre spiegare con quale frequenza l’attività legittima sia stata interrotta.

Se emergeranno queste prove, rafforzeranno l’affermazione che l’applicazione delle policy in fase di esecuzione può supportare implementazioni pratiche degli agenti. Se i clienti rimarranno anonimi e le misurazioni private, gli acquirenti dovrebbero considerare l’integrazione promettente ma non dimostrata.

Il secondo segnale è un’identità e un’autorizzazione più solide tra le piattaforme. Il NIST ha già evidenziato questioni riguardanti identificazione degli agenti, delega, audit e non ripudio. Il mercato necessita di modalità coerenti per dimostrare quale agente stia agendo, per conto di chi e con quale autorità.

L’interoperabilità sarà importante perché i flussi di lavoro enterprise raramente restano all’interno dell’ambiente di un unico fornitore. Un agente potrebbe usare un modello Google, interrogare un database di terze parti, chiamare un’applicazione Microsoft e invocare uno strumento sviluppato internamente.

Le policy devono accompagnare quel flusso di lavoro senza concedere a una credenziale riutilizzabile un accesso ampio. Un’autorizzazione di breve durata legata a un’attività specifica ridurrebbe il rischio. Record verificabili dovrebbero collegare ogni azione rilevante sia all’agente sia all’essere umano o servizio responsabile.

I progressi negli standard aperti per l’identità rafforzerebbero la strategia di partnership di Google Cloud. Una frammentazione persistente favorirebbe piattaforme strettamente integrate che controllano una porzione più ampia dello stack tecnologico.

Il terzo segnale è rappresentato dai test avversariali indipendenti. Thales e Google Cloud dovrebbero testare il sistema combinato contro prompt injection indirette, output di strumenti malevoli, abuso di credenziali, avvelenamento della memoria e agenti compromessi. Le valutazioni dovrebbero misurare il contenimento, non solo il rilevamento di un attacco.

Un test utile dovrebbe presupporre che il modello fallisca. Dovrebbe poi chiedersi se i controlli esterni impediscono l’esfiltrazione dei dati o una modifica non autorizzata del sistema. Questo distingue le affermazioni sulla sicurezza del modello dal valore pratico per la sicurezza offerto dall’architettura circostante.

Ricercatori indipendenti dovrebbero inoltre esaminare gli aggiramenti creati dai flussi di lavoro multi-agente. Una policy può bloccare una richiesta diretta, consentendo però diverse azioni singolarmente accettabili che producono lo stesso risultato vietato.

Il lancio arriva al momento giusto. Le aziende vogliono che gli agenti facciano più che riassumere informazioni, mentre autorità di regolamentazione e team di sicurezza richiedono una responsabilità più chiara. Queste pressioni rendono il controllo in fase di esecuzione un requisito anziché una funzionalità opzionale.

Tuttavia, l’onere della prova cresce con l’autonomia. Maggiore è l’autorità ricevuta da un agente, maggiori sono le evidenze di cui gli acquirenti hanno bisogno per dimostrare che identità, autorizzazioni, policy e registri di audit funzionano insieme sotto attacco.

Le organizzazioni che valutano l’integrazione per la sicurezza dell’AI tra Thales e Google Cloud dovrebbero iniziare con un flusso di lavoro circoscritto e un budget di errore definito. Mappate ogni strumento, credenziale, fonte di dati e azione irreversibile. Quindi verificate se i controlli bloccano gli abusi senza sommergere gli utenti di approvazioni.

La domanda decisiva è pratica: la partnership può trasformare l’ampia capacità di un agente in un’azione strettamente autorizzata ogni volta che il flusso di lavoro cambia? Le misurazioni in produzione, le identità interoperabili e i test indipendenti forniranno la risposta.