Sicherheit für agentische Unternehmen in Google Cloud

Die von Unternehmen am häufigsten genannten Bedenken sind Datenpannen (52 %) und die Einhaltung regulatorischer Anforderungen (50 %) (Quelle: Cloud Security Alliance, Dezember 2025). Die Transition von Unternehmen zu autonomer agentischer KI bringt jedoch neue kritische Vektoren mit sich:

• Die durchschnittliche Zeit bis zur Ausnutzung von Sicherheitslücken ist auf minus sieben Tage gesunken, was bedeutet, dass Zero-Day-Lücken routinemäßig ausgenutzt werden, bevor Software-Patches veröffentlicht werden (Quelle: Mandiant M-Trends-Bericht).
• In modernen Cloud-Umgebungen gibt es inzwischen 82-mal mehr nicht menschliche Workload-Identitäten als menschliche Identitäten (Quelle: Google Cloud NEXT 2026).
• 42% der aktiven KI-Agenten in Unternehmen haben derzeit sensible, übermäßig weitreichende Berechtigungen (Quelle: Google Cloud NEXT 2026)
• Um sich gegen Angriffe in Maschinengeschwindigkeit zu verteidigen, muss der gesamte KI-Stack – Infrastruktur, Daten, Modelle und autonome Agenten – gleichzeitig gesichert werden.

Schatten-KI entsteht, wenn Entwickler oder Geschäftseinheiten nicht genehmigte Modelle, externe APIs oder KI-Agenten-Skills von Drittanbietern ohne Prüfung durch die IT-Abteilung einsetzen:

• Über 15% der auf öffentlichen Marktplätzen verfügbaren KI-Agenten-Skills sind bekanntermaßen schädlich (Quelle: Google Cloud NEXT 2026).
• 68% der Unternehmen nutzen selbst gehostete Modelle, die tief in Drittanbieter-Software eingebettet sind, oft ohne es zu wissen (Quelle: Wiz, State of AI in the Cloud 2026)
• Um Schatten-KI zu erkennen, verwenden Unternehmen die Wiz AI-APP, die sich innerhalb von 15 Minuten über eine API verbindet, um eine dynamische KI-Materialliste (AI-BOM) zu erstellen. In Kombination mit Gemini, das eine zentrale Agent Registry bereitstellt, können alle aktiven KI-Agenten, benutzerdefinierten MCP-Server und externen Tools katalogisiert und verwaltet werden.

Nein. Der Fachkräftemangel ist zwar eine bekannte Herausforderung, aber Unternehmen mit formeller KI-Governance schulen ihre Mitarbeiter dreimal häufiger im Umgang mit KI-Sicherheitstools (Quelle: Cloud Security Alliance, Dezember 2025). Außerdem sind Sicherheitsteams mittlerweile in 53 % der Unternehmen für den Schutz von KI-Systemen verantwortlich (Quelle: Cloud Security Alliance, Dezember 2025). Google Cloud verlagert die Sicherheit direkt in die Plattformstruktur: Grundlegende Konfigurationen werden über den Enterprise Foundations Blueprint automatisiert, Laufzeitinteraktionen werden nativ von Model Armor gesteuert und autonome Find-and-Fix-Agenten wie CodeMender und Wiz Green Agent testen und generieren idiomatische Code-Patches direkt in Entwickler-Workflows.

Um autonome KI-Agenten zu schützen, müssen Sie über statische Dienstkonten hinausgehen. Da es 82-mal mehr nicht menschliche Identitäten als menschliche gibt und 42 % der aktiven Agenten übermäßig viele Berechtigungen haben (Quelle: Google Cloud NEXT 2026), hat Google Cloud einen Identity-First Security Stack eingerichtet:

• Agent Identity: Ein dedizierter, erstklassiger Hauptkontotyp, der sich von menschlichen Nutzern unterscheidet und kryptografische, stark attestierte, lebenszyklusgebundene Laufzeit-Anmeldedaten bereitstellt
• Prinzip der geringsten Berechtigung: Die Funktionen werden mit dem Privileged Access Manager (PAM) für den Just-in-Time-Zugriff (JIT) eingeschränkt, wodurch dauerhafte Berechtigungen vermieden werden.
• Principal Access Boundary (PAB): Legt schützende, harte Ressourcengrenzen fest, um das maximale Schadensausmaß laufender Agentenidentitäten einzuschränken

Das Secure AI Framework (SAIF) ist die konzeptionelle Architektur von Google für die sichere und verantwortungsvolle Bereitstellung von KI. Es überträgt Zero-Trust-Sicherheitsprinzipien auf KI-Systeme, indem es die Build-Herkunft auf SLSA-Ebene 3 vorschreibt, die durch Binärautorisierung, automatisierte Policy-as-Code-Prüfungen in Cloud Build und eine kontinuierliche Bedrohungserkennung validiert wird. In agentischen Umgebungen wird SAIF durch den vierstufigen Lebenszyklus operationalisiert: Architektur, Inventar, Abfangen und Verteidigung (Quelle: Secure AI Innovation eBook, Kapitel 6)

Das Model Context Protocol (MCP) ist ein offener Standard, der es autonomen KI-Agenten ermöglicht, sich mit externen Datenquellen, Unternehmenstools und Geschäfts-APIs zu verbinden. Nicht verwaltete benutzerdefinierte MCP-Einbindungen führen jedoch riskante, nicht geprüfte Endpunkte in die Produktion ein. Google Cloud sichert agentische Tools über von Google Cloud verwaltete MCP-Server (wie den MCP-Server für BigQuery). Dies standardisiert die Interaktion von KI-Agenten mit Unternehmensdatenbanken, erzwingt streng begrenzte, prüfbare IAM-Berechtigungen und ersetzt benutzerdefinierte API-Wrapper durch gehärtete, vom Unternehmen verwaltete Verbindungen (Quelle: Google Cloud NEXT 2026).

Session Bleeding tritt in Umgebungen mit mehreren Mandanten oder Agenten auf, wenn private Unterhaltungskontexte, Nutzertokens oder sensible Unternehmensdaten aus der Sitzung eines Nutzers unbeabsichtigt in die Sitzung eines anderen Nutzers gelangen. Google Cloud verhindert Session Bleeding durch das Agent Development Kit (ADK) (Quelle: Secure AI Innovation eBook, Kapitel 2):

• Mandantenisolation: Das ADK erzwingt strikte Nutzergrenzen und Ausführungsisolation mithilfe nativer session_id- und user_id-Primitive.
• Trennung von Anmeldedaten: Downstream-Authentifizierungstokens werden isoliert, sodass ein Agent weder Anmeldedaten noch Konversationsstatus über verschiedene Nutzersitzungen hinweg übertragen kann.

Ja. Unternehmen verfolgen Multi-Modell-Strategien und nutzen durchschnittlich 2,6 verschiedene Modelle(Quelle: Cloud Security Alliance, Dezember 2025). Google Cloud unterstützt die Multi-Modell-Governance, indem Gemini als zentrale Steuerungsebene für die Ausführung verwendet wird. Einheitliche Laufzeitschutzmaßnahmen – einschließlich Model Armor für die Bereinigung von Prompts und semantische Governance-Richtlinien – gelten einheitlich für Gemini-Modelle, Open-Source-Modelle und Modelle von Drittanbietern. Für Multi-Cloud-Umgebungen (einschließlich AWS Bedrock, Databricks und nicht verwalteter Open-Source-Software) bildet der Wiz Security Graph Sicherheitslücken und Angriffspfade über alle Cloud-Anbieter hinweg ab (Quelle: Google Cloud NEXT 2026).

Nein. CodeMender wurde mit einer datenschutzorientierten lokalen Ausführungsarchitektur entwickelt (Quelle: E-Book „Secure AI Innovation“, Kapitel 4):

• Lokale CLI-Verarbeitung: Die CodeMender-Scan-Engine wird über eine lokale Befehlszeile direkt in der sicheren Umgebung der Entwickler ausgeführt.
• Isolierte Sandbox: Anwendungs-Builds und aktive Exploit-Prüfungen werden in einer isolierten Sandbox auf Ihrer eigenen Infrastruktur ausgeführt.
• Kein Modelltraining: Ihr proprietärer Quellcode und Ihr geistiges Eigentum bleiben streng geschützt und werden niemals zum Trainieren von Google Foundation Models verwendet. Entwickler behalten die vollständige Kontrolle durch Standard-IDE/CLI-Workflows und Human-in-the-Loop (HITL)-Genehmigungsgates, bevor ein Code-Patch zusammengeführt wird.

Um risikoreiche Geschäftslogik auszuführen, ohne die Kerninfrastruktur offenzulegen, verwenden Unternehmen die BYOC (Bring Your Own Container)-Referenzarchitektur:

• Container-Sandboxing: Autonome KI-Agenten mit hohem Risiko (z. B. für Inventar oder Logistik) werden in isolierten Containern in Cloud Run bereitgestellt.
• Strikte Trennung von Berechtigungen: Berechtigungen für die Infrastruktur während der Bereitstellung sind strikt von Berechtigungen für die Ausführung während der Laufzeit getrennt.
• Human-in-the-Loop-Gates (HITL): Das Agent Development Kit (ADK) führt programmierte Bedenkzeiten ein, zu denen risikoreiche Aktionen (wie das Initiieren von Fulfillment-APIs oder Finanzzahlungen) vor der Ausführung eine ausdrückliche Genehmigung durch einen Menschen erfordern.

Google Cloud erzwingt eine Laufzeitlösung mit doppelter Schutzmaßnahme, um Nutzlasten ohne zusätzliche Latenz zu bereinigen:

1. Zugriffssteuerung (IAM-Grenzen): Wird nativ im Agent Gateway mithilfe von Identity-Aware Proxy (IAP) erzwungen, um die digitalen IDs von Aufrufern kryptografisch zu überprüfen, bevor Verbindungen weitergeleitet werden.
2. Intent-Kontrolle (semantische Grenzen): Model Armor fungiert als Inline-Proxy, der Nutzer-, Agenten- und Modellinteraktionen in Echtzeit überprüft, um Prompt-Injections zu neutralisieren, Jailbreaks zu verhindern und vertrauliche personenidentifizierbare Informationen zu entfernen. Auf der Anwendungsebene erzwingt das Agent Development Kit (ADK) eine Eingabevalidierung (z. B. BeforeToolCallback), um indirekte SQL-Injections in BigQuery-Tabellen zu verhindern.

Um Datenlecks zu verhindern, ist eine gestaffelte Verteidigung auf Netzwerk-, Anwendungs- und Modellebene erforderlich:

• Private Topologien: KI-Arbeitslasten werden in zentral verwalteten, gemeinsam genutzten VPCs ausgeführt, die durch VPC Service Controls (VPC-SC) isoliert sind. Dadurch entsteht ein Makroperimeter um das gesamte Agenten-Ökosystem.
• Inline-Bereinigung: Model Armor bereinigt und entfernt automatisch sensible Kundendaten und personenidentifizierbare Informationen aus Prompt-Eingaben und Modellausgaben.
• Tokenlose Authentifizierung: Der Agent Identity-Authentifizierungsmanager übernimmt komplexe nachgelagerte OAuth-Handshakes im Namen von Nutzern und übergibt Tokens sicher, ohne KI-Agenten Rohdaten offenzulegen.
• Confidential Computing: Schützt aktive Daten, indem der Arbeitsspeicher während der aktiven Modellverarbeitung verschlüsselt wird.