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-Agenten eine Verbindung zu Cloud SQL for PostgreSQL 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 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 Datenbanksteuerungen 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 Agenten 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)	Beschränken Sie den Zugriff des Agenten 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.

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 Systemprompt 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 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 Nutzerprompt vorab auf böswillige Absichten prüft und die Ausgabe des Aktions-LLM nachab auf nicht autorisierte Aktionen oder Datenlecks prüft.

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 im anfänglichen Systemprompt 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 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 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 für Datenbanken 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, bei dem die Identität des Nutzers im Abfragefilter außerhalb der Kontrolle des Agenten festgelegt wird.

Sicherheitskonfigurationen

Cloud SQL for PostgreSQL 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 PostgreSQL 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 personenbezogenen Daten. 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 kann model_armor_config.json auf eine DLP-Vorlage verweisen:

{
  "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 Verteidigung gegen dieses Szenario ist eine robuste Wiederherstellungsstrategie.

Fast alle Data Cloud-Produkte bieten Funktionen zur Datenwiederherstellung, 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 kontinuierliche Sicherung und Wiederherstellung. Dadurch wird PITR mit Mikrosekunden-Granularität ermöglicht, sodass Sie einen Cluster zu jedem Zeitpunkt im Aufbewahrungszeitraum wiederherstellen können.
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 PITR.
Firestore	Unterstützt automatische Sicherungen, mit denen Sie eine Datenbank in einem früheren Zustand wiederherstellen können. Außerdem bietet es PITR zum Schutz vor versehentlichem Löschen oder Schreiben. 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 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 Ihr Anwendungscode die folgenden Daten für jede Agentenentscheidung protokollieren:

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 (Agent-Only-Modell) oder genehmigt wird (Human-in-the-Middle). Weitere Informationen finden Sie unter Agentenverwendung verstehen.
Nutzer- und Sitzungs-ID:Die Kennung für den Endnutzer, der die Anfrage initiiert hat.