Agentische KI zwingt Zero Trust zur Bewältigung einer Identitätskrise

Agentische KI erreichte Google News mit einer drastischen Behauptung: Autonome Systeme stellen die Zero-Trust-Cybersicherheit „auf den Kopf“. Die Schlagzeile von Breaking Defense benennt einen realen Konflikt, auch wenn die zugrunde liegenden Details weiterhin schwer unabhängig zu verifizieren sind. Sicherheitsteams haben Zugriffskontrollen rund um Menschen, Geräte und vorhersehbare Anwendungen aufgebaut. KI-Agenten verwischen nun alle drei Kategorien, während sie mit delegierter Autorität handeln.

Das macht Zero Trust nicht obsolet. Es verändert, was Organisationen prüfen müssen, wie häufig sie dies prüfen und welche Identität jede Aktion ausgeführt hat. Ein Agent kann ein Ziel interpretieren, Tools auswählen, externe Inhalte lesen, APIs aufrufen und Daten ändern. Sein Verhalten wird nicht vollständig durch die Berechtigungen seines menschlichen Eigentümers erfasst.

Das Ergebnis ist eine unangenehme Umkehr. Zero Trust geht davon aus, dass jede Anfrage überprüft werden sollte, doch agentische Workflows erzeugen lange Ketten von Anfragen in Maschinengeschwindigkeit. Der zentrale Konflikt lautet daher nicht agentische KI gegen Zero Trust. Es geht um statische Zugriffskontrolle gegenüber kontinuierlicher Kontrolle autonomen Verhaltens.

Die Google-News-Behauptung weist auf einen realen Sicherheitswandel hin

Die entscheidende Veränderung besteht nicht darin, dass KI auf Unternehmenssysteme zugreifen kann, sondern darin, dass sie nach dem Zugriff entscheiden kann, was sie tut.

Traditionelle Software folgt Pfaden, die Entwickler im Voraus festlegen. Sie kann Fehler enthalten, bösartige Eingaben akzeptieren oder verwundbare Schnittstellen offenlegen. Dennoch können Verteidiger ihre vorgesehenen Funktionen in der Regel etablierten Konten, Prozessen und Netzwerkverbindungen zuordnen.

Agentische KI fügt zwischen der Anweisung eines Nutzers und der daraus resultierenden Handlung eine Entscheidungsebene ein. Ein Agent kann ein übergeordnetes Ziel in kleinere Aufgaben aufteilen, aus verfügbaren Tools auswählen und sich anpassen, wenn ein Weg scheitert. NIST beschreibt moderne Agenten als Allzweckmodelle in Kombination mit Software, die es ihnen ermöglicht, Tools über die Textgenerierung hinaus zu bedienen.

Zu diesen Tools können Browser, Datenbanken, Kalender, Code-Interpreter, lokale Dateien und administrative Schnittstellen gehören. Die Tool-Use-Taxonomie von NIST unterscheidet zwischen schreibgeschütztem Zugriff sowie eingeschränktem oder uneingeschränktem Schreibzugriff. Sie trennt zudem vertrauenswürdige von nicht vertrauenswürdigen Umgebungen.

Diese Unterscheidung ist wichtig, weil ein einzelner Agent während eines Auftrags oft mehrere Kategorien überschreitet. Er könnte eine E-Mail lesen, eine Kundennummer extrahieren, eine interne Datenbank abfragen und einen Support-Vorgang aktualisieren. Jeder Schritt kann bei isolierter Betrachtung erlaubt erscheinen.

Der kombinierte Workflow kann dennoch zu einem unsicheren Ergebnis führen. Ein Angreifer könnte versteckte Anweisungen in der E-Mail platzieren. Der Agent könnte diese Anweisungen als Teil seiner Aufgabe interpretieren und anschließend legitime Berechtigungen nutzen, um Daten offenzulegen.

Dieser Angriff wird als indirekte Prompt Injection bezeichnet. Dabei erreichen bösartige Anweisungen einen Agenten über Inhalte, die er verarbeitet. Der Angreifer benötigt nicht das Passwort des Mitarbeiters. Er zielt auf die Interpretation vertrauenswürdiger und nicht vertrauenswürdiger Informationen durch den Agenten.

Die Google-News-Schlagzeile erfasst diesen Wandel mit der Formulierung „auf den Kopf“. Zuvor sorgten sich Sicherheitsteams darum, dass Menschen Software missbrauchen oder Zugangsdaten preisgeben könnten. Nun müssen sie auch Software berücksichtigen, die die Autorität einer Person interpretiert und innerhalb dieses Rahmens eigenständig handelt.

Dies ist nicht bloß ein weiterer Endpunkt im Netzwerk. Ein Endpunkt hat normalerweise eine relativ stabile Funktion, Sicherheitslage und ein stabiles Eigentumsmodell. Ein Agent kann seinen unmittelbaren Plan ändern, während er dieselbe Identität, dieselben Zugangsdaten und dieselbe Verbindung behält.

Dadurch entsteht ein Sichtbarkeitsproblem. Ein Protokoll kann zeigen, dass ein gültiges Servicekonto auf eine Datenbank zugegriffen hat. Es zeigt möglicherweise nicht, welcher Nutzer die Aufgabe initiiert hat, welcher Agent den Plan erstellt hat oder welche externe Eingabe die Entscheidung beeinflusste.

Die Schlagzeile sollte dennoch als These und nicht als Beweis für einen konkreten Sicherheitsvorfall behandelt werden. Dem bereitgestellten Google-News-Beitrag liegen keine verifizierten Vorfallsdetails bei. Das umfassendere Sicherheitsproblem wird jedoch durch öffentliche Forschung und laufende Standardisierungsarbeit gestützt.

Sicherheitsteams schützen nicht mehr nur Zugriffe von Menschen auf Anwendungen und von Anwendungen auf Anwendungen. Sie müssen eine Kette absichern, die einen Menschen, einen Agenten, ein Modell, mehrere Tools und mehrere Datenquellen verbindet. Vertrauen kann bei jeder Übergabe verloren gehen.

Zero Trust wurde für Anfragen entwickelt, nicht für offene Ziele

Zero Trust bleibt relevant, doch seine herkömmliche Kontrolleinheit ist für autonome Arbeit zu eng gefasst.

NIST veröffentlichte seine grundlegende Zero-Trust-Architektur im Jahr 2020. Das Modell lehnt implizites Vertrauen aufgrund des Netzwerkstandorts oder des Eigentums an einem Asset ab. Authentifizierung und Autorisierung erfolgen, bevor eine Sitzung eine Unternehmensressource erreicht.

Die Architektur konzentriert sich auf Ressourcen statt auf traditionelle Netzwerksegmente. Sie geht davon aus, dass ein Netzwerk möglicherweise bereits kompromittiert wurde. Der Zugriff sollte daher auf die kleinste Berechtigungsmenge beschränkt bleiben, die für eine bestimmte Aufgabe erforderlich ist.

Dieser Ansatz wirkt dem alten Perimetermodell entgegen. Bei Perimetersicherheit erhielten authentifizierte Nutzer nach dem Eintritt in ein vertrauenswürdiges Netzwerk häufig umfassenden Zugriff. Angreifer konnten sich dann nach der Kompromittierung eines Kontos oder Geräts lateral zwischen Systemen bewegen.

Agentische KI widerlegt diese Grundsätze nicht. Tatsächlich werden Least Privilege und kontinuierliche Überprüfung wichtiger, wenn Maschinen viele Aktionen schnell ausführen können. Die Schwierigkeit besteht darin, ein weit gefasstes Nutzerziel in durchsetzbare, kurzlebige Berechtigungen zu übersetzen.

Betrachten wir einen Agenten, der einen vierteljährlichen Bericht über Kundenrisiken erstellen soll. Die Aufgabe klingt informativ, doch ihre Erledigung kann mehrere Fähigkeiten erfordern. Der Agent muss Datensätze finden, Daten zusammenführen, Trends berechnen und ein Dokument erstellen.

Sollte der Agent während des gesamten Auftrags Zugriff auf jeden Kundendatensatz erhalten? Sollte er diese Berechtigungen danach behalten? Kann er den Bericht per E-Mail versenden, oder sollte die Verteilung eine separate Genehmigung erfordern?

Ein herkömmliches Zugriffssystem kann diese Fragen anhand der bestehenden Rolle des Nutzers beantworten. Wenn der Mitarbeiter die Datenbank lesen und E-Mails versenden darf, erbt der Agent beide Befugnisse. Diese Vererbung ist einfach, schafft jedoch übermäßige Autorität.

Der Agent kann Kombinationen von Aktionen ausführen, die der Mitarbeiter nie beabsichtigte. Er kann sie zudem in einem Umfang wiederholen, den manuelle Workflows selten erreichen. Ein kleiner Interpretationsfehler kann zu Hunderten von Datenbankabfragen oder Nachrichten werden.

Offene Ziele erschweren die Gestaltung von Richtlinien. „Finde die relevanten Belege“ legt nicht fest, welche Repositories durchsucht werden sollen. „Löse das Problem“ definiert nicht, ob der Agent eine Rückerstattung veranlassen, ein Konto ändern oder Code ausführen darf.

Zero Trust bewertet Zugriffsanfragen traditionell anhand von Identität, Gerätezustand, Sensibilität der Ressource und Umgebungskontext. Agentische Systeme fügen eine weitere Frage hinzu: Bleibt diese Aktion mit der Aufgabe vereinbar, die den Zugriff rechtfertigte?

Diese Frage erfordert absichtsbezogene Kontrollen. Diese Kontrollen vergleichen eine Aktion mit dem zugewiesenen Zweck des Agenten, seinem aktuellen Plan und der genehmigten Richtlinie. Sie können sich nicht allein darauf stützen, ob ein Konto technisch über eine Berechtigung verfügt.

Die Sicherheitsgrenze verschiebt sich auch bei Multi-Agenten-Arbeit. Ein Agent kann die Recherche an einen anderen Agenten delegieren. Dieser zweite Agent kann einen Drittanbieterdienst aufrufen, der Inhalte mit neuen Anweisungen zurückgibt.

Jede Übergabe kann den Kontext verändern und zugleich die scheinbare Autorisierung erhalten. Eine statische Richtlinie sieht genehmigte Identitäten, die Daten weitergeben. Eine verhaltensbasierte Richtlinie muss feststellen, ob die gesamte Kette weiterhin dem ursprünglichen Ziel dient.

Deshalb kann die Sicherheit agentischer KI nicht bei der Netzwerksegmentierung enden. Die Kontrollebene muss Identitäten, Aufgaben, Tools, Datenherkunft und Aktionsverlauf verstehen. Sie muss diese Beziehungen zudem für spätere Untersuchungen bewahren.

Das ursprüngliche Zero-Trust-Versprechen gilt weiterhin: Vertrauen darf niemals allein deshalb gewährt werden, weil sich etwas bereits innerhalb befindet. Agentische Workflows zeigen lediglich, dass „innerhalb“ ein Kontextfenster, eine delegierte Aufgabe oder eine Tool-Kette beschreiben kann. Es bezieht sich nicht mehr nur auf ein Netzwerk.

KI-Agenten benötigen von ihren Eigentümern getrennte Identitäten

Eine Organisation kann einen autonomen Agenten nicht steuern, wenn jede Aktion unter einem menschlichen oder gemeinsam genutzten Servicekonto erscheint.

Identität ist der erste Druckpunkt für Sicherheitsverantwortliche in Unternehmen. Menschen haben Personalakten, Vorgesetzte, Tätigkeitsrollen und Austrittsprozesse. Anwendungen haben Eigentümer, Release-Prozesse und Servicekonten.

Agenten vereinen Merkmale beider Gruppen. Sie können Ziele von Menschen erhalten, führen sie jedoch über Software aus. Sie können kurz für eine einzelne Aufgabe arbeiten oder als dauerhafte digitale Arbeitskräfte weiterlaufen.

Einen Agenten als versteckte Funktion innerhalb einer Anwendung zu behandeln, verschleiert Verantwortlichkeit. Ihn wie einen normalen Mitarbeiter zu behandeln, schafft ebenfalls falsches Vertrauen. Der Agent benötigt eine eigenständige Maschinenidentität, die mit seinem Eigentümer, Zweck und Einsatz verknüpft ist.

Diese Identität sollte die Identität des auslösenden Nutzers nicht ersetzen. Beide sollten im gesamten Workflow erhalten bleiben. Untersuchende müssen wissen, wer eine Aktion angefordert und welcher Agent sie ausgeführt hat.

Ein hilfreicher Prüfdatensatz sollte zudem das beteiligte Modell, Tool, die Richtlinie und Datenquelle erfassen. Ohne diesen Kontext zeigt ein Datenbankprotokoll nur den finalen Zugriff. Es kann nicht erklären, warum der Agent diesen Zugriff für angemessen hielt.

Sicherheitsteams sollten gemeinsame Zugangsdaten für Agentenbereitstellungen vermeiden. Gemeinsame Konten verhindern eine zuverlässige Zuordnung und erschweren den Entzug von Berechtigungen. Sie ermöglichen es außerdem, dass verlassene Agenten nach dem Ende ihrer ursprünglichen Projekte aktiv bleiben.

Eine Agentenidentität benötigt einen Lebenszyklus. Bei der Erstellung sollten ein verantwortlicher Eigentümer und ein genehmigter Anwendungsfall festgelegt werden. Regelmäßige Überprüfungen sollten bestätigen, dass der Agent weiterhin notwendig ist und seine Berechtigungen noch seinem Zweck entsprechen.

Ablauf ist ebenso wichtig. Temporäre Agenten sollten ihren Zugriff verlieren, wenn eine Aufgabe oder ein Projekt endet. Dauerhafte Agenten sollten regelmäßig erneut zertifiziert werden, ähnlich wie privilegierte menschliche Konten.

Berechtigungen sollten zudem aufgabenbezogen und kurzlebig sein. Ein Agent, der einen Bericht vorbereitet, kann vorübergehenden Lesezugriff auf ausgewählte Datensätze erhalten. Das Versenden dieses Berichts außerhalb der Organisation sollte eine separate Berechtigung oder menschliche Bestätigung erfordern.

Dieses Design verringert Privilege Creep, das auftritt, wenn Identitäten Zugriffe ansammeln, die nicht mehr ihren Verantwortlichkeiten entsprechen. Privilege Creep ist bereits bei Mitarbeitern schwer zu handhaben. Autonome Agenten können das Problem vervielfachen, weil Teams sie schnell erstellen können.

Die Erkennung von Agenten wird daher zu einer betrieblichen Anforderung. Sicherheitsteams benötigen ein Inventar über SaaS-Dienste, Entwicklungsplattformen, interne Automatisierungssysteme und Drittanbieterintegrationen hinweg. Beschaffungsunterlagen allein identifizieren keine Agenten, die innerhalb bestehender Produkte erstellt wurden.

Die Erkennung muss zwischen einer KI-Funktion und einer handelnden Identität unterscheiden. Eine Zusammenfassungsfunktion, die nur ein Dokument liest, birgt andere Risiken als ein Agent, der Laufwerke durchsuchen und Nachrichten versenden kann. Beide können dasselbe Modell verwenden.

Der Eigentümer sollte auch in Richtlinien und Protokollen sichtbar sein. Wenn ein Agent außerhalb der Erwartungen handelt, benötigen Reaktionsverantwortliche eine Person oder ein Team, das ihn sperren kann. Anonyme Automatisierung verursacht Verzögerungen bei Vorfällen.

Organisationen verwenden bereits nicht-menschliche Identitäten für Dienste, Workloads und Maschinen. Agentenidentitäten erweitern diese Disziplin, statt sie zu ersetzen. Der Unterschied besteht darin, dass Richtlinien variables Verhalten innerhalb derselben zugewiesenen Rolle berücksichtigen müssen.

Große Sicherheitsanbieter bewegen sich in diese Richtung. Cisco kündigte in seinem Sicherheitsupdate für Agenten Agentenerkennung, agentische Identitätskontrollen und die Durchsetzung des Model Context Protocol an. Das Model Context Protocol, kurz MCP, verbindet Modelle mit Tools und externen Daten.

Ankündigungen von Anbietern sind kein unabhängiger Beleg dafür, dass diese Kontrollen in jeder Bereitstellung funktionieren. Sie zeigen jedoch, wohin sich der Wettbewerb entwickelt. Identitätsplattformen, Zugriffsbroker und Sicherheitsgateways wollen allesamt zum Kontrollpunkt für Agentenverkehr werden.

Unternehmen sollten der Versuchung widerstehen, ein einzelnes Gateway als vollständige Lösung zu betrachten. NIST weist seit Langem darauf hin, dass kein einzelner Anbieter eine komplette Zero-Trust-Architektur liefert. Agentische Sicherheit fügt weitere Komponenten und zusätzliche Möglichkeiten für inkonsistente Durchsetzung hinzu.

Der unmittelbare Druck lastet auf Teams für Identity and Access Management. Sie müssen rasch erstellte maschinelle Akteure unterstützen, ohne das Problem unverwalteter Servicekonten zu wiederholen. Statische Rollenzuweisungen werden nicht ausreichen.

Agent Hijacking zeigt die Grenzen statischer Berechtigungsprüfungen

Ein korrekt authentifizierter Agent kann dennoch die falsche Aktion ausführen, weil Authentifizierung seine Schlussfolgerungen nicht validiert.

Das stärkste Argument für eine Überarbeitung von Zero Trust liefert die Forschung zu Agent Hijacking. Im März 2026 berichtete NIST über die Ergebnisse eines großen öffentlichen Red-Teaming-Wettbewerbs mit 13 führenden Modellen. Mehr als 400 Teilnehmende unternahmen über 250.000 Angriffsversuche.

Gegen jedes getestete Modell wurde mindestens ein erfolgreicher Hijacking-Angriff gefunden. Die Modelle unterschieden sich in ihrer Widerstandsfähigkeit, doch Leistungsfähigkeit sagte Sicherheit nicht durchgängig voraus. Einige Angriffsfamilien ließen sich zudem auf verschiedene Modelle und Szenarien übertragen.

Diese Ergebnisse bedeuten nicht, dass jeder eingesetzte Agent leicht kompromittiert werden kann. Ein Wettbewerb zieht gezielt agierende Angreifer an und bildet möglicherweise nicht jede Produktionskontrolle ab. Er zeigt jedoch, dass Widerstandsfähigkeit auf Modellebene allein nicht als Sicherheitsgrenze dienen kann.

NIST definiert Agent Hijacking als einen Angriff, bei dem bösartige Anweisungen in Daten platziert werden, die ein Agent verarbeitet. Ziel ist es, den Agenten zu schädlichem Verhalten umzulenken. Mögliche Folgen sind Datenexfiltration oder die Ausführung schädlichen Codes.

Das entscheidende Detail: Der Agent nutzt dabei häufig gültige Tools und Zugangsdaten. Eine Firewall sieht möglicherweise eine genehmigte Verbindung. Ein Identitätssystem sieht möglicherweise ein authentifiziertes Konto. Der gefährliche Schritt erfolgt bei der Interpretation von Inhalten durch den Agenten.

Damit sind statische Allowlists unvollständig. Einem Agenten zu erlauben, E-Mails zu lesen und eine Datenbank zu aktualisieren, kann für seine Aufgabe erforderlich sein. Die Richtlinie muss dennoch verhindern, dass eine E-Mail neu definiert, was das Datenbank-Tool tun soll.

Die relevanten Red-Team-Erkenntnisse sprechen für Defense in Depth. Modelle müssen bewertet werden, doch Bereitstellungen benötigen zudem eingeschränkte Tools, Datengrenzen, Monitoring und Freigabepunkte.

Tool-Berechtigungen sollten die Konsequenzen widerspiegeln, nicht die Bequemlichkeit. Das Lesen einer öffentlichen Webseite birgt andere Risiken als die Ausführung heruntergeladenen Codes. Die Abfrage eines Kundendatensatzes unterscheidet sich vom Löschen oder Exportieren dieses Datensatzes.

Tools mit hoher Wirkung sollten eng abgegrenzte Operationen bereitstellen. Ein Agent, der ein Meeting planen muss, sollte nicht uneingeschränkte Kontrolle über das Postfach erhalten. Ein Finanzagent, der eine Zahlung vorbereitet, sollte diese nicht zugleich genehmigen und übermitteln.

Dieses Prinzip wird Funktionstrennung genannt. Es verhindert, dass eine Identität jeden Schritt eines sensiblen Prozesses kontrolliert. Agentische Systeme benötigen dieselbe Trennung, auch wenn Automatisierung eine Bündelung verlockend macht.

Menschliche Freigaben bleiben an unumkehrbaren Grenzen sinnvoll. Überweisungen, Löschungen, externe Veröffentlichungen, Produktionsdeployments und Änderungen von Zugangsdaten verdienen explizite Prüfungen. Die Freigabe sollte die beabsichtigte Aktion und den relevanten Kontext anzeigen.

Ein generischer „Zulassen“-Button bietet kaum Schutz. Die prüfende Person muss wissen, welcher Agent die Aktion angefordert hat, welche Daten er verwendet hat und welche Wirkung die Freigabe erzeugt. Andernfalls verlagert die Automatisierung Social Engineering lediglich auf den Freigabebildschirm.

Das Monitoring sollte sich auf Verhaltensänderungen konzentrieren. Wenn ein Agent plötzlich auf unbekannte Repositories zugreift, kann dies auf Hijacking oder fehlerhafte Planung hindeuten. Wiederholte fehlgeschlagene Tool-Aufrufe können signalisieren, dass ein Agent seine Rolle austestet.

Rate Limits reduzieren ebenfalls den Schaden durch Fehler. Ausführung mit Maschinengeschwindigkeit kann aus einer einzelnen Fehlentscheidung einen weitreichenden Vorfall machen. Die Begrenzung des Aktionsvolumens gibt Monitoring-Systemen und Incident-Response-Teams Zeit zum Eingreifen.

Sandboxing bleibt wertvoll, sollte aber nicht zu einer falschen Sicherheitsannahme führen. Ein Agent kann Schaden anrichten, ohne seiner Laufzeitumgebung zu entkommen. Autorisierte Daten an das falsche Ziel zu senden, erfordert möglicherweise keinen Software-Exploit.

Die zentrale Unsicherheit besteht darin, ob absichtsorientierte Systeme zuverlässige Entscheidungen treffen können, ohne nützliche Arbeit zu blockieren. Agentenpläne ändern sich, Geschäftsaufgaben enthalten Mehrdeutigkeiten, und Richtlinien können nicht jede legitime Ausnahme vorhersehen.

Übermäßig strenge Kontrollen führen zu ständigen Freigabeanfragen. Teams könnten dann weitergehende Berechtigungen vergeben, um die Produktivität wiederherzustellen. Diese Reaktion stellt genau jenes implizite Vertrauen wieder her, das Zero Trust beseitigen sollte.

Übermäßig permissive Kontrollen führen zum gegenteiligen Versagen. Agenten arbeiten reibungslos, bis eine bösartige Eingabe oder ein Planungsfehler ihre Befugnisse ausnutzt. Sicherheitsteams müssen sowohl blockierte Arbeit als auch unsichere Aktionen messen.

Dieser Zielkonflikt verhindert einfache Behauptungen, ein „agentisches Zero-Trust“-Produkt habe das Problem gelöst. Produktdemonstrationen zeigen üblicherweise ausgewählte Workflows. Reale Bereitstellungen umfassen Altsysteme, gemeinsame Identitäten und inkonsistente Logs.

Der glaubwürdigste kurzfristige Ansatz ist mehrschichtig. Geben Sie jedem Agenten eine Identität, beschränken Sie jedes Tool, bewahren Sie den auslösenden Nutzer, validieren Sie folgenreiche Aktionen und überwachen Sie das Verhalten. Gehen Sie davon aus, dass Schutzmaßnahmen auf Modellebene gelegentlich versagen.

Der Wettbewerb verlagert sich in die Control Plane

Sicherheitsanbieter konkurrieren darum, Agentenverhalten zu vermitteln, während Unternehmen weiterhin ein gemeinsames Modell fehlt, um die Wirksamkeit dieser Vermittlung nachzuweisen.

Agentische KI schafft Chancen für Identitätsanbieter, Netzwerksicherheitsanbieter, Cloud-Plattformen und spezialisierte KI-Sicherheitsunternehmen. Jede Gruppe kontrolliert einen anderen Teil des Workflows. Keine hat automatisch Einblick in die gesamte Kette.

Identitätsanbieter wissen, wer Zugriff erhalten hat. Netzwerkplattformen beobachten Verbindungen zwischen Systemen. Cloud-Anbieter können Workloads und API-Aufrufe überwachen. KI-Sicherheitstools prüfen Prompts, Modellausgaben und Tool-Anfragen.

Die wertvolle Position ist der Entscheidungspunkt für Richtlinien. In einer Zero-Trust-Architektur bewertet diese Komponente den Zugriff und entscheidet, ob die Durchsetzung ihn erlauben sollte. Agentische Systeme machen diese Entscheidung umfassender und umstrittener.

Ein Netzwerkanbieter könnte argumentieren, dass Agentenkommunikation über einen Sicherheitsbroker laufen sollte. Ein Identitätsanbieter könnte die Richtlinie auf Maschinenidentitäten und delegierte Autorisierung ausrichten. Ein KI-Sicherheitsanbieter könnte die Prompt-Prüfung und Verhaltensbewertung priorisieren.

Alle drei Sichtweisen enthalten einen Teil der Antwort. Netzwerkkontext kann nicht jede bösartige Anweisung erkennen. Prompt-Prüfung kann eine blockierte Datenbankabfrage nicht allein durchsetzen. Identitätsprüfung kann nicht garantieren, dass ein authentifizierter Agent seinem Zweck folgt.

MCP ist zu einem Schwerpunkt geworden, weil es Verbindungen zwischen Modellen und Tools standardisiert. Ein Gateway kann Server inventarisieren, Operationen einschränken und Aufrufe protokollieren. Allerdings verwendet nicht jeder Agent MCP, und ein Gateway kann Tools nicht steuern, die es umgehen.

Agent-zu-Agent-Kommunikation stellt eine weitere Herausforderung dar. Delegation kann Modelle, Anbieter oder Organisationsgrenzen überschreiten. Der empfangende Agent benötigt Nachweise über Identität, Befugnis und angeforderten Umfang des Senders.

Eine signierte Nachricht kann den Sender authentifizieren. Sie beweist nicht, dass dessen Plan sicher ist. Richtlinien müssen zwischen Provenienz, die angibt, woher eine Anfrage stammt, und Autorisierung, die bestimmt, ob sie fortgesetzt werden darf, unterscheiden.

Die Standardisierungsarbeit beginnt, diese Lücken zu schließen. NIST startete im Februar 2026 seine Initiative für Agentenstandards. Auf ihrer Agenda stehen Interoperabilität, offene Protokolle, Sicherheit, Identität und vertrauenswürdige Einführung.

Diese Initiative ist wichtig, weil Organisationen vergleichbare Darstellungen von Agentenidentität und Befugnis benötigen. Ohne gemeinsame Formate erstellt jede Plattform proprietäre Identitäten und Richtliniensignale. Sicherheitsteams haben dann Schwierigkeiten, Kontrollen über verschiedene Umgebungen hinweg durchzusetzen.

Standards allein können die Risikotoleranz nicht festlegen. Ein Krankenhaus, eine Bank, ein Rüstungsunternehmen und eine Marketingagentur werden derselben Tool-Aktion unterschiedliche Konsequenzen beimessen. Interoperabilität liefert gemeinsame Infrastruktur, keine universelle Richtlinie.

Die Perspektive von Breaking Defense ist besonders für Umgebungen mit hohen Sicherheitsanforderungen relevant. Verteidigungssysteme kombinieren oft klassifizierte Daten, Einsatzvorgaben, Altsysteme und strikte Rechenschaftspflichten. Eine autonome Aktion kann Folgen haben, die über gewöhnliche Büroautomatisierung hinausgehen.

Diese Umgebungen erzeugen zugleich Druck zur Automatisierung. Analysten stehen großen Mengen an Warnmeldungen, Dokumenten und Sensordaten gegenüber. Agenten können helfen, Informationen zu korrelieren und wiederkehrende Schritte auszuführen, doch größere Autonomie erhöht den Bedarf an nachvollziehbarer Kontrolle.

Der Wettbewerb sollte daher anhand von Nachweisen bewertet werden, nicht anhand von Produktvokabular. Käufer müssen testen, ob eine Kontrolle Agenten zuverlässig identifiziert, Aktionen an Verantwortliche bindet, Tools begrenzt und nutzbare Audit-Aufzeichnungen erzeugt.

Sie sollten auch Ausfallfälle testen. Was geschieht, wenn der Identitätsanbieter nicht verfügbar ist? Kann ein Agent auf zwischengespeicherte Berechtigungen zurückgreifen? Failt ein Broker geschlossen, oder umgeht der Verkehr die Prüfung?

Plattformübergreifende Abdeckung ist ebenso wichtig wie einzelne Funktionen. Eine Organisation kann ein Cloud-Modell, den Coding-Agenten eines anderen Anbieters und mehrere SaaS-Assistenten nutzen. Eine Kontrolle, die nur eine Umgebung sieht, lässt erhebliche blinde Flecken.

Der Markt wird sich wahrscheinlich um integrierte Plattformen konsolidieren, doch Integration kann ein eigenes Konzentrationsrisiko schaffen. Eine kompromittierte Policy Plane könnte viele Agenten betreffen. Unabhängige Protokollierung und Durchsetzung bleiben wichtige Schutzmaßnahmen.

Google News mag Schlagzeilen verstärken, wonach agentische KI vertraute Sicherheitsmodelle ersetzt. Die zutreffendere Schlussfolgerung ist enger gefasst. Bestehende Anbieter müssen Zero Trust von Verbindungsentscheidungen auf die Steuerung von Identität, Absicht und Aktionen ausweiten.

Worauf Sicherheitsteams als Nächstes achten sollten

Die nächste Phase wird durch messbare Nachweise aus Bereitstellungen entschieden, nicht durch weiter gefasste Behauptungen über autonome Sicherheit.

Das erste Signal ist, ob Standardisierungsgremien nutzbare Spezifikationen für Agentenidentität und delegierte Autorisierung hervorbringen. NIST erklärte, seine Initiative werde Forschung, Leitlinien und weitere Ergebnisse entwickeln. Unternehmen sollten auf Formate achten, die anbieterübergreifend funktionieren.

Eine nützliche Identitätsspezifikation muss einen Agenten mit einem Eigentümer, Zweck, Modell und genehmigten Tools verknüpfen. Sie sollte auch den auslösenden Nutzer bei Delegation bewahren. Wenn Plattformen inkompatible Darstellungen übernehmen, bleibt die Governance fragmentiert.

Das zweite Signal sind unabhängige Sicherheitstests. NISTs Wettbewerb fand erfolgreiche Angriffe gegen jedes getestete führende Modell, doch Organisationen benötigen Bewertungen auf Ebene der Bereitstellung. Tests sollten Modelle, Tools, Berechtigungen, Speicher und externe Daten umfassen.

Vergleichstests sollten mehr messen als den Erfolg von Prompt-Injection-Angriffen. Sie sollten untersuchen, ob Agenten den Aufgabenrahmen überschreiten, legitime Tools missbrauchen oder folgenreiche Aktionen in langen Workflows verbergen. Sie sollten außerdem Wiederherstellung und Audit-Qualität testen.

Wenn die Erfolgsquote von Angriffen sinkt, während Agenten nützliche Fähigkeiten behalten, wird das Vertrauen in absichtsorientierte Kontrollen wachsen. Bleiben verbesserte Modelle in toolreichen Deployments anfällig, werden Infrastrukturkontrollen noch wichtiger.

Das dritte Signal ist das Verhalten von Unternehmen nach Pilotprojekten. Sicherheitsteams sollten verfolgen, wie viele Agenten eindeutige Identitäten, eingeschränkte Berechtigungen und klar definierte Verantwortliche erhalten. Sie sollten außerdem aufgegebene Agenten und ungeprüfte Berechtigungen messen.

Allein Adoptionszahlen sagen wenig aus. Ein Unternehmen kann Tausende von Agenten einsetzen und sie dabei schreibgeschützt und isoliert halten. Ein einzelner Agent mit weitreichendem Produktionszugriff kann ein größeres Risiko darstellen als diese gesamte Population.

Vorfallberichte werden einen weiteren Realitätscheck liefern. Öffentliche Fälle sollten erklären, ob Fehler durch Prompt Injection, übermäßige Berechtigungen, Identitätsverwechslungen oder fehlende Freigabegrenzen entstanden sind. Ohne diese Details kann die Branche Abwehrmaßnahmen nicht vergleichen.

Sicherheitsverantwortliche sollten vor der Ausweitung eines Pilotprojekts direkte Fragen stellen:

• Hat jeder Agent eine eindeutige Identität und einen verantwortlichen Eigentümer?

• Können Berechtigungen automatisch ablaufen, wenn die Aufgabe endet?

• Bewahren Protokolle sowohl die anfragende Person als auch den handelnden Agenten auf?

• Welche Tools können irreversible Änderungen vornehmen?

• Können externe Inhalte diese Tool-Aufrufe beeinflussen?

• Welches Aktionsvolumen löst eine Überprüfung oder Aussetzung aus?

• Können Incident-Responder einen einzelnen Agenten deaktivieren, ohne die gesamte Plattform anzuhalten?

• Sind delegierte Agenten durch die ursprüngliche Aufgabe begrenzt?

• Schlägt das System sicher fehl, wenn Policy-Dienste nicht verfügbar sind?

• Können Auditoren nachvollziehen, warum eine sensible Aktion erfolgte?

Diese Fragen machen die Behauptung, alles „auf den Kopf zu stellen“, zu einem Implementierungstest. Kann eine Plattform sie nicht beantworten, bleibt ihre Zero-Trust-Sprache unvollständig. Kann sie es, passt sich die Architektur möglicherweise bereits an.

Die wichtigste Schlussfolgerung ist, dass Unternehmen Zero Trust nicht aufgeben sollten. Sie sollten es auf kleinere, dynamischere Einheiten von Autorität anwenden. Jeder Agent, jeder Tool-Aufruf, jede Delegation und jede folgenschwere Aktion verdient ihren eigenen Policy-Kontext.

Dieser Ansatz wird Reibung erzeugen. Einige automatisierte Aufgaben werden enger begrenzte Tools oder eine menschliche Bestätigung erfordern. Einige Pilotprojekte werden sich verlangsamen, während Teams Inventare und Lifecycle-Kontrollen aufbauen.

Die Alternative ist verborgene Autorität. Agenten werden weitreichende menschliche Berechtigungen übernehmen, nicht vertrauenswürdige Inhalte verarbeiten und unvollständige Aufzeichnungen hinterlassen. Sicherheitsteams werden autonome Workflows dann erst nach einem Vorfall entdecken.

Agentic AI hat Zero Trust nicht besiegt. Sie hat offengelegt, wo viele Zero-Trust-Programme bei Authentifizierung, Netzwerkzugriff oder Gerätezustand stehen geblieben sind. Die nächste Version muss regeln, was authentifizierte Maschinen zu tun beschließen.

Die über Google News aufgeworfene Frage ist daher es wert, beibehalten zu werden, auch wenn die Überschrift die Umkehr überzeichnet. Kann Ihr Unternehmen die Identität, den Zweck, die Evidenz und die Autorität eines Agenten nachverfolgen, bevor seine nächste Aktion ausgeführt wird?

Beginnen Sie mit einem Produktionsworkflow und rekonstruieren Sie diese Kette von Anfang bis Ende. Wenn irgendeine Übergabe unsichtbar wird, behandeln Sie sie als Kontrolllücke. Diese Übung bietet mehr Nutzen als die Einführung eines weiteren Sicherheitslabels, weil sie prüft, ob Zero Trust dem Agenten bei der tatsächlichen Arbeit folgt.