Proteggere l'azienda agentica su Google Cloud

Le principali preoccupazioni citate dalle aziende sono l'esposizione dei dati sensibili al 52% e la conformità legale al 50% (Fonte: Cloud Security Alliance, dicembre 2025). Tuttavia, la transizione aziendale verso l'AI agentica autonoma introduce nuovi vettori critici:

• Il tempo medio per sfruttare le vulnerabilità è sceso a meno sette giorni, il che significa che gli zero-day vengono regolarmente sfruttati prima della pubblicazione delle patch software (fonte: report sulle tendenze M-Trends di Mandiant)
• Le identità dei workload non umani ora superano le identità umane di 82 volte nei moderni ambienti cloud (Fonte: Google Cloud NEXT 2026)
• Il 42% degli agenti AI aziendali attivi attualmente dispone di privilegi sensibili e troppo permissivi (Fonte: Google Cloud NEXT 2026)
• Per difendersi da questi attacchi alla velocità delle macchine, è necessario proteggere contemporaneamente l'intero stack AI: infrastruttura, dati, modelli e agenti autonomi

La Shadow AI si verifica quando gli sviluppatori o le unità aziendali eseguono il deployment di modelli non autorizzati, API esterne o skill di agenti di terze parti senza la revisione dell'IT:

• Oltre il 15% delle competenze degli agenti disponibili nei marketplace pubblici è noto per essere dannoso (Fonte: Google Cloud NEXT 2026)
• Il 68% delle organizzazioni esegue modelli self-hosted integrati in profondità nel software di terze parti, spesso senza rendersene conto (Fonte: Wiz, State of AI in the Cloud 2026)
• Per rilevare la shadow AI, le organizzazioni utilizzano Wiz AI-APP, che si connette tramite API in 15 minuti per generare una distinta base AI (AI-BOM) dinamica, abbinata a Gemini, che fornisce un Agent Registry centralizzato per catalogare e gestire tutti gli agenti attivi, i server MCP personalizzati e gli strumenti esterni

No. Sebbene la carenza di competenze sia una sfida riconosciuta, le organizzazioni con una governance formale dell'AI hanno 3 volte più probabilità di formare il personale sugli strumenti di sicurezza dell'AI(Fonte: Cloud Security Alliance, dicembre 2025) e i team di sicurezza ora guidano la protezione dell'AI nel 53% delle organizzazioni (Fonte: Cloud Security Alliance, dicembre 2025). Google Cloud sposta la sicurezza direttamente nella struttura della piattaforma: le configurazioni di base sono automatizzate tramite Enterprise Foundations Blueprint, le interazioni di runtime sono gestite in modo nativo da Model Armor e gli agenti autonomi di ricerca e correzione come CodeMender e Wiz Green Agent testano e generano patch di codice idiomatiche direttamente nei workflow degli sviluppatori.

Per proteggere gli agenti autonomi è necessario andare oltre i service account statici. Poiché le identità non umane superano quelle umane di 82 volte e il 42% degli agenti attivi possiede privilegi eccessivamente permissivi (fonte: Google Cloud NEXT 2026), Google Cloud stabilisce uno stack di sicurezza incentrato sull'identità:

• Identità dell'agente: un tipo di entità dedicato e di prima classe, distinto dagli utenti umani, che fornisce credenziali di runtime crittografiche, fortemente attestate e legate al ciclo di vita
• Controlli con privilegio minimo: le funzionalità sono limitate utilizzando Privileged Access Manager (PAM) per l'accesso just-in-time (JIT), eliminando i privilegi permanenti
• Confine di accesso dell'entità (PAB): impone confini di risorse rigidi e protettivi per limitare il raggio d'azione massimo delle identità degli agenti in esecuzione

Il Secure AI Framework (SAIF) è l'architettura concettuale di Google per un'implementazione sicura e responsabile dell'AI. Traduce i principi di sicurezza Zero Trust nei sistemi di AI imponendo la provenienza della build SLSA di livello 3 convalidata tramite Autorizzazione binaria, controlli automatizzati di policy-as-code in Cloud Build e rilevamento continuo delle minacce. Negli ambienti agentici, il SAIF si rende operativo attraverso il ciclo di vita in 4 fasi: Architect, Inventory, Intercept e Defend (Fonte: Secure AI Innovation eBook, Capitolo 6)

Il Model Context Protocol (MCP) è uno standard aperto che consente agli agenti AI autonomi di connettersi a origini dati esterne, strumenti aziendali e API aziendali. Tuttavia, le integrazioni MCP personalizzate non gestite introducono in produzione endpoint rischiosi e non controllati. Google Cloud protegge gli strumenti agentici tramite i server MCP gestiti da Google Cloud (come il server MCP per BigQuery). In questo modo, si standardizza l'interazione degli agenti con i database aziendali, applicando autorizzazioni IAM rigorosamente definite e verificabili e sostituendo i wrapper API personalizzati con connessioni rafforzate e gestite dall'azienda (Fonte: Google Cloud NEXT 2026).

La perdita di sessione si verifica in ambienti multi-tenant o multi-agente quando il contesto di una conversazione privata, i token utente o i dati aziendali sensibili della sessione di un utente vengono involontariamente divulgati in quella di un altro. Google Cloud elimina il session bleeding tramite l'Agent Development Kit (ADK) (Fonte: Secure AI Innovation eBook, Capitolo 2):

• Isolamento dei tenant: l'ADK applica limiti rigorosi per gli utenti e l'isolamento dell'esecuzione utilizzando le primitive native session_id e user_id
• Segregazione delle credenziali: i token di autenticazione downstream sono isolati in modo che un agente non possa trasferire le credenziali o lo stato della conversazione tra sessioni utente distinte

Sì. Le organizzazioni perseguono strategie multi-modello eseguendo in media 2,6 modelli diversi(Fonte: Cloud Security Alliance, dicembre 2025). Google Cloud supporta la governance multi-modello utilizzando Gemini come control plane di esecuzione centralizzato. I vincoli di runtime unificati, tra cui Model Armor per la sanificazione dei prompt e le norme di governance semantica, si applicano in modo coerente ai modelli Gemini proprietari, ai modelli open source e ai modelli di terze parti. Per i patrimoni multi-cloud (tra cui AWS Bedrock, Databricks e open source non gestito), il Wiz Security Graph mappa le vulnerabilità e i percorsi di attacco tra tutti i provider cloud (Fonte: Google Cloud NEXT 2026).

No. CodeMender è progettato con un'architettura di esecuzione locale incentrata sulla privacy (Fonte: Secure AI Innovation eBook, Capitolo 4):

• Elaborazione CLI locale: il motore di scansione di CodeMender opera tramite un'interfaccia a riga di comando locale direttamente all'interno dell'ambiente sicuro dello sviluppatore
• Sandboxing isolato: le build delle applicazioni e le verifiche degli exploit attivi vengono eseguite all'interno di una sandbox isolata sulla tua infrastruttura.
• Zero addestramento dei modelli: il tuo codice sorgente proprietario e la tua proprietà intellettuale rimangono rigorosamente protetti e non vengono mai utilizzati per addestrare i foundation model di Google. Gli sviluppatori mantengono il controllo completo attraverso i workflow IDE/CLI standard e i controlli di approvazione human-in-the-loop (HITL) prima che venga eseguito il merge di qualsiasi patch di codice

Per eseguire una logica di business ad alto rischio senza esporre l'infrastruttura di base, le aziende utilizzano l'architettura di riferimento Bring Your Own Container (BYOC):

• Sandboxing dei container: gli agenti autonomi ad alto rischio (come i collegamenti di inventario o logistica) vengono distribuiti in container isolati su Cloud Run
• Separazione rigorosa delle autorizzazioni: le autorizzazioni dell'infrastruttura al momento del deployment sono rigorosamente separate dalle autorizzazioni di esecuzione del runtime
• Gate human-in-the-loop (HITL): l'Agent Development Kit (ADK) introduce momenti di pausa programmati in cui le azioni ad alto rischio (come l'avvio di API di evasione o esborsi finanziari) richiedono l'approvazione esplicita di una persona prima dell'esecuzione

Google Cloud applica una soluzione di runtime con doppio guardrail per sanificare i payload senza aggiungere latenza dell'annuncio:

1. Controllo dell'accesso (confini IAM): applicato in modo nativo su Agent Gateway utilizzando Identity-Aware Proxy (IAP) per verificare crittograficamente gli ID digitali del chiamante prima di instradare le connessioni
2. Controllo dell'intent (confini semantici): Model Armor opera come un proxy in linea che esamina le interazioni di utenti, agenti e modelli in tempo reale per neutralizzare i prompt injection, prevenire i jailbreak e oscurare le PII sensibili. A livello di applicazione, l'Agent Development Kit (ADK) applica la convalida dell'input (come BeforeToolCallback) per bloccare le SQL injection indirette contro le tabelle BigQuery

La prevenzione della fuga di dati richiede una difesa in profondità a livello di rete, applicazione e modello:

• Topologie private: i workload di AI vengono eseguiti su VPC condivisi gestiti centralmente e isolati dai Controlli di servizio VPC (VPC-SC), creando un macroperimetro attorno all'intero ecosistema di agenti
• Sanitizzazione in linea: Model Armor pulisce e oscura automaticamente i dati sensibili dei clienti e le PII dagli input dei prompt e dagli output dei modelli
• Autenticazione senza token: il gestore di autenticazione di Agent Identity gestisce handshake OAuth complessi a valle per conto degli utenti, passando i token in modo sicuro senza esporre le credenziali non elaborate all'agente
• Confidential Computing: protegge i dati in uso criptando la memoria durante l'elaborazione del modello attivo