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 unter den Beschreibungen der Startphase.

Das Model Context Protocol (MCP) standardisiert die Verbindung von generativen KI-Agents zu Bigtable. 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 sich an die Best Practices in diesem Leitfaden halten. Google Cloud

Hinweis

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 Schaden durch die internen Berechtigungen der Datenbank-Engine begrenzt wird, z. B. durch das Verhindern eines DROP TABLE-Befehls.

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	IAM-Rollen und IAM-Bedingungen	Zugriffsberechtigungen pro Datenbank mit IAM-Rollen und IAM-Bedingungen konfigurieren.
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 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 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 nachab 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 in der ersten Systemaufforderung und im Backend-Code eine Zulassungsliste mit Funktionen oder Datenbanktabellen, auf die der Agent zugreifen kann. Ein Beispiel für die Gemini-Befehlszeile finden Sie unter Tool-Zugriff einschränken.

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 gemäß IAM- und Datenbankberechtigungen zugegriffen werden darf. Wenn Sie einen Agent erstellen, der ohne vertrauenswürdigen menschlichen Eingriff auf Daten in einer mandantenfähigen Anwendung zugreift, müssen Sie den Datenzugriff möglicherweise weiter einschränken.

Damit der KI-Agent nur Teilmengen der Daten lesen kann, auf die er Zugriff hat, empfehlen wir, benutzerdefinierte Tools mit einem Framework wie der MCP Toolbox für Datenbanken zu erstellen. Weitere Informationen finden Sie unter Vorgefertigte 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 aufrufen kann. Der Chat-Agent hat die Berechtigung, die gesamte Tabelle Orders zu lesen. Ein Endnutzer darf jedoch keine Informationen zu den Bestellungen eines anderen Nutzers anfordern.

In einem unsicheren Szenario statten Sie den Agent nur mit einem execute_sql-Tool aus, was das Risiko eines Datenlecks birgt. 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 Agent ein spezifischeres benutzerdefiniertes Tool, z. B. lookup_active_order, bei dem die Identität des Nutzers im Abfragefilter außerhalb der Kontrolle des Agents festgelegt wird.

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 DeidentifyTemplate von Sensitive Data Protection, 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 Kontrollen 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 automatisierte Sicherungen, mit denen Sie eine Datenbank in einem früheren Zustand wiederherstellen können. Außerdem bietet sie PITR, 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.

Cloud-Audit-Logs aktivieren

Achten Sie darauf, dass Audit-Logs für den Datenzugriff für MCP sowie alle relevanten Google Cloud Dienste wie BigQuery, Cloud SQL, AlloyDB, Firestore 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.

Sensible 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-Anfrage oder ein Dokumentpfad, der vom LLM generiert wird.
• 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.