Thales Google Cloud AI Security ergänzt Kontrollen, doch Autonomie erhöht den Einsatz

Thales hat seine Partnerschaft mit Google Cloud am 28. September ausgeweitet und Sicherheitskontrollen für KI-Agenten ergänzt, obwohl weiterhin ungeklärt ist, wie zuverlässig Leitplanken autonome Systeme begrenzen können. Die Thales Google Cloud AI Security-Integration verbindet Thales AI Security Fabric mit Gemini Enterprise. Sie richtet sich auf die Interaktionen zwischen Nutzern, Agenten, Modellen, Unternehmensdaten und externen Tools.

Die Ankündigung spiegelt einen größeren Wandel in der Unternehmens-KI wider. Assistenten erzeugten bisher vor allem Antworten, die Menschen prüfen konnten. Agenten können nun Tools auswählen, sensible Datensätze abrufen, APIs aufrufen und Geschäftssysteme verändern. Eine bösartige Anweisung oder übermäßige Berechtigung kann daher einen operativen Vorfall auslösen und nicht nur eine schlechte Antwort.

Google Cloud positioniert Agent Gateway bereits als Kontrollpunkt für Verbindungen zwischen Agenten und Tools. Thales ergänzt diese Verbindungen um Inspektion, Richtliniendurchsetzung und Bedrohungserkennung. Damit bewegt sich die Partnerschaft auf demselben strategischen Spielfeld wie Microsoft, Zscaler, Palo Alto Networks und andere Anbieter, die die Sicherheitsebene für Unternehmensagenten definieren wollen.

Die zentrale Frage lautet nicht mehr, ob KI-Agenten zusätzlichen Schutz benötigen. Behördliche Leitlinien und unabhängige Sicherheitsforschung haben diesen Punkt geklärt. Die eigentliche Frage ist, ob eine integrierte Laufzeitebene Agenten zuverlässig einschränken kann, ohne sie zu langsam, zu teuer oder zu eingeschränkt für einen sinnvollen Einsatz zu machen.

Was die Thales Google Cloud AI Security-Integration verändert

Die Partnerschaft verlagert die Agentensicherheit näher an den Zeitpunkt, an dem ein KI-System Daten liest, ein Tool auswählt oder eine Aktion versucht.

Laut der Sicherheitsankündigung wird Thales AI Security Fabric in Google Cloud Gemini Enterprise integriert. Thales zufolge kann das kombinierte System Transparenz-, Governance- und Sicherheitsrichtlinien auf die Kommunikation zwischen Nutzern, Agenten, Modellen, Tools und Unternehmensinformationen anwenden.

Die vorgesehene Abdeckung umfasst mehrere Phasen eines agentischen Workflows. Das System kann Datenverkehr prüfen, der in einen Agenten gelangt, Austauschvorgänge zwischen dem Agenten und seinem Modell beobachten und Aufrufe externer Tools überwachen. Zudem soll es Grenzen für die Informationen durchsetzen, auf die ein Agent zugreifen kann, sowie für die Aktionen, die er ausführen darf.

Diese Unterscheidungen sind wichtig, weil ein Agent keine einzelne isolierte Modellsitzung ist. Er ist eine Kette aus Entscheidungen, Zugangsdaten, Datenquellen und Softwareschnittstellen. Jede Übergabe schafft einen weiteren Punkt, an dem ein Angreifer, ein Konfigurationsfehler oder eine unzuverlässige Modellentscheidung das Ergebnis verändern kann.

Thales nennt Prompt Injection, Datenabfluss, unsichere Ausgaben, nicht autorisierte Aktionen und die Kommunikation zwischen Agenten als wesentliche Risiken. Prompt Injection tritt auf, wenn feindliche Anweisungen, die in Inhalte eingebettet sind, das Verhalten eines Modells manipulieren. Eine E-Mail, ein Dokument, eine Website oder eine Tool-Antwort kann solche Anweisungen enthalten, ohne dass Nutzer sie bemerken.

Die vorgeschlagene Antwort der Partnerschaft ist eine einheitliche Durchsetzungsebene. Thales zufolge kann seine Fabric KI-spezifische Bedrohungen erkennen, Transparenz über Agentenverhalten bewahren und Aktionen blockieren, die gegen organisatorische Richtlinien verstoßen. Das Unternehmen positioniert zentralisierte Aufzeichnungen zudem als Unterstützung für Compliance-Prüfungen und Vorfalluntersuchungen.

Betrachten wir das von Thales angeführte Versicherungsbeispiel. Ein Agent, der bei der Regulierung von Schadensfällen helfen darf, könnte personenbezogene Informationen aus nicht genehmigten Quellen heranziehen. Selbst wenn die Berechnung der Auszahlung plausibel erscheint, kann der Workflow Datenschutz-, Fairness- und Compliance-Probleme schaffen.

Eine Laufzeitkontrolle könnte die angeforderte Datenquelle, die dem Agenten zugewiesene Rolle und die vorgeschlagene Aktion prüfen, bevor der Workflow fortgesetzt werden darf. Sie könnte die Anfrage verweigern, den versuchten Zugriff protokollieren oder eine menschliche Genehmigung verlangen. Das ist ein anderes Sicherheitsmodell als lediglich den von einem Nutzer eingereichten Prompt zu filtern.

Die Integration baut außerdem auf der umfassenderen Agentenarchitektur von Google Cloud auf. Sein Agent Gateway-Ökosystem bietet gesteuerte Konnektivität für Datenverkehr von Nutzern zu Agenten, zwischen Agenten sowie von Agenten zu Tools. Google hat das Gateway als offenen Kontrollpunkt beschrieben, der mit mehreren Sicherheitsanbietern zusammenarbeiten kann.

Thales ersetzt daher nicht die nativen Kontrollen von Google Cloud. Stattdessen liefert es eine spezialisierte Inspektions- und Durchsetzungsebene innerhalb einer breiteren Architektur. Der Wert hängt davon ab, wie viel zusätzlichen Kontext sie analysieren kann und wie zuverlässig sie eingreifen kann, bevor riskante Aktivitäten ein Geschäftssystem erreichen.

Warum KI-Agenten Kontrollen über Modell-Leitplanken hinaus benötigen

Eine sichere Modellantwort garantiert keinen sicheren Workflow, wenn das System Zugangsdaten besitzen und ohne unmittelbare menschliche Prüfung handeln kann.

Traditionelle Sicherheit für generative KI konzentriert sich häufig auf Inhalte. Unternehmen versuchen, schädliche Antworten, die Offenlegung vertraulicher Daten oder unangemessene Prompts zu verhindern. Diese Bedenken bleiben wichtig, doch Agenten führen eine weitere Risikokategorie ein: Softwareaktionen mit realen Folgen.

Ein Agent kann eine Anweisung erhalten, einen Plan erstellen, ein Tool auswählen und eine Transaktion ausführen. Er könnte eine Nachricht senden, einen Kundendatensatz bearbeiten, eine Rückerstattung genehmigen, Quellcode ändern oder eine Infrastrukturänderung anstoßen. Ein Fehler kann sich ausbreiten, bevor eine Person die Zwischenschritte der Argumentation sieht.

Dieser Unterschied erklärt, warum Laufzeitautorisierung zunehmend zentral wird. Eine Richtlinie sollte nicht nur bewerten, was der Agent sagt, sondern auch, welche Identität er verwendet, welche Ressource er anfordert und ob diese Aktion zu seiner zugewiesenen Aufgabe passt. Die Entscheidung muss möglicherweise erneut getroffen werden, sobald der Workflow die Richtung ändert.

Das Problem wird schwieriger, wenn Agenten zusammenarbeiten. Ein Agent könnte Informationen sammeln, während ein anderer eine Empfehlung abgibt und ein dritter eine Aktion ausführt. Eine kompromittierte Komponente kann manipulierten Kontext oder Anfragen an den Rest der Kette weitergeben.

Thales erklärt, seine Kontrollen würden diese Interaktionen zwischen Agenten abdecken. Dieses Versprechen adressiert eine wichtige Lücke, doch Implementierungsdetails werden seinen Wert bestimmen. Sicherheitsteams müssen wissen, wie Identitäten überprüft werden, wie delegierte Berechtigungen dargestellt werden und wie Richtlinien einer Aufgabe über mehrere Agenten hinweg folgen.

NIST hat dasselbe Problem identifiziert. Seine im Mai 2026 veröffentlichte Analyse zur Agentensicherheit stellte breite Übereinstimmung fest, dass Agenten neuartige Bedrohungen einführen. Die Befragten erklärten zudem, dass bewährte Cybersicherheitspraktiken weiterhin nützlich seien, aber für Agentensysteme angepasst werden müssten.

Identität veranschaulicht diese Anpassung. Eine herkömmliche Anwendung arbeitet häufig über ein stabiles Dienstkonto mit vorhersehbaren Funktionen. Ein Agent kann einen Plan dynamisch zusammenstellen und abhängig von wechselndem Kontext zwischen mehreren Tools wählen.

Einem solchen Agenten weitreichende Zugangsdaten zu geben, macht ihn nützlich, erhöht aber auch den Schaden durch Manipulation. Jede Berechtigung im Voraus einzuschränken, senkt das Risiko, kann den Agenten jedoch daran hindern, legitime Arbeit abzuschließen. Sicherheitsteams müssen nützliche Autonomie gegen einen eng begrenzten Schadensradius abwägen.

Prüfprotokolle stellen eine weitere Herausforderung dar. Das Protokollieren eines Tool-Aufrufs reicht nicht aus, wenn Ermittler nicht feststellen können, welcher Nutzer die Aufgabe initiiert hat, welche Informationen den Agenten beeinflusst haben oder warum eine Aktion autorisiert wurde. Nützliche Aufzeichnungen müssen menschliche Absicht, Agentenidentität, Datenzugriff und die daraus resultierende Systemänderung verbinden.

Der Thales Google Cloud AI Security-Ansatz behandelt dieses Problem durch Transparenz über den gesamten Workflow hinweg. Grundsätzlich kann eine gemeinsame Ebene Aktivitäten korrelieren, die andernfalls in getrennten Modell-, Identitäts-, API- und Anwendungsprotokollen erscheinen.

Diese Transparenz kann Security-Operations-Teams dabei helfen, ungewöhnliches Verhalten zu erkennen. Ein Agent, der normalerweise regionale Verkaufsdaten liest, sollte genauer geprüft werden, wenn er plötzlich Mitarbeiterdaten oder einen unbekannten externen Endpunkt anfordert. Verhaltenskontext ist wertvoll, wenn statische Regeln nicht jede gültige Abfolge vorhersehen können.

Transparenz ist jedoch keine Eindämmung. Ein Dashboard kann einen Vorfall erklären, nachdem der Schaden entstanden ist. Die weitergehende Behauptung lautet, dass Richtlinien die unsichere Aktion in Echtzeit stoppen können, ohne legitime Varianten zu blockieren, die Agenten nützlich machen.

Laufzeitdurchsetzung wird zum wichtigsten Wettbewerbsfeld

Der strategische Wettbewerb findet zwischen Sicherheit statt, die in eine Cloud-Plattform eingebettet ist, und unabhängigen Kontrollen, die konsistente Richtlinien über Modelle, Agenten und Tools hinweg versprechen.

Google Cloud baut ein Partnerökosystem rund um Agent Gateway auf, anstatt sich auf einen Sicherheitsanbieter zu stützen. Zu den veröffentlichten Teilnehmern zählen Thales, Zscaler, Exabeam, Silverfort, Cisco, CrowdStrike, Palo Alto Networks und andere. Jeder Anbieter behandelt einen anderen Teil des Agenten-Workflows.

Thales bringt Imperva-Anwendungs- und API-Sicherheit in diese Struktur ein. Die angegebene Abdeckung umfasst Datenverkehr vom Client zum Agenten, Austausch zwischen Agent und Modell sowie Interaktionen mit Tools über Schnittstellen wie Model Context Protocol. MCP ist ein Protokoll, das KI-Anwendungen mit externen Daten und Softwarefunktionen verbinden lässt.

Dieser Ansatz bietet Unternehmenskäufern Flexibilität. Ein Unternehmen kann die Infrastruktur von Google nutzen und zusätzliche Kontrollen auswählen, die zu seinen bestehenden Sicherheitsabläufen passen. Es kann außerdem den Druck verringern, vollständig von Schutzmaßnahmen eines Modellanbieters abhängig zu sein.

Der Nachteil ist Komplexität. Mehrere Produkte können denselben Workflow aus unterschiedlichen Perspektiven prüfen. Sicherheitsteams müssen entscheiden, welche Komponente für Identität, Datenschutz, Verhaltensanalyse, Autorisierung und Reaktion auf Vorfälle zuständig ist.

Überlappende Kontrollen können ebenso leicht Lücken wie Tiefe erzeugen. Ein Produkt könnte eine Anfrage auf Grundlage der Identität des Agenten genehmigen, während einem anderen der Aufgabenkontext fehlt, der nötig wäre, um Missbrauch zu erkennen. Ein drittes könnte den Tool-Aufruf protokollieren, ohne die zurückgegebenen sensiblen Daten zu verstehen.

Microsoft verfolgt einen stärker vertikal integrierten Weg. Seine Sicherheitsstrategie für Agenten verbindet Identität, Zugriffsrichtlinien, Daten-Governance und Produktivitätsanwendungen. Microsoft Entra kann Agenten Identitäten zuweisen, während Purview-Richtlinien sensible Informationen innerhalb der Microsoft-Umgebung steuern.

Dieses Modell bietet Organisationen, die bereits auf Microsoft-Dienste ausgerichtet sind, einen klareren administrativen Weg. Es weckt jedoch auch die bekannten Bedenken einer Plattformabhängigkeit. Kontrollen, die für die Anwendungen eines Anbieters optimiert sind, könnten weniger konsistente Abdeckung bieten, wenn Workflows Clouds, Modelle und Tools von Drittanbietern überqueren.

Die partnerbasierte Architektur von Google macht Offenheit zu einem Teil des Versprechens. Doch Offenheit verlagert Integrationsarbeit auf die Plattform und ihre Kunden. Eine Richtlinie ist nur dann nützlich, wenn sie jede Übergabe übersteht und schnell genug eine Entscheidung liefert, um Produktionsverkehr zu bedienen.

Unabhängige Anbieter stehen vor einer ähnlichen Herausforderung. Sie müssen nachweisen, dass ihre zusätzliche Ebene mehr als eine weitere Monitoring-Konsole bietet. Käufer werden durchsetzbare Richtlinien, brauchbare Untersuchungen und Belege erwarten, dass die Kontrollen Risiken senken, ohne die Routinearbeit zu stören.

Thales hat eine glaubwürdige Position, weil Imperva bereits im Umfeld von Webanwendungen und APIs arbeitet. Agenten-Workflows verwenden viele derselben Schnittstellen. Bestehende Datenverkehrsinspektion, Bot-Management und API-Schutz können eine Grundlage bieten, um Clients zu erkennen und Anfragen zu kontrollieren.

Das Verhalten von Agenten unterscheidet sich weiterhin vom herkömmlichen Anwendungsverkehr. Ein gültiger Agent kann eine technisch gültige API-Anfrage zu einem unzulässigen Zweck stellen. Um diesen Unterschied zu erkennen, braucht es Kontext zu Nutzerabsicht, delegierter Befugnis, Datensensibilität und der Abfolge vorheriger Aktionen.

Hier verlagert sich der Wettbewerbsdruck über etablierte Websicherheit hinaus. Anbieter müssen den operativen Kontext eines Agenten interpretieren, ohne sich auf dessen eigene Erklärung zu verlassen. Ein manipulierter Modell kann eine überzeugende Begründung für einen unsicheren Aufruf liefern.

Cloud-Anbieter verfügen zudem über einen Informationsvorsprung. Sie betreiben den Modelldienst, die Identitätsebene, das Netzwerk und die Agentenplattform. Ein Partner muss ausreichend Telemetriedaten erhalten, um präzise Entscheidungen treffen zu können, und dabei zugleich Kundendatenschutz und Systemleistung wahren.

Die stärkste Architektur könnte daher mehrschichtig sein. Native Cloud-Kontrollen können grundlegende Identität und Isolation durchsetzen, während spezialisierte Produkte Anwendungsverhalten und Bewegungen sensibler Daten prüfen. Menschliche Freigaben bleiben bei irreversiblen oder folgenreichen Entscheidungen angemessen.

Dieser Wettbewerb wird nicht durch die längste Funktionsliste entschieden. Unternehmen werden bewerten, wie gut jede Architektur mit gemischten Umgebungen, delegierten Identitäten und unvollständigem Kontext umgeht. Sie werden außerdem prüfen, ob Incident-Response-Teams einen Workflow rekonstruieren können, ohne mehrere inkompatible Logs zusammenführen zu müssen.

Das Sicherheitsversprechen braucht weiterhin Produktionsnachweise

Thales und Google Cloud beschreiben die richtigen Kontrollpunkte, doch die Ankündigung belegt nicht, wie präzise oder konsistent diese Kontrollen unter gegnerischem Druck funktionieren.

Die Unternehmen haben in der Ankündigung weder Deployment-Zahlen, Latenzmessungen, unabhängige Bewertungen noch detaillierte Falschpositiv-Raten veröffentlicht. Sie nennen auch keine Kundenfallstudien, die zeigen, dass das integrierte Sicherheitsgeflecht Angriffe im Produktivbetrieb stoppt.

Dieses Fehlen entkräftet nicht die Produktrichtung. Es begrenzt jedoch, was aus dem Start abgeleitet werden kann. Die Integration sollte als erweiterte Sicherheitsarchitektur betrachtet werden, nicht als Beweis dafür, dass agentische Workflows nun sicher sind.

Prompt Injection bleibt ein anspruchsvoller Test. Die Red-Teaming-Ergebnisse von NIST aus dem März 2026 beschreiben indirekte Prompt Injection als Übernahme eines Agenten. Angreifer platzieren feindliche Anweisungen in externen Inhalten, die ein Agent später verarbeitet.

Diese Angriffe nutzen eine grundlegende Mehrdeutigkeit aus. Ein Modell erhält sowohl legitime Anweisungen als auch nicht vertrauenswürdige Informationen in ähnlichen Textformen. Es muss Daten, die es analysieren soll, von Befehlen unterscheiden, denen es folgen soll – selbst wenn bösartige Inhalte gezielt darauf ausgelegt sind, diese Grenze zu verwischen.

Laufzeit-Richtlinien können den Schaden verringern. Eine eingeschleuste Anweisung könnte einen Agenten dazu bewegen, vertrauliche Datensätze anzufordern, doch eine separate Autorisierungsebene kann diese Anfrage weiterhin verweigern. Die Kontrolle muss nicht exakt feststellen, warum das Modell die falsche Entscheidung getroffen hat.

Diese Trennung ist eine der stärksten Ideen der Partnerschaft. Deterministische Begrenzungen beim Datenzugriff und bei der Tool-Nutzung können Fehler eindämmen, die Guardrails auf Modellebene übersehen. Least-Privilege-Anmeldedaten und menschliche Freigaben können die Auswirkungen zusätzlich reduzieren.

Die Policy Engine benötigt jedoch präzisen Kontext. Sie muss wissen, welcher Nutzer die Aufgabe autorisiert hat, welchem Zweck der Agent dient und welche Ressourcen erforderlich sind. Breite oder schlecht gepflegte Richtlinien können eine technisch fortschrittliche Kontrollebene in ein permissives Gateway verwandeln.

Falschpositive erzeugen den gegenteiligen Fehler. Wenn ein Agent wiederholt auf Freigaben wartet oder den Zugriff auf Routinedaten verliert, könnten Mitarbeitende ihn meiden. Administratoren könnten Richtlinien lockern, bis die Durchsetzung keinen sinnvollen Schutz mehr bietet.

Auch Latenz spielt eine Rolle. Jeder Prüfschritt erhöht die Verarbeitungszeit. Bei einer einzelnen Interaktion kann der Effekt gering sein, in Workflows mit Dutzenden Modellanfragen und Tool-Aufrufen jedoch erheblich. Organisationen benötigen Messwerte aus realistischen Multi-Agent-Deployments.

Verschlüsselung und Datenschutz erzeugen eine weitere Spannung. Sicherheitstools benötigen ausreichende Einblicke, um sensible Informationen und bösartige Anweisungen zu erkennen. Kunden werden klare Erklärungen dazu erwarten, welche Inhalte geprüft werden, wo sie verarbeitet werden, wie lange sie aufbewahrt werden und wer darauf zugreifen kann.

Das Problem geht über ein einzelnes Produkt hinaus. Die OWASP-Agentenrisiken umfassen Zielübernahme, Tool-Missbrauch, Identitätsmissbrauch, Speichervergiftung, unsichere Inter-Agenten-Kommunikation und kaskadierende Ausfälle. Kein einzelner Traffic-Filter löst jede Kategorie.

Speichervergiftung ist ein anschauliches Beispiel. Ein Angreifer könnte falsche oder bösartige Informationen platzieren, die ein Agent zur späteren Verwendung speichert. Eine Laufzeitkontrolle könnte die ursprüngliche Eingabe prüfen, doch die schädliche Wirkung kann erst Tage später in einem anderen Workflow auftreten.

Kaskadierende Ausfälle sind ebenso schwierig. Ein Agent kann ein falsches Ergebnis erzeugen, das für einen anderen vertrauenswürdig erscheint. Jeder einzelne Tool-Aufruf kann die Richtlinien erfüllen, während sich der Gesamtworkflow einem schädlichen Ergebnis nähert.

Organisationen benötigen daher Defense in Depth. Sie sollten eingeschränkte Berechtigungen, Sandboxing, signierte Identitäten, geschützten Speicher, validierte Tools, kontinuierliches Monitoring und menschliche Prüfung kombinieren. Sicherheitstests müssen vollständige Workflows statt isolierter Modellantworten abdecken.

Staatliche Leitlinien bekräftigen diese Position. Australiens Leitlinien zur Einführung von Agenten empfehlen menschliche Kontrollpunkte, kontinuierliches Monitoring, minimale Berechtigungen und mehrere überlappende Schutzmaßnahmen. Sie raten außerdem zu einer schrittweisen Ausweitung der Autonomie.

Thales AI Security Fabric kann zu einer dieser Schutzmaßnahmen werden. Die Ankündigung rechtfertigt jedoch nicht, es als vollständiges Sicherheitsprogramm zu behandeln. Käufer sollten fragen, wie es mit bereits vorhandenen Identitätssystemen, Entwicklungskontrollen, Incident Response und Freigabeverfahren zusammenspielt.

Wer unter Druck gerät, wenn Agentensicherheit in den Workflow einzieht

Sicherheitsanbieter, Cloud-Plattformen und Unternehmenskäufer stehen nun unter Druck, Agenten-Governance von einer schriftlichen Richtlinie in durchsetzbare Software zu überführen.

Cloud-Anbieter sehen sich den unmittelbarsten Erwartungen gegenüber. Sie wollen, dass Kunden Agenten aus Experimenten in Geschäftsprozesse überführen, doch die Einführung stockt, wenn Rechts- und Sicherheitsteams keine akzeptablen Grenzen definieren können. Eine Plattform, die grundlegende Fragen zu Identität, Zugriff und Auditierbarkeit nicht beantworten kann, wird bei sensiblen Deployments Schwierigkeiten haben.

Die Antwort von Google Cloud besteht darin, Agent Gateway als gemeinsamen Durchsetzungspunkt aufzubauen und ihn mit spezialisierten Partnern zu umgeben. Thales stärkt diese Strategie, indem es Anwendungs-, API-, Modell- und Tool-Interaktionen über ein Sicherheitsgeflecht abdeckt.

Thales muss zeigen, dass dieser breitere Umfang handhabbar bleibt. Sein Wertversprechen beruht darauf, Kunden einen kohärenten Überblick über mehrere technische Ebenen zu geben. Fragmentierte Richtlinien oder doppelte Warnmeldungen würden den Nutzen der Integration schwächen.

Konkurrierende Sicherheitsanbieter stehen unter Druck, eine ebenso breite Abdeckung nachzuweisen. Der Schutz von Prompts allein reicht nicht mehr aus. Käufer benötigen Kontrollen für Anmeldedaten, Tool-Ausführung, Datenbewegungen, Speicher, Inter-Agenten-Nachrichten und externe Aktionen.

Auch Identitätsanbieter stehen vor neuen Aufgaben. Agenten benötigen eigenständige Identitäten, begrenzte Berechtigungen, nachvollziehbare Verantwortlichkeiten und verwaltbare Lebenszyklen. Temporäre Agenten sollten nach Ende ihrer Aufgaben keine dauerhaften Anmeldedaten hinterlassen.

Anwendungsverantwortliche tragen eine weitere Last. Sie müssen definieren, welche Aktionen ein Agent unter welchen Bedingungen ausführen darf. Sicherheitsteams können keine nützlichen Richtlinien erstellen, ohne operativen Input von den Menschen, die den Workflow verstehen.

Entwickler müssen mehr strukturierten Kontext bereitstellen. Eine Sicherheitsebene kann bessere Entscheidungen treffen, wenn Tool-Aufrufe die Aufgabe, den Nutzer, die angeforderte Ressource und die beabsichtigte Wirkung deklarieren. Unstrukturierte Prompts allein bilden eine schwache Grundlage für Autorisierung.

Unternehmenskäufer sollten der Versuchung widerstehen, Beschaffung als Ende der Governance zu behandeln. Die Installation eines Sicherheitsgeflechts bestimmt keine akzeptable Autonomie. Organisationen müssen weiterhin Anwendungsfälle klassifizieren, Verantwortliche zuweisen, Eskalationspunkte definieren und Fehlerszenarien testen.

Anwendungsfälle mit geringem Risiko bieten einen sinnvollen Ausgangspunkt. Ein Agent, der einen Bericht aus genehmigten internen Dokumenten erstellt, hat einen kleineren Schadensradius als einer, der Nachrichten versendet oder Kundenkonten verändert. Berechtigungen sollten erst ausgeweitet werden, wenn die Bewertung zeigt, dass der Workflow kontrolliert bleibt.

Folgenreiche Aktionen verdienen eine ausdrückliche Freigabe. Finanztransfers, Produktionsänderungen, rechtliche Kommunikation, Personalentscheidungen und die Offenlegung sensibler Daten sollten nicht allein von der Zuversicht eines Modells abhängen. Menschliche Prüfung kann den Workflow verlangsamen, doch diese Reibung entspricht den Folgen eines Fehlers.

Wissensarbeiter sollten sich dafür interessieren, weil diese Kontrollen bestimmen, was Arbeitsplatz-Agenten sehen und tun können. Bessere Sicherheit kann Agenten Zugang zu nützlichen internen Informationen ermöglichen. Schlecht konzipierte Kontrollen können entweder zu viele Daten offenlegen oder den für präzise Arbeit erforderlichen Kontext blockieren.

Mitarbeitende benötigen zudem Transparenz. Sie sollten wissen, wann ein Agent unter ihrer Identität handelt, auf welche Datensätze er zugegriffen hat und ob seine Ausgaben externe Änderungen auslösen. Versteckte Automatisierung erschwert Verantwortlichkeit, wenn ein Vorfall eintritt.

Die größere Verschiebung ist organisatorischer Natur. KI-Sicherheit entwickelt sich von einer Aufgabe der Modellbewertung zu einem Bestandteil des alltäglichen Identitäts- und Anwendungsmanagements. Dadurch werden Agenten denselben operativen Disziplinen unterworfen, die für Mitarbeitende, Dienste, Anbieter und Software-Deployments gelten.

Die KI-Sicherheitspartnerschaft von Thales und Google Cloud ist wichtig, weil sie diesen Übergang ausdrücklich macht. Ihr Erfolg wird weniger von der Ankündigung abhängen als davon, ob Unternehmen die Kontrollen anwenden können, ohne eine weitere isolierte Governance-Ebene zu schaffen.

Drei Signale werden zeigen, ob die Kontrollen funktionieren

Der nächste Test sind messbare Deployment-Nachweise, gefolgt von interoperabler Identität und glaubwürdiger adversarialer Bewertung.

Das erste Signal ist die Einführung im Produktivbetrieb mit offengelegten Ergebnissen. Thales oder Google Cloud sollten Kundenbeispiele veröffentlichen, die Workflow, Berechtigungen, blockiertes Verhalten und operativen Aufwand erläutern. Nützliche Nachweise würden Erkennungsgenauigkeit, Freigabehäufigkeit, Latenz und Ergebnisse der Incident Response umfassen.

Eine vage Aussage, dass ein Kunde sichere Agenten eingesetzt hat, sagt wenig aus. Die stärkste Fallstudie würde zeigen, wie eine Kontrolle eine realistische Prompt Injection oder einen nicht autorisierten Tool-Aufruf gestoppt hat. Sie sollte außerdem erklären, wie oft legitime Aktivitäten unterbrochen wurden.

Wenn diese Nachweise erscheinen, stärken sie die Behauptung, dass Laufzeitdurchsetzung praktische Agenten-Deployments unterstützen kann. Bleiben Kunden ungenannt und Messwerte privat, sollten Käufer die Integration als vielversprechend, aber unbewiesen betrachten.

Das zweite Signal ist eine stärkere Identität und Autorisierung über Plattformen hinweg. NIST hat bereits Fragen zu Agentenidentifikation, Delegation, Auditierung und Nichtabstreitbarkeit hervorgehoben. Der Markt benötigt konsistente Wege, um nachzuweisen, welcher Agent handelt, für wen und mit welcher Befugnis.

Interoperabilität wird wichtig sein, weil Unternehmensworkflows selten innerhalb der Umgebung eines einzelnen Anbieters bleiben. Ein Agent könnte ein Google-Modell nutzen, eine Datenbank eines Drittanbieters abfragen, eine Microsoft-Anwendung aufrufen und ein intern entwickeltes Tool einsetzen.

Richtlinien müssen diesem Workflow folgen, ohne einer wiederverwendbaren Anmeldeinformation weitreichenden Zugriff zu gewähren. Kurzlebige, an eine spezifische Aufgabe gebundene Autorisierung würde das Risiko reduzieren. Überprüfbare Aufzeichnungen sollten jede folgenreiche Aktion sowohl mit dem Agenten als auch mit dem verantwortlichen Menschen oder Dienst verbinden.

Fortschritte bei offenen Identitätsstandards würden die Partnerstrategie von Google Cloud stärken. Anhaltende Fragmentierung würde eng integrierte Plattformen begünstigen, die einen größeren Teil des technischen Stacks kontrollieren.

Das dritte Signal sind unabhängige adversariale Tests. Thales und Google Cloud sollten das gemeinsame System gegen indirekte Prompt-Injection, bösartige Tool-Ausgaben, Missbrauch von Zugangsdaten, Memory Poisoning und kompromittierte Agenten testen. Die Evaluierungen sollten die Eindämmung messen – nicht nur, ob ein Angriff erkannt wurde.

Ein sinnvoller Test würde davon ausgehen, dass das Modell versagt. Anschließend würde geprüft, ob externe Kontrollen Datenexfiltration oder eine nicht autorisierte Systemänderung verhindern. Damit lassen sich Sicherheitsversprechen des Modells vom praktischen Sicherheitswert der umgebenden Architektur trennen.

Unabhängige Forschende sollten außerdem Umgehungsmöglichkeiten untersuchen, die durch Multi-Agent-Workflows entstehen. Eine Richtlinie kann eine direkte Anfrage blockieren, zugleich aber mehrere einzeln zulässige Aktionen erlauben, die gemeinsam zum gleichen untersagten Ergebnis führen.

Die Einführung kommt zum richtigen Zeitpunkt. Unternehmen wollen, dass Agenten mehr leisten als Informationen zusammenzufassen, während Regulierungsbehörden und Sicherheitsteams klarere Verantwortlichkeit fordern. Dieser Druck macht Laufzeitkontrollen zu einer Anforderung statt zu einer optionalen Funktion.

Dennoch steigt die Beweislast mit der Autonomie. Je mehr Befugnisse ein Agent erhält, desto mehr Nachweise benötigen Käufer dafür, dass Identitäten, Berechtigungen, Richtlinien und Audit-Aufzeichnungen unter Angriff gemeinsam funktionieren.

Organisationen, die die KI-Sicherheitsintegration von Thales und Google Cloud bewerten, sollten mit einem abgegrenzten Workflow und einem definierten Fehlertoleranzbudget beginnen. Erfassen Sie jedes Tool, jeden Zugangsnachweis, jede Datenquelle und jede irreversible Aktion. Testen Sie anschließend, ob die Kontrollen Missbrauch verhindern, ohne Nutzende mit Genehmigungen zu überlasten.

Die entscheidende Frage ist praktisch: Kann die Partnerschaft die weitreichenden Fähigkeiten eines Agenten bei jeder Änderung des Workflows in eng begrenzte, autorisierte Handlungen überführen? Messungen im Produktiveinsatz, interoperable Identitäten und unabhängige Tests werden die Antwort liefern.