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

Model Context Protocol (MCP) standardizza il modo in cui gli agenti di AI generativa si connettono a Firestore. A causa dei rischi intrinseci degli agenti autonomi, la mitigazione delle vulnerabilità come la prompt injection richiede un modello di responsabilità condivisa, che combini i controlli della piattaforma con una progettazione di applicazioni sicura.
Per progettare ed eseguire il deployment di 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 postura di sicurezza 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

In qualità di cliente, sei responsabile della configurazione e del funzionamento sicuri della piattaforma dell'agente.

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 univoca che utilizza gli strumenti MCP. Non riutilizzare i service account esistenti, soprattutto quelli con autorizzazioni ampie.
Ambiti minimi: concedi al 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 i ruoli IAM personalizzati per limitare l'accesso al minimo assoluto necessario 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: un account 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 attaccante compromette il token IAM dell'agente, l'ambito dei danni è limitato dalle autorizzazioni interne del motore del database, ad esempio impedendo l'esecuzione di un comando Elimina database.

Prodotto	Meccanismo di controllo granulare	Obiettivo
Cloud SQL e AlloyDB	Ruoli a livello di database come CREATE ROLE in PostgreSQL e MySQL.	Gestisci le autorizzazioni in un'istanza e negli schemi di database specifici.
BigQuery	Controllo dell'accesso a livello di colonna (utilizzando i tag di policy)	Limita l'accesso dell'agente alle colonne sensibili, ad esempio le 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	Ruoli e condizioni IAM	Configura le autorizzazioni di accesso per database utilizzando i ruoli e le condizioni IAM.
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 agenti richiedono solide difese a livello di applicazione contro gli attacchi di injection di prompt, che tentano di sostituire il prompt di sistema. Per ulteriori informazioni, consulta Sicurezza e protezione dell'AI.

Considerare i dati e gli input degli utenti come non attendibili

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

Implementare pattern di selezione delle azioni

Evita le architetture pianifica ed esegui a tempo indeterminato, 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 delle azioni: l'unico compito del modello è tradurre una richiesta dell'utente in una di un piccolo insieme predefinito di funzioni sicure. La logica delle azioni è hardcoded e non può essere modificata dall'LLM. In questo modo, l'agente è immune agli attacchi di injection che prendono di mira il flusso di controllo.
Pattern a doppio LLM: utilizza un LLM principale (l'LLM di azione) che esegue l'attività principale e un LLM secondario altamente sicuro (l'LLM di protezione) che esegue la pre-analisi del prompt dell'utente per rilevare intenti dannosi e la post-analisi dell'output dell'LLM di azione per rilevare azioni o perdite di dati non autorizzate.

Impedire l'incatenamento di strumenti non autorizzato

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 backend. Per un esempio di Gemini CLI, consulta Limitare l'accesso agli strumenti.

Limitare l'accesso ai dati nei database multi-tenant

Uno strumento generico come execute_sql consente al chiamante di eseguire query di database che possono leggere tutti i dati a cui le autorizzazioni IAM e del database consentono l'accesso. Quando crei un agente che accede ai dati in un'applicazione multi-tenant senza un human-in-the-loop attendibile, potresti dover limitare ulteriormente l'accesso ai dati.

Per assicurarti che l'agente possa leggere solo sottoinsiemi dei dati a cui ha accesso, ti consigliamo di creare strumenti personalizzati utilizzando un framework come MCP Toolbox per database. Per ulteriori informazioni, consulta Strumenti predefiniti e personalizzati.

Ad esempio, supponiamo che il database memorizzi gli ordini di tutti gli utenti finali nella tabella Orders. Stai sviluppando un agente di chat che interagisce con gli utenti e può cercare i loro ordini. L'agente di chat ha l'autorizzazione per leggere l'intera tabella Orders, ma un utente finale non deve essere in grado di richiedere informazioni sugli ordini di un altro utente.

In uno scenario non sicuro, fornisci all'agente solo uno strumento execute_sql, creando un rischio di fuga di dati. Un utente malintenzionato può indurre l'agente a leggere e restituire gli ordini di altri utenti. In genere, non è sufficiente istruire l'agente ad applicare le regole di accesso per proteggere i dati.

In uno scenario sicuro, fornisci all'agente uno strumento personalizzato più specifico, ad esempio lookup_active_order, in cui l'identità dell'utente nel filtro della query è impostata al di fuori del controllo dell'agente.

Configurazioni di sicurezza e protezione

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

Abilitare Model Armor

Utilizza Google Cloud CLI per abilitare Model Armor nel deployment del modello. In questo modo, viene attivata la protezione integrata contro i vettori di attacco noti, come l'injection 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.

Applicare soglie di sicurezza minime per le operazioni sui dati sensibili

Model Armor consente di applicare una soglia di sicurezza minima per le operazioni sui dati sensibili, ad esempio il rilevamento e l'anonimizzazione delle informazioni che consentono l'identificazione personale (PII). Utilizza un Sensitive Data Protection 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 di 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 dell'agente è 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 i ruoli IAM e quelli nativi del database siano progettati per impedire azioni distruttive, devi avere un piano di recupero 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 Elimina database o a danneggiare i dati.

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

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'abilitazione e della configurazione di queste funzionalità.

Prodotto	Meccanismi di backup e recupero
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 recupero continui per impostazione predefinita. In questo modo è possibile eseguire il PITR con una granularità di microsecondi, consentendoti 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 punto degli ultimi 7 giorni. Per la conservazione a lungo termine, puoi creare snapshot delle tabelle.
Spanner	Supporta sia i backup on demand sia il PITR.
Firestore	Supporta i backup automatici che consentono di ripristinare un database a uno stato precedente. Offre anche il PITR per proteggere da eliminazioni o scritture accidentali. Entrambe queste funzionalità sono disattivate per impostazione predefinita.
Bigtable	Supporta i backup on demand e automatici. Questi backup sono completamente gestiti e possono essere ripristinati in una nuova tabella.

Abilitare Cloud Audit Logs

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

Eseguire l'audit delle azioni sensibili

Configura gli 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 target 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 la registrazione specifica 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 Firestore o un percorso del documento, generato dall'LLM.
Azione finale: indica se l'azione viene eseguita (modello solo agente) o approvata (uomo nel mezzo). Per ulteriori informazioni, consulta Informazioni sull'utilizzo degli agenti.
ID utente e sessione: l'identificatore dell'utente finale che ha avviato la richiesta.