Best practice per proteggere le interazioni degli agenti con Model Context Protocol

Anteprima

Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini di servizio generali dei Termini di servizio specifici. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per ulteriori informazioni, consulta le descrizioni delle fasi di lancio.

Il Model Context Protocol (MCP) standardizza il modo in cui gli agenti di AI generativa si connettono a Bigtable. A causa dei rischi intrinseci degli agenti autonomi, la mitigazione delle vulnerabilità come l'iniezione di prompt richiede un modello di responsabilità condivisa, che combini i controlli della piattaforma con la progettazione di applicazioni sicure.
Per progettare e implementare applicazioni AI che utilizzano gli strumenti Google Cloud Model Context Protocol (MCP), segui le best practice descritte in questa guida.

Prima di iniziare

Quando utilizzi gli strumenti MCP, la security posture della tua applicazione dipende dal modello di interazione dell'agente. Per scoprire in che modo l'utilizzo degli agenti influisce sui rischi per la sicurezza associati all'integrazione degli agenti con un server MCP, consulta Sicurezza e protezione dell'AI.

Responsabilità in materia di sicurezza

Come cliente, sei responsabile della configurazione e del funzionamento sicuri della tua piattaforma di agenti.

Seguire il principio del privilegio minimo

Esegui l'agente con un account di servizio con ambito minimo. Questo è il primo e più importante livello di difesa.

• Identità dedicata:crea un account di servizio separato e dedicato per ogni agente o applicazione unici utilizzando gli strumenti MCP. Non riutilizzare gli SA esistenti, soprattutto quelli con autorizzazioni generali.
• Ambiti minimi:concedi all'account di servizio solo i ruoli Identity and Access Management (IAM) necessari, ad esempio alloydb.viewer, non alloydb.admin. Se l'agente ha bisogno solo dell'accesso in lettura a un set di dati specifico, utilizza ruoli IAM personalizzati per limitare l'accesso al minimo indispensabile per la sua funzione.
• Separazione dei compiti: se un agente ha bisogno sia dell'accesso in lettura ai dati sia dell'accesso in scrittura a un log o a uno spazio di archiviazione temporaneo, utilizza due service account separati: uno per l'accesso ai dati ad alto rischio (con ambito minimo) e uno per le attività operative a basso rischio.

Utilizzare controlli granulari nativi del database

Per una difesa più efficace, combina i ruoli IAM con i controlli di accesso granulari offerti dal database stesso. In questo modo, anche se un malintenzionato compromette il token IAM dell'agente, l'entità del danno è limitata dalle autorizzazioni interne del motore del database, ad esempio impedendo un DROP TABLE

Prodotto	Meccanismo di controllo granulare	Focus
Cloud SQL e AlloyDB	Ruoli a livello di database come CREATE ROLE in PostgreSQL e MySQL.	Gestisci le autorizzazioni in un'istanza di database e schemi specifici.
BigQuery	Controllo dell'accesso a livello di colonna (utilizzando i tag criterio)	Limita l'accesso dell'agente a colonne sensibili, ad esempio PII, anche in una tabella autorizzata.
Spanner	Controllo dell'accesso granulare (ruoli di database con GRANT/REVOKE)	Applica autorizzazioni di lettura/scrittura/aggiornamento precise su tabelle e colonne.
Firestore	Regole di sicurezza di Firestore	Limita l'accesso a livello di documento o di campo in base alla logica dell'applicazione o al contesto dell'utente richiedente.
Bigtable	Ruoli IAM	Bigtable offre un controllo granulare tramite i ruoli IAM a livello di progetto, istanza e tabella.

Progettazione di agenti sicuri

I modelli solo con agenti richiedono difese robuste a livello di applicazione contro gli attacchi di prompt injection, che tentano di ignorare il prompt di sistema. Per saperne di più, consulta Sicurezza e protezione dell'AI.

Considera i dati e gli input degli utenti come non attendibili

Considera come non attendibili l'input degli utenti finali o i dati recuperati dall'agente da fonti esterne, come un risultato di ricerca web o un documento di terze parti.

Implementare pattern di selezione delle azioni

Evita architetture pianifica ed esegui aperte, in cui il sistema disaccoppia la specifica delle attività di alto livello dall'esecuzione meccanica. Utilizza invece pattern di progettazione che limitano la libertà del modello.

• Pattern di selezione dell'azione: l'unico compito del modello è quello di tradurre una richiesta dell'utente in una delle funzioni sicure di un piccolo insieme predefinito. La logica dell'azione è hardcoded e non può essere modificata dal LLM. In questo modo, l'agente è immune agli attacchi di iniezione che hanno come target il flusso di controllo.
• Pattern Dual-LLM:utilizza un LLM principale (il LLM di azione) che esegue l'attività principale e un LLM secondario altamente sicuro (il LLM di protezione) che esamina in anteprima il prompt dell'utente per rilevare intenti dannosi e in post-produzione l'output del LLM di azione per rilevare azioni non autorizzate o perdite di dati.

Impedire il concatenamento non autorizzato di strumenti

Gli agenti devono chiamare solo gli strumenti necessari per l'attività. Assicurati che il codice di orchestrazione impedisca quanto segue:

• Strumenti dinamici:l'agente non deve essere in grado di registrare dinamicamente nuovi strumenti o modificare le autorizzazioni degli strumenti esistenti.
• Applicazione della lista consentita:dichiara una lista consentita di funzioni o tabelle di database a cui l'agente può accedere nel prompt di sistema iniziale e nel codice di backend. Per un esempio di Gemini CLI, vedi Limitare l'accesso agli strumenti.

Configurazioni di sicurezza

Bigtable fornisce Model Armor per applicare i limiti di sicurezza a livello di piattaforma. Devi attivare e configurare queste impostazioni.

Abilita Model Armor

Utilizza Google Cloud CLI per attivare Model Armor nel deployment del modello. In questo modo, viene attivata la protezione integrata contro i vettori di attacco noti come l'iniezione e il jailbreaking.

L'esempio seguente abilita Model Armor su un endpoint Vertex AI.

# Example: Enable Model Armor on a Vertex AI endpoint
gcloud ai endpoints update ENDPOINT_ID \
    --region=REGION \
    --enable-model-armor

Per ulteriori informazioni ed esempi, consulta Configurare la protezione Model Armor per MCP su Google Cloud.

Applica soglie di sicurezza minime per le operazioni sui dati sensibili

Model Armor ti consente di applicare una soglia di sicurezza minima per le operazioni sui dati sensibili, ad esempio il rilevamento e la deidentificazione delle informazioni che consentono l'identificazione personale (PII). Utilizza la protezione dei dati sensibili DeidentifyTemplate per oscurare o mascherare le informazioni sensibili prima che vengano restituite all'utente, anche se il modello è compromesso.

Di seguito è riportato un esempio concettuale per la configurazione:

  # Example: Apply a DeidentifyTemplate to filter PII
gcloud ai endpoints update ENDPOINT_ID \
    --region=REGION \
    --model-armor-config-file=model_armor_config.json

Nell'esempio seguente, model_armor_config.json potrebbe fare riferimento a un modello DLP:

{
  "safety_thresholds": {
    "injection": "HIGH",
    "harmful_content": "MEDIUM"
  },
  "data_protection_config": {
    "dlp_deidentify_template": "projects/PROJECT_NUMBER/locations/LOCATION/deidentifyTemplates/DLP_TEMPLATE_ID"
  }
}

Controllo e osservabilità

La visibilità delle azioni degli agenti è fondamentale per l'analisi post-incidente e il rilevamento degli agenti compromessi.

Implementare una strategia di recupero dei dati

Sebbene i controlli a più livelli come IAM e i ruoli nativi del database siano progettati per prevenire azioni distruttive, devi disporre di un piano di ripristino nel caso in cui queste difese non funzionino. Un agente compromesso o ingenuo con autorizzazioni di scrittura (un rischio "Solo agente") potrebbe essere indotto a eseguire un comando distruttivo come DROP TABLE o a danneggiare i dati.

La tua difesa principale contro questo scenario è una strategia di recupero robusta.

Quasi tutti i prodotti Data Cloud forniscono funzionalità per il recupero dei dati, tramite backup tradizionali, recupero point-in-time (PITR) o snapshot dei dati. Sei responsabile dell'attivazione e della configurazione di queste funzionalità.

Prodotto	Meccanismi di backup e ripristino
Cloud SQL	Supporta sia i backup on demand sia quelli automatici, consentendoti di ripristinare un'istanza a uno stato precedente. Supporta anche il recupero point-in-time (PITR).
AlloyDB	Fornisce backup e ripristino continui per impostazione predefinita. In questo modo viene attivato PITR con una granularità di microsecondi, il che ti consente di ripristinare un cluster in qualsiasi momento della finestra di conservazione.
BigQuery	Il recupero dei dati viene eseguito utilizzando "Time Travel", che consente di accedere e ripristinare i dati da qualsiasi momento degli ultimi 7 giorni. Per la conservazione a lungo termine, puoi creare snapshot delle tabelle.
Spanner	Supporta sia i backup on demand sia il recupero temporizzato.
Firestore	Supporta esportazioni/importazioni gestite come backup. Offre anche il recupero point-in-time (PITR), disabilitato per impostazione predefinita, per proteggere da eliminazioni o scritture accidentali.
Bigtable	Supporta i backup on demand e automatici. Questi backup sono completamente gestiti e possono essere ripristinati in una nuova tabella.

Abilita Cloud Audit Logs

Assicurati che i log di controllo dell'accesso ai dati siano abilitati per MCP e per tutti i Google Cloud servizi pertinenti come BigQuery, Cloud SQL, AlloyDB e Spanner. Per impostazione predefinita, sono abilitati solo gli audit log Attività di amministrazione. Gli audit log di accesso ai dati registrano ogni operazione di lettura e scrittura eseguita dall'agente. Per saperne di più, consulta Audit log di accesso ai dati per MCP.

Controllare le azioni sensibili

Configura avvisi in Cloud Logging per rilevare azioni anomale o ad alto rischio. La query di Esplora log identifica i service account che eseguono operazioni di scrittura dei dati in Firestore, ad esempio, che è un obiettivo comune per l'esfiltrazione o gli attacchi distruttivi:

resource.type="firestore_database"
# Filter for data write operations
AND protoPayload.methodName="google.firestore.v1.Firestore.Commit"
# Ensure the caller is an agent service account (modify regex as needed)
AND protoPayload.authenticationInfo.principalEmail=~".*@.*.gserviceaccount.com"
# Exclude expected system calls to reduce noise
AND NOT protoPayload.authenticationInfo.principalEmail=~"system-managed-service-account"

Utilizzare il logging specifico dell'agente

Oltre a Cloud Audit Logs, assicurati che il codice dell'applicazione registri i seguenti dati per ogni decisione dell'agente:

• Esecuzione dello strumento:lo strumento MCP chiamato.
• Comando non elaborato:il comando esatto, ad esempio una query SQL o il percorso del documento, generato dal modello LLM.
• Azione finale:indica se l'azione viene eseguita (modello Solo agente) o approvata (Human-in-the-Middle). Per saperne di più, consulta Informazioni sull'utilizzo dell'agente.
• ID utente e sessione: l'identificatore dell'utente finale che ha avviato la richiesta.