Best Practices für die Sicherung von Agent-Interaktionen mit dem Model Context Protocol

Das Model Context Protocol (MCP) standardisiert, wie generative KI-Agenten eine Verbindung zu Spanner herstellen. Aufgrund der inhärenten Risiken autonomer Agenten erfordert die Minimierung von Sicherheitslücken wie Prompt-Injection ein Modell der geteilten Verantwortung, das Plattformkontrollen mit einem sicheren Anwendungsdesign kombiniert.
Wenn Sie KI-Anwendungen entwerfen und bereitstellen möchten, die Google Cloud Model Context Protocol (MCP)-Tools verwenden, folgen Sie den Best Practices in diesem Leitfaden.

Hinweis

Wenn Sie MCP-Tools verwenden, hängt der Sicherheitsstatus Ihrer Anwendung vom Interaktionsmodell des Agenten ab. Informationen dazu, wie sich die Verwendung von Agenten auf die Sicherheitsrisiken auswirkt, die mit der Integration von Agenten in einen MCP-Server verbunden sind, finden Sie unter KI-Sicherheit.

Sicherheitsverantwortlichkeiten

Als Kunde sind Sie für die sichere Konfiguration und den sicheren Betrieb Ihrer Agentenplattform verantwortlich.

Folgen Sie dem Prinzip der geringsten Berechtigung.

Führen Sie Ihren Agenten mit einem Dienstkonto mit minimalem Umfang aus. Dies ist die erste und wichtigste Verteidigungsebene.

  • Dedizierte Identität:Erstellen Sie für jeden einzelnen Agenten oder jede Anwendung, die MCP-Tools verwendet, ein separates, dediziertes Dienstkonto. Verwenden Sie keine vorhandenen Dienstkonten wieder, insbesondere nicht solche mit umfassenden Berechtigungen.
  • Minimale Zugriffsbereiche:Gewähren Sie dem Dienstkonto nur die erforderlichen IAM-Rollen (Identity and Access Management), z. B. alloydb.viewer und nicht alloydb.admin. Wenn der Agent nur Lesezugriff auf ein bestimmtes Dataset benötigt, verwenden Sie benutzerdefinierte IAM-Rollen, um den Zugriff auf das absolute Minimum zu beschränken, das für seine Funktion erforderlich ist.
  • Aufgabentrennung : Wenn ein Agent sowohl Lesezugriff auf Daten als auch Schreibzugriff auf ein Log oder einen temporären Speicher benötigt, verwenden Sie zwei separate Dienstkonten: ein Konto für den risikoreichen Datenzugriff (mit minimalem Umfang) und eines für operative Aufgaben mit geringem Risiko.

Detaillierte native Datenbanksteuerungen verwenden

Für den bestmöglichen Schutz kombinieren Sie IAM-Rollen mit den detaillierten Zugriffssteuerungen, die von der Datenbank selbst angeboten werden. So wird sichergestellt, dass selbst wenn ein Angreifer das IAM-Token des Agenten kompromittiert, der Umfang des Schadens durch die internen Berechtigungen der Datenbank-Engine begrenzt wird, z. B. durch das Verhindern eines DROP TABLE-Befehls.


Produkt
Detaillierter Steuerungsmechanismus
Fokus

Cloud SQL und AlloyDB
Rollen auf Datenbankebene wie CREATE ROLE in PostgreSQL und MySQL.
Berechtigungen in einer bestimmten Datenbankinstanz und in Schemas verwalten.

BigQuery
Zugriffssteuerung auf Spaltenebene (mit Richtlinien-Tags)
Beschränken Sie den Agentenzugriff auf sensible Spalten, z. B. personenidentifizierbare Informationen, auch in einer autorisierten Tabelle.

Spanner
Detaillierte Zugriffssteuerung (Datenbankrollen mit GRANT/REVOKE)
Erzwingen Sie genaue Lese-, Schreib- und Aktualisierungsberechtigungen für Tabellen und Spalten.

Firestore
IAM-Rollen und IAM-Bedingungen
Konfigurieren Sie Zugriffsrechte pro Datenbank mit IAM-Rollen und IAM-Bedingungen.

Bigtable
IAM-Rollen
Bigtable bietet eine detaillierte Steuerung über IAM-Rollen auf Projekt-, Instanz- und Tabellenebene.

Oracle Database@Google Cloud
IAM-Rollen
Oracle Database@Google Cloud bietet eine detaillierte Steuerung über IAM-Rollen auf Projekt- und Ressourcenebene.

Sicheres Agentendesign

Für Modelle, die nur auf Agenten basieren, sind robuste Abwehrmaßnahmen auf Anwendungsebene gegen Prompt-Injection-Angriffe erforderlich, mit denen versucht wird, den System-Prompt zu überschreiben. Weitere Informationen finden Sie unter KI-Sicherheit und Sicherheit.

Daten und Nutzereingaben als nicht vertrauenswürdig behandeln

Behandeln Sie Eingaben von Endnutzern oder Daten, die vom Agenten aus externen Quellen abgerufen werden, z. B. ein Websuchergebnis oder ein Drittanbieterdokument, als nicht vertrauenswürdig.

Muster für die Aktionsauswahl implementieren

Vermeiden Sie offene Plan- und Ausführungsarchitekturen, bei denen die Spezifikation von Aufgaben auf hoher Ebene von der mechanischen Ausführung entkoppelt wird. Verwenden Sie stattdessen Designmuster, die die Freiheit des Modells einschränken.

  • Muster für die Aktionsauswahl:Die einzige Aufgabe des Modells besteht darin, eine Nutzeranfrage in eine von einer kleinen, vordefinierten Menge sicherer Funktionen zu übersetzen. Die Aktionslogik ist fest codiert und kann vom LLM nicht geändert werden. So wird der Agent immun gegen Injection-Angriffe, die auf den Kontrollfluss abzielen.
  • Dual-LLM-Muster:Verwenden Sie ein primäres LLM (das Aktions-LLM), das die Kernaufgabe ausführt, und ein sekundäres, hochsicheres LLM (das Guardrail-LLM), das den Nutzer-Prompt vorab auf böswillige Absichten prüft und die Ausgabe des Aktions-LLM nachab auf nicht autorisierte Aktionen oder Datenlecks.

Unbefugte Tool-Verkettung verhindern

Agenten dürfen nur Tools aufrufen, die für die Aufgabe erforderlich sind. Achten Sie darauf, dass Ihr Orchestrierungscode Folgendes verhindert:

  • Dynamische Tools:Der Agent darf keine neuen Tools dynamisch registrieren oder die Berechtigungen vorhandener Tools ändern können.
  • Erzwingung der Zulassungsliste:Deklarieren Sie in Ihrem anfänglichen System-Prompt und Backend-Code eine Zulassungsliste von Funktionen oder Datenbanktabellen, auf die der Agent zugreifen kann. Ein Beispiel für die Gemini CLI finden Sie unter Restricting Tool Access.

Datenzugriff in Mandantendatenbanken einschränken

Mit einem allgemeinen Tool wie execute_sql kann der Aufrufer Datenbankabfragen ausführen, mit denen alle Daten gelesen werden können, auf die IAM- und Datenbankberechtigungen Zugriff gewähren. Wenn Sie einen Agenten erstellen, der auf Daten in einer Mandantenanwendung zugreift, ohne dass ein vertrauenswürdiger Mensch beteiligt ist, müssen Sie den Datenzugriff möglicherweise weiter einschränken.

Damit der Agent nur Teilmengen der Daten lesen kann, auf die er Zugriff hat, empfehlen wir, benutzerdefinierte Tools mit einem Framework wie der MCP Toolbox for Databases zu erstellen. Weitere Informationen finden Sie unter Vordefinierte und benutzerdefinierte Tools.

Angenommen, in Ihrer Datenbank werden Bestellungen für alle Endnutzer in der Tabelle Orders gespeichert. Sie entwickeln einen Chat-Agenten, der mit Nutzern interagiert und ihre Bestellungen nachschlagen kann. Der Chat-Agent hat die Berechtigung, die gesamte Tabelle Orders zu lesen, aber ein Endnutzer darf keine Informationen zu den Bestellungen eines anderen Nutzers anfordern.

In einem unsicheren Szenario statten Sie den Agenten nur mit einem execute_sql-Tool aus, wodurch das Risiko eines Datenlecks entsteht. Ein böswilliger Nutzer kann den Agenten dazu bringen, die Bestellungen anderer Nutzer zu lesen und zurückzugeben. Wenn Sie den Agenten anweisen, die Zugriffsregeln zu erzwingen, reicht das in der Regel nicht aus, um die Daten zu schützen.

In einem sicheren Szenario geben Sie dem Agenten ein spezifischeres benutzerdefiniertes Tool, z. B. lookup_active_order, wobei die Identität des Nutzers im Abfragefilter außerhalb der Kontrolle des Agenten festgelegt wird.

Sicherheitskonfigurationen

Spanner bietet Model Armor, um Sicherheitsgrenzen auf der Plattformebene zu erzwingen. Sie müssen diese Einstellungen aktivieren und konfigurieren.

Model Armor aktivieren

Verwenden Sie die Google Cloud CLI, um Model Armor für Ihre Modellbereitstellung zu aktivieren. Dadurch wird der integrierte Schutz vor bekannten Angriffsvektoren wie Injection und Jailbreaking aktiviert.

Im folgenden Beispiel wird Model Armor für einen Vertex AI-Endpunkt aktiviert.

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

Weitere Informationen und Beispiele finden Sie unter Model Armor-Schutz für MCP auf Google Cloud konfigurieren.

Mindestsicherheitsschwellenwerte für sensible Datenvorgänge erzwingen

Mit Model Armor können Sie einen Mindestsicherheitsschwellenwert für sensible Datenvorgänge erzwingen, z. B. für die Erkennung und Anonymisierung von personenidentifizierbaren Informationen. Verwenden Sie eine Sensitive Data Protection DeidentifyTemplate um sensible Informationen zu schwärzen oder zu maskieren, bevor sie an den Nutzer zurückgegeben werden, auch wenn das Modell kompromittiert ist.

Hier sehen Sie ein konzeptionelles Beispiel für die Konfiguration:

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

Im folgenden Beispiel verweist model_armor_config.json möglicherweise auf eine DLP-Vorlage:

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

Prüfung und Beobachtbarkeit

Die Sichtbarkeit von Agentenaktionen ist entscheidend für die Analyse nach einem Vorfall und die Erkennung kompromittierter Agenten.

Strategie zur Datenwiederherstellung implementieren

Mehrschichtige Kontrollen wie IAM- und datenbankeigene Rollen sollen destruktive Aktionen verhindern. Sie müssen jedoch einen Wiederherstellungsplan haben, falls diese Abwehrmaßnahmen fehlschlagen. Ein kompromittierter oder naiver Agent mit Schreibberechtigungen (ein „Agent-Only“-Risiko) kann dazu gebracht werden, einen destruktiven Befehl wie DROP TABLE auszuführen oder Daten zu beschädigen.

Ihre primäre Abwehr gegen dieses Szenario ist eine robuste Wiederherstellungsstrategie.

Fast alle Data Cloud-Produkte bieten Funktionen zur Datenwiederherstellung, entweder über herkömmliche Sicherungen, Wiederherstellung zu einem bestimmten Zeitpunkt (Point-in-Time Recovery, PITR) oder Datensnapshots. Sie sind für die Aktivierung und Konfiguration dieser Funktionen verantwortlich.

Produkt Mechanismen für Sicherung und Wiederherstellung
Cloud SQL Unterstützt sowohl On-Demand- als auch automatische Sicherungen, mit denen Sie eine Instanz in einem früheren Zustand wiederherstellen können. Außerdem wird die Wiederherstellung zu einem bestimmten Zeitpunkt unterstützt.
AlloyDB Bietet standardmäßig kontinuierliche Sicherung und Wiederherstellung. Dadurch ist die Wiederherstellung zu einem bestimmten Zeitpunkt mit Mikrosekunden-Granularität möglich. Sie können einen Cluster zu jedem Zeitpunkt im Aufbewahrungszeitraum wiederherstellen.
BigQuery Die Datenwiederherstellung erfolgt mit der Funktion „Zeitreisen“, mit der Sie auf Daten von jedem Zeitpunkt der letzten 7 Tage zugreifen und sie wiederherstellen können. Für eine längere Aufbewahrungsdauer können Sie Tabellen-Snapshots erstellen.
Spanner Unterstützt sowohl On-Demand-Sicherungen als auch die Wiederherstellung zu einem bestimmten Zeitpunkt.
Firestore Unterstützt automatische Sicherungen, mit denen Sie eine Datenbank in einem früheren Zustand wiederherstellen können. Außerdem wird die Wiederherstellung zu einem bestimmten Zeitpunkt unterstützt, um vor versehentlichem Löschen oder Schreiben zu schützen. Beide Funktionen sind standardmäßig deaktiviert.
Bigtable Unterstützt On-Demand- und automatische Sicherungen. Diese Sicherungen werden vollständig verwaltet und können in einer neuen Tabelle wiederhergestellt werden.
Oracle Database@Google Cloud Unterstützt automatische Sicherungen und die Wiederherstellung zu einem bestimmten Zeitpunkt.

Cloud-Audit-Logs aktivieren

Achten Sie darauf, dass Audit-Logs für den Datenzugriff sowohl für MCP als auch für alle relevanten Google Cloud Dienste wie BigQuery, Cloud SQL, AlloyDB, Firestore, Spanner und Oracle Database@Google Cloud aktiviert sind. Standardmäßig sind nur Admin Activity-Audit-Logs aktiviert. In Audit-Logs für den Datenzugriff werden alle Lese- und Schreibvorgänge aufgezeichnet, die vom Agenten ausgeführt werden. Weitere Informationen finden Sie unter Daten zugriffs-Audit-Logs für MCP.

Sensible Aktionen prüfen

Konfigurieren Sie Benachrichtigungen in Cloud Logging, um anomale oder risikoreiche Aktionen zu erkennen. Mit der Logs Explorer-Abfrage werden beispielsweise Dienstkonten identifiziert, die Datenschreibvorgänge in Firestore ausführen. Firestore ist ein häufiges Ziel für Exfiltration oder destruktive Angriffe:

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"

Agentspezifisches Logging verwenden

Zusätzlich zu Cloud-Audit-Logs muss in Ihrem Anwendungscode für jede Agentenentscheidung Folgendes protokolliert werden:

  • Toolausführung:Das aufgerufene MCP-Tool.
  • Rohbefehl:Der genaue Befehl, z. B. eine SQL-Abfrage oder ein Dokumentpfad, der vom LLM generiert wurde.
  • Endgültige Aktion:Ob die Aktion ausgeführt (Agent-Only-Modell) oder genehmigt wurde (Human-in-the-Middle). Weitere Informationen finden Sie unter Agentenverwendung verstehen.
  • Nutzer- und Sitzungs-ID:Die Kennung des Endnutzers, der die Anfrage initiiert hat.