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

MySQL | PostgreSQL | SQL Server

Das Model Context Protocol (MCP) standardisiert, wie generative KI-Agents eine Verbindung zu Cloud SQL for MySQL herstellen. Aufgrund der inhärenten Risiken autonomer Agents 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 Agents ab. Informationen dazu, wie sich die Verwendung von Agents auf die Sicherheits risiken auswirkt, die mit der Integration von Agents in einen MCP-Server verbunden sind, finden Sie unter KI-Sicherheit und -Sicherheit.

Sicherheitsverantwortlichkeiten

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 minimalem Umfang aus. Dies ist die erste und wichtigste Verteidigungsebene.

Dedizierte Identität:Erstellen Sie für jeden einzelnen Agent oder jede einzelne Anwendung, die MCP-Tools verwendet, ein separates, dediziertes Dienstkonto. Verwenden Sie keine vorhandenen Dienstkonten wieder, insbesondere nicht solche mit umfassenden Berechtigungen.
Minimale Bereiche: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 Datenbankkontrollen verwenden

Für die stärkste Verteidigung 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 Agents kompromittiert, der Umfang des Schadens durch die internen Berechtigungen der Datenbank-Engine begrenzt wird. So kann beispielsweise ein DROP TABLE-Befehl verhindert werden.

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)	Agent-Zugriff auf sensible Spalten, z. B. personenidentifizierbare Informationen, auch in einer autorisierten Tabelle beschränken.
Spanner	Detaillierte Zugriffssteuerung (Datenbankrollen mit `GRANT/REVOKE`)	Genaue Lese-, Schreib- und Aktualisierungsberechtigungen für Tabellen und Spalten erzwingen.
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 reine Agent-Modelle 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 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, bei denen das System 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 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 im Nachhinein auf nicht autorisierte Aktionen oder Datenlecks überprüft.

Unbefugte Tool-Verkettung 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 können.
Allowlist-Erzwingung:Deklarieren Sie im anfänglichen System-Prompt und Backend-Code eine Allowlist mit Funktionen oder Datenbanktabellen, auf die der Agent zugreifen kann. Ein Beispiel für die Gemini CLI finden Sie unter Restricting Tool Access.

Datenzugriff in Mandanten-Datenbanken 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 ermöglichen. Wenn Sie einen Agent 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-Agent, 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 Agent nur mit einem execute_sql-Tool aus, wodurch das Risiko eines Datenlecks entsteht. Ein böswilliger Nutzer kann den Agent dazu bringen, die Bestellungen anderer Nutzer zu lesen und zurückzugeben. Wenn Sie den Agent 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

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

Model Armor aktivieren

Verwenden Sie die gcloud 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 in Cloud SQL for MySQL konfigurieren Google Cloud.

Mindestsicherheitsgrenzwerte für sensible Datenvorgänge erzwingen

Mit Model Armor können Sie einen Mindestsicherheitsgrenzwert für sensible Datenvorgänge erzwingen, z. B. 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 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 datenbankeigene Rollen sollen destruktive Aktionen verhindern. Sie müssen jedoch einen Wiederherstellungsplan haben, falls diese Abwehrmaßnahmen versagen. Ein kompromittierter oder naiver Agent mit Schreibberechtigungen (ein reines Agent-Risiko) kann dazu gebracht 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.

In fast allen Data Cloud-Produkten sind Funktionen zur Datenwiederherstellung verfügbar, entweder über herkömmliche Sicherungen, die Wiederherstellung zu einem bestimmten Zeitpunkt (Point-in-time Recovery, PITR) 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, mit denen Sie eine Instanz in einem früheren Zustand wiederherstellen können. Außerdem wird die Wiederherstellung zu einem bestimmten Zeitpunkt (Point-in-time Recovery, PITR) unterstützt.
AlloyDB	Bietet standardmäßig eine kontinuierliche Sicherung und Wiederherstellung. Dadurch wird die Wiederherstellung zu einem bestimmten Zeitpunkt mit Mikrosekunden-Granularität ermöglicht. 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.

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 und Spanner 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 Agent 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 Agent-Entscheidung Folgendes 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.
Endgültige Aktion:Ob die Aktion ausgeführt (reines Agent-Modell) oder genehmigt (Human-in-the-Middle) wird. Weitere Informationen finden Sie unter Agent-Nutzung verstehen.
Nutzer- und Sitzungs-ID:Die Kennung für den Endnutzer, der die Anfrage initiiert hat.