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

Vorschau

Diese Funktion unterliegt den Bedingungen für Pre‑GA-Angebote im Abschnitt „Allgemeine Dienstbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Funktionen stehen in der vorliegenden Form zur Verfügung und bieten möglicherweise nur eingeschränkten Support. Weitere Informationen finden Sie in den Beschreibungen der Produkteinführungsphasen.

Das Model Context Protocol (MCP) standardisiert, wie generative KI-Agents eine Verbindung zu Bigtable herstellen. Aufgrund der inhärenten Risiken autonomer Agents erfordert die Eindämmung 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 MCP-Tools (Model Context Protocol) verwenden, sollten Sie die Best Practices in diesem Leitfaden beachten. Google Cloud

Hinweise

Wenn Sie MCP-Tools verwenden, hängt der Sicherheitsstatus Ihrer Anwendung vom Interaktionsmodell des KI-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.

Sicherheitsverantwortung

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

Folgen Sie dem Prinzip der geringsten Berechtigung.

Führen Sie Ihren Agent mit einem Dienstkonto mit minimalen Berechtigungen aus. Dies ist die erste und wichtigste Verteidigungsebene.

• Eigene Identität:Erstellen Sie für jeden einzelnen Agenten oder jede einzelne Anwendung, die MCP-Tools verwendet, ein separates, eigenes Dienstkonto. Verwenden Sie keine vorhandenen Dienstkonten wieder, insbesondere solche mit umfassenden Berechtigungen.
• Minimale Bereiche:Weisen Sie dem Dienstkonto nur die erforderlichen IAM-Rollen (Identity and Access Management) zu, z. B. alloydb.viewer, nicht alloydb.admin. Wenn der Agent nur Lesezugriff auf einen bestimmten Datensatz 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 Zugriff auf Daten mit hohem Risiko (mit minimalem Umfang) und eines für operative Aufgaben mit geringem Risiko.

Detaillierte Steuerelemente der Datenbank verwenden

Für den bestmöglichen Schutz sollten Sie IAM-Rollen mit den detaillierten Zugriffssteuerungen der Datenbank kombinieren. So wird sichergestellt, dass selbst wenn ein Angreifer das IAM-Token des Agents kompromittiert, der Umfang des Schadens durch die internen Berechtigungen der Datenbank-Engine begrenzt wird. So wird beispielsweise verhindert, dass ein DROP TABLE

Produkt	Detaillierter Kontrollmechanismus	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)	Den Zugriff von KI-Agenten auf sensible Spalten, z. B. personenbezogene Daten, einschränken, auch in einer autorisierten Tabelle.
Spanner	Detaillierte Zugriffssteuerung (Datenbankrollen mit GRANT/REVOKE)	Erzwingen Sie genaue Lese-/Schreib-/Aktualisierungsberechtigungen für Tabellen und Spalten.
Firestore	Firestore-Sicherheitsregeln	Dokument- oder feldbezogenen Zugriff basierend auf der Anwendungslogik oder dem Kontext des anfragenden Nutzers einschränken.
Bigtable	IAM-Rollen	Bigtable bietet eine detaillierte Steuerung über IAM-Rollen auf Projekt-, Instanz- und Tabellenebene.

Sicheres Agent-Design

Für Agent-Only-Modelle sind robuste Schutzmaßnahmen auf Anwendungsebene gegen Prompt-Injection-Angriffe erforderlich, mit denen versucht wird, den System-Prompt zu überschreiben. Weitere Informationen finden Sie unter KI-Sicherheit.

Daten und Nutzereingaben als nicht vertrauenswürdig behandeln

Behandeln Sie Eingaben von Endnutzern oder Daten, die vom Agent 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, in denen die Architektur die Spezifikation von Aufgaben auf hoher Ebene von der mechanischen Ausführung entkoppelt. Verwenden Sie stattdessen Designmuster, die die Freiheit des Modells einschränken.

• Muster zur Auswahl von Aktionen:Die einzige Aufgabe des Modells besteht darin, eine Nutzeranfrage in eine von einer kleinen, vordefinierten Gruppe sicherer Funktionen zu übersetzen. Die Aktionslogik ist fest codiert und kann vom LLM nicht geändert werden. So wird der Agent immun gegen Injektionsangriffe, 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 im Nachhinein auf unautorisierte Aktionen oder Datenlecks.

Unbefugte Verkettung von Tools verhindern

Agents 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.
• Durchsetzung der Zulassungsliste:Deklarieren Sie im ursprünglichen Systemprompt und Backend-Code eine Zulassungsliste von Funktionen oder Datenbanktabellen, auf die der Agent zugreifen kann. Ein Beispiel für die Gemini-Befehlszeile finden Sie unter Tool-Zugriff einschränken.

Sicherheitskonfigurationen

Bigtable bietet Model Armor, um Sicherheitsgrenzen auf 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 die 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 Cloudkonfigurieren.

Mindestsicherheitsgrenzwerte für Vorgänge mit sensiblen Daten erzwingen

Mit Model Armor können Sie einen Mindestsicherheitsgrenzwert für Vorgänge mit sensiblen Daten erzwingen, z. B. für die Erkennung und Anonymisierung von personenidentifizierbaren Informationen. Verwenden Sie eine Sensitive Data Protection-Funktion DeidentifyTemplate, um vertrauliche Informationen zu entfernen oder zu maskieren, bevor sie an den Nutzer zurückgegeben werden, auch wenn das Modell manipuliert wurde.

Das folgende Beispiel zeigt eine konzeptionelle 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 Agent-Aktionen ist entscheidend für die Analyse nach einem Vorfall und die Erkennung kompromittierter Agents.

Strategie zur Datenwiederherstellung implementieren

Mehrschichtige Steuerelemente wie IAM und datenbanknative Rollen sollen zwar destruktive Aktionen verhindern, Sie müssen aber einen Wiederherstellungsplan haben, falls diese Schutzmaßnahmen fehlschlagen. Ein kompromittierter oder naiver Agent mit Schreibberechtigungen (ein reines Agentenrisiko) könnte dazu verleitet werden, einen destruktiven Befehl wie DROP TABLE auszuführen oder Daten zu beschädigen.

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

Fast alle Data Cloud-Produkte bieten Funktionen zur Datenwiederherstellung, entweder durch herkömmliche Backups, die Wiederherstellung zu einem bestimmten Zeitpunkt oder Datensnapshots. Sie sind für die Aktivierung und Konfiguration dieser Funktionen verantwortlich.

Produkt	Sicherungs- und Wiederherstellungsmechanismen
Cloud SQL	Unterstützt sowohl On-Demand- als auch automatische Sicherungen, sodass 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 wird PITR mit Mikrosekundendetaillierungsgrad aktiviert. Sie können einen Cluster zu einem beliebigen Zeitpunkt im Aufbewahrungszeitraum wiederherstellen.
BigQuery	Die Datenwiederherstellung erfolgt über „Zeitreisen“, mit denen Sie auf Daten eines beliebigen Zeitpunkts in den letzten 7 Tagen zugreifen und sie wiederherstellen können. Für eine langfristige Aufbewahrung können Sie Tabellen-Snapshots erstellen.
Spanner	Unterstützt sowohl On-Demand-Sicherungen als auch PITR.
Firestore	Unterstützt verwaltete Exporte/Importe als Sicherungen. Außerdem bietet sie PITR, das standardmäßig deaktiviert ist, um vor versehentlichem Löschen oder Schreiben zu schützen.
Bigtable	Unterstützt On-Demand- und automatische Sicherungen. Diese Sicherungen werden vollständig verwaltet und können in einer neuen Tabelle wiederhergestellt werden.

Cloud-Audit-Logs aktivieren

Achten Sie darauf, dass Audit-Logs zum Datenzugriff für MCP sowie für alle relevanten Google Cloud Dienste wie BigQuery, Cloud SQL, AlloyDB und Spanner aktiviert sind. Standardmäßig sind nur Audit-Logs zur Administratoraktivität aktiviert. In Audit-Logs zum Datenzugriff werden alle Lese- und Schreibvorgänge aufgezeichnet, die vom Agent ausgeführt werden. Weitere Informationen finden Sie unter Audit-Logs zum Datenzugriff für MCP.

Vertrauliche Aktionen prüfen

Konfigurieren Sie Benachrichtigungen in Cloud Logging, um anormale oder risikoreiche Aktionen zu erkennen. Mit der Logs Explorer-Abfrage werden Dienstkonten identifiziert, die Datenschreibvorgänge in Firestore ausführen. Dies ist beispielsweise ein häufiges Ziel für Exfiltrations- oder zerstörerische 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

Achten Sie darauf, dass in Ihrem Anwendungscode zusätzlich zu Cloud-Audit-Logs die folgenden Daten für jede Agent-Entscheidung protokolliert werden:

• Tool-Ausführung:Das aufgerufene MCP-Tool.
• Rohbefehl:Der genaue Befehl, z. B. eine SQL-Abfrage oder ein Dokumentpfad, der vom LLM generiert wurde.
• Finale Aktion:Gibt an, ob die Aktion ausgeführt (Agent-Only-Modell) oder genehmigt (Human-in-the-Middle) wird. Weitere Informationen finden Sie unter Agent-Nutzung.
• Nutzer- und Sitzungs-ID:die Kennung für den Endnutzer, der die Anfrage initiiert hat.