Israels Cyberbranche setzt auf Identität als nächstes Schlachtfeld der KI-Sicherheit

Israels Cyberbranche hat eine klare Wette abgeschlossen, die nun in Google News zunehmend sichtbar wird: Identitätskontrollen werden zur ersten Verteidigungslinie gegen autonome KI-Agenten.

Diese Wette verändert, wie Sicherheitsanbieter die KI-Bedrohung definieren. Das unmittelbare Problem beschränkt sich nicht länger auf bösartige Prompts, unsichere Modellausgaben oder vertrauliche Daten, die in einen Chatbot gelangen. Zunehmend geht es um Software-Agenten, die Zugangsdaten erhalten, Tools aufrufen und Geschäftssysteme ohne fortlaufende menschliche Genehmigung verändern.

Israelische Unternehmen wie CyberArk, Oasis Security, Apono, Silverfort und Astrix Security gehen das Problem aus unterschiedlichen Positionen an. Dennoch ist ihre Ausrichtung bemerkenswert einheitlich. Jedes behandelt einen KI-Agenten als aktive Identität, deren Zugriffe entdeckt, begrenzt, überwacht und widerrufen werden müssen.

Der entstehende Wettbewerb ist daher größer als eine einzelne Produktkategorie. Herkömmliche Identitätssysteme erteilen Berechtigungen für vorhersehbare Nutzer und Anwendungen. Das neuere Modell muss Software steuern, die Anweisungen interpretiert, Tools auswählt, Arbeit delegiert und ihr Verhalten mit wechselndem Kontext anpasst.

Daraus entsteht die zentrale Spannung. Unternehmen wollen, dass Agenten nützliche Arbeit erledigen, ohne bei jedem Schritt auf eine Freigabe zu warten. Sicherheitsteams benötigen ausreichend Kontrolle, um zu verhindern, dass ein kompromittierter Agent legitimen Zugriff in authentifizierten Missbrauch verwandelt.

Die israelische Wette entwickelt sich von einer Finanzierungsthese zur Produktstrategie

Identitätssicherheit ist zu einem praktischen Produktwettlauf geworden, weil KI-Agenten beginnen, die Grenze zwischen dem Generieren von Antworten und dem Ausführen von Handlungen zu überschreiten.

Die Belege sind bei mehreren israelischen Anbietern sichtbar. CyberArk führte Secure AI Agents als Erweiterung seiner Identity-Security-Plattform ein. Das Produkt wendet Berechtigungskontrollen auf autonome Agenten in Cloud-, Software- und Entwicklerumgebungen an.

Oasis Security hat sich von der Erkennung nichtmenschlicher Identitäten hin zu dem entwickelt, was das Unternehmen als agentic access management bezeichnet. Der Ansatz bewertet, was ein Agent erreichen will, bevor er eng begrenzte Berechtigungen für diese Aufgabe erteilt.

Apono brachte Agent Privilege Guard nach demselben Prinzip auf den Markt. Der Dienst verknüpft Agentenaktivitäten mit Just-in-Time-Zugriff, sodass Zugangsdaten nur verfügbar werden, wenn eine konkrete Aktion sie erfordert. Diese Berechtigungen können anschließend ablaufen, statt dauerhaft an ein Konto gebunden zu bleiben.

Silverfort und Astrix Security kommen aus angrenzenden Bereichen des Identitätsmarktes. Silverfort konzentriert sich darauf, Authentifizierung und Identitätsschutz über Unternehmenssysteme hinweg auszuweiten. Astrix fokussiert sich auf nichtmenschliche Verbindungen, Servicekonten, Tokens und Anwendungszugriffe.

Diese Unternehmen bieten keine identische Technologie an. Einige beginnen mit Erkennung, andere mit privilegiertem Zugriff, Autorisierung oder Bedrohungserkennung. Ihre gemeinsame Prämisse ist wichtiger als ihre Unterschiede: Ein KI-Agent darf keine weitreichenden Befugnisse erben, nur weil ein Mensch seine Aufgabe angestoßen hat.

Diese Prämisse gewann an wirtschaftlichem Gewicht, als Oasis von erheblicher Unternehmensnachfrage und einer großen Finanzierungsrunde berichtete. Laut einem Unternehmensprofil zur Finanzierung erklärte Oasis, dass seine neuen jährlich wiederkehrenden Umsätze gegenüber dem Vorjahr um das Fünffache gestiegen seien.

Das Unternehmen erklärte zudem, die meisten Kunden seien große Unternehmen, von denen viele mehrjährige Verträge abgeschlossen hätten. Diese Angaben wurden in der öffentlichen Berichterstattung nicht unabhängig geprüft. Sie deuten dennoch darauf hin, dass Identitätskontrollen näher an die Budgets für Kerninfrastruktur rücken.

CyberArk lieferte ein weiteres Signal, als das Unternehmen sein Produkt zur Agentensicherheit allgemein verfügbar machte. Die Veröffentlichung zur Agentensicherheit beschrieb Erkennung, sicheren Zugriff, Echtzeiterkennung und Lifecycle-Management als eine zusammenhängende Kontrollebene.

Diese Bündelung ist wichtig. Sie macht KI-Agentensicherheit aus einem spezialisierten Problem der Modellsicherheit zu einer Erweiterung der Identitätsverwaltung. Zum Käufer wird das Team, das bereits für Zugangsdaten, Berechtigungen, privilegierte Konten und Zugriffsprüfungen verantwortlich ist.

Dieser Wandel erklärt auch, warum etablierte Plattformen und jüngere Start-ups im selben Markt konkurrieren können. Große Anbieter verfügen über Unternehmensvertrieb und vorhandene Identitätsdaten. Start-ups können Autorisierung auf kurzlebige, dynamische Agentenaktivitäten ausrichten, ohne Jahrzehnte gewachsener Legacy-Architektur unterstützen zu müssen.

Der Wettlauf geht über die Vorhersage einer künftigen Bedrohung hinaus. Anbieter müssen nun nachweisen, dass ihre Kontrollen in realen Agenten-Workflows funktionieren, ohne diese Workflows unbrauchbar zu verlangsamen.

Warum Google News voller Berichte über KI-Identitätssicherheit ist

Die zunehmende Berichterstattung in Google News spiegelt einen realen Architekturwandel wider: KI-Systeme erhalten die Fähigkeit, über vertrauenswürdige Unternehmensverbindungen zu handeln.

Ein herkömmlicher Chatbot erzeugt Text, den eine Person prüft. Ein KI-Agent kann eine Programmierschnittstelle aufrufen, eine Datenbank abfragen, einen Kundendatensatz aktualisieren oder eine Softwarebereitstellung starten. Jede Aktion hängt von einer Form der Identität und delegierter Befugnis ab.

Diese Befugnis schafft ein größeres Risiko als allein eine falsche Antwort. Ein halluzinierender Chatbot kann seine Leser in die Irre führen. Ein halluzinierender Agent mit Schreibzugriff kann Produktionsdaten verändern, bevor jemand den Fehler bemerkt.

Die Unterscheidung verändert auch die Bedeutung von Authentifizierung. Authentifizierung stellt fest, welche Identität eine Anfrage stellt. Autorisierung bestimmt, ob diese Identität die angeforderte Aktion ausführen darf. Ein Agent benötigt beides, doch keine der Kontrollen reicht aus, wenn sie nur einmal angewendet wird.

Man stelle sich einen Coding-Agenten vor, der einen Produktionsvorfall diagnostizieren soll. Er benötigt möglicherweise Lesezugriff auf Protokolle, zeitweiligen Zugriff auf ein Repository und die Berechtigung, einen Dienst neu zu starten. Permanente Administratorzugangsdaten würden die Aufgabe erleichtern, aber auch den Schaden durch Prompt Injection oder eine Kompromittierung vergrößern.

Ein sichereres Design gibt dem Agenten eine eindeutige Identität und erteilt begrenzte Berechtigungen für die unmittelbare Aufgabe. Das System zeichnet auf, wer die Aktion angefordert hat, welcher Agent sie ausgeführt hat, welche Ressourcen er berührt hat und wann sein Zugriff ablief.

Dieser Ansatz wird oft als Least Privilege, Just-in-Time-Zugriff oder Zero Standing Privilege bezeichnet. Least Privilege beschränkt den Zugriff auf das, was eine Aufgabe erfordert. Just-in-Time-Zugriff gewährt ihn nur bei Bedarf. Zero Standing Privilege entfernt dauerhafte Befugnisse zwischen genehmigten Vorgängen.

Dies sind etablierte Sicherheitskonzepte. Der schwierige Teil besteht darin, sie auf Agenten anzuwenden, die über mehrere Schritte hinweg Schlussfolgerungen ziehen und andere Agenten aufrufen können. Das Autorisierungssystem muss zwischen legitimer Anpassung und Verhalten unterscheiden, das sich außerhalb der genehmigten Aufgabe bewegt hat.

Das Thema ist bedeutsam genug geworden, um Standardisierungsarbeit anzuziehen. Im Februar 2026 kündigte das US National Institute of Standards and Technology eine Initiative an, die sich auf interoperable und sichere KI-Agenten konzentriert.

Seine Initiative zu Agentenstandards umfasst Forschung zu Agenten-Authentifizierung, Identitätsinfrastruktur und sicheren Interaktionen zwischen Menschen und Agenten. NIST schlug zudem Arbeiten zu Autorisierung, Auditierung, Nichtabstreitbarkeit und Kontrollen gegen Prompt Injection vor.

Nichtabstreitbarkeit bedeutet, Nachweise dafür zu schaffen, dass eine identifizierte Partei eine bestimmte Handlung vorgenommen hat. Sie wird schwierig, wenn eine menschliche Anfrage mehrere Agenten, temporäre Zugangsdaten und automatisierte Tool-Aufrufe auslöst.

Google News erfasst daher mehr als eine koordinierte Marketingkampagne. Standardisierungsgremien, etablierte Anbieter, Investoren und Sicherheitsverantwortliche in Unternehmen konzentrieren sich auf denselben ungelösten Kontrollpunkt.

Wiederholte Berichterstattung belegt jedoch nicht, welche Anbieterarchitektur sich durchsetzen wird. Sie zeigt, dass das Problem verständlich genug geworden ist, damit sich mehrere Märkte darum bilden.

Zu diesen Märkten gehören Agentenerkennung, Zugangsdatenverwaltung, Laufzeitautorisierung, Identitätsbedrohungserkennung, Prüfpfade und Richtliniendurchsetzung. Sie werden sich überschneiden, und Käufer werden sich dagegen sträuben, für jede Ebene eine separate Konsole zu betreiben.

Die späteren Gewinner müssen diese Funktionen verbinden, ohne Transparenz mit Kontrolle zu verwechseln. Einen Agenten zu finden, ist nützlich. Seine übermäßigen Berechtigungen aufzuzeigen, ist besser. Eine unsichere Aktion zu verhindern und zugleich legitime Arbeit zu ermöglichen, ist der schwierigere und wertvollere Schritt.

Autonome Agenten setzen traditionelle Zugriffskontrollen unter Druck

Der zentrale Wettbewerb findet zwischen statischen Berechtigungen für vorhersehbare Software und Laufzeitautorisierung für Agenten statt, deren Aktionen sich mit dem Kontext ändern.

Traditionelles Identity and Access Management funktioniert gut, wenn Administratoren eine stabile Beziehung zwischen einem Nutzer, einer Rolle und einer Ressource definieren können. Ein Buchhalter gehört zu einer Finanzgruppe. Ein Server erhält ein Servicekonto. Eine geplante Anwendung verwendet bekannte Zugangsdaten.

KI-Agenten schwächen diese Annahmen. Ein Agent kann in einer Sitzung Dokumente zusammenfassen, in einer anderen einen Projekt-Tracker aktualisieren und in einer dritten Bereitstellungswerkzeuge aufrufen. Seine erforderlichen Befugnisse ändern sich mit Ziel, Umgebung und Daten.

Rollenbasierte Zugriffskontrolle kann dem Agenten eine vordefinierte Rolle zuweisen. Eine weitreichende Rolle riskiert jedoch, mehr Zugriff zu gewähren, als eine Aufgabe erfordert. Für jede temporäre Aufgabe eine neue Rolle zu schaffen, kann zu administrativer Überlastung führen.

Absichtsbasierte Zugriffskontrolle versucht, dieses Problem zu lösen, indem sie die vorgeschlagene Aktion und ihren Zweck zur Laufzeit bewertet. Oasis und Apono verwenden beide Varianten dieser Sprache, auch wenn sich ihre Implementierungen und Durchsetzungspunkte unterscheiden.

Apono erklärt, sein Privilege Guard könne Zugriffsentscheidungen zwischen einen Agenten und die Unternehmensinfrastruktur schalten. Anfragen mit höherem Risiko können eine menschliche Genehmigung auslösen, während zulässige Aufgaben zeitweiligen Zugriff erhalten.

Oasis beschreibt einen Prozess, der die beabsichtigte Arbeit eines Agenten in einen präziseren Aktionsplan umwandelt. Sein System kann dann berechnen, welche Ressourcen und Berechtigungen dieser Plan erfordert.

Das Versprechen ist attraktiv. Ein Agent kann risikoarme Vorgänge weiterführen, während Sicherheitsrichtlinien sensible Aktionen blockieren oder eskalieren. Unternehmen erhalten Automatisierung, ohne dem Modell dauerhaft administrative Befugnisse zu übertragen.

Die Herausforderung liegt darin, die Absicht zuverlässig zu bestimmen. Eine Anfrage in natürlicher Sprache sagt nicht immer die endgültige Abfolge von Tool-Aufrufen voraus. Der Kontext kann sich ändern, externe Daten können feindliche Anweisungen enthalten, und ein Agent kann einen Teil seiner Aufgabe delegieren.

Eine Richtlinien-Engine muss daher mehr bewerten als den ursprünglichen Prompt. Sie benötigt die Identität des Agenten, den menschlichen Auftraggeber, die angeforderte Ressource, die aktuelle Aktion, den Umfang der Zugangsdaten, das Umgebungsrisiko und das vorherige Verhalten.

Diese Anforderung setzt etablierte Identitätsanbieter unter Druck. Ihre bestehenden Systeme enthalten wertvolle Informationen über Nutzer, Gruppen, Konten und Berechtigungen. Möglicherweise fehlt ihnen jedoch detaillierter Kontext dazu, warum ein Agent zu einem bestimmten Zeitpunkt ein bestimmtes Tool aufruft.

Start-ups stehen vor dem umgekehrten Problem. Sie können für dynamisches Agentenverhalten entwickeln, müssen aber viele Clouds, Datenbanken, Softwareplattformen und Identitätsanbieter integrieren. Ein Autorisierungsprodukt kann keine Verbindung schützen, die es nicht sieht.

Der daraus entstehende Wettbewerb ist nicht einfach Start-up gegen etablierten Anbieter. Es ist ein Wettstreit um die Kontrollebene, also die Schicht, in der Organisationen festlegen und durchsetzen, wer was tun darf.

CyberArk bringt Privileged Access Management und bestehende Unternehmensbeziehungen ein. Okta bringt Workforce Identity und Anwendungszugriff ein. Cloud-Plattformen kontrollieren viele der Anmeldedaten, die Agenten nutzen werden. Agent-Entwickler können die Autorisierung zudem in ihre eigenen Frameworks integrieren.

Diese Fragmentierung wirft für Käufer eine unangenehme Frage auf. Soll die Autorität von Agenten in einer Identitätsplattform, einem Cloud-Sicherheitsprodukt, dem Agent-Framework oder einem dedizierten Enforcement-Gateway liegen?

Kontrolle ausschließlich im Agenten zu platzieren, ist riskant, weil ein kompromittierter Agent nicht selbst als vertrauenswürdiger Wächter dienen kann. Jede Entscheidung in ein externes Gateway zu verlagern, kann dagegen Latenz verursachen und Kontext übersehen, der innerhalb des Agenten vorhanden ist.

Die wahrscheinliche Architektur wird die Verantwortung aufteilen. Agent-Frameworks liefern Aufgaben-Kontext und Nachvollziehbarkeit. Unabhängige Richtliniensysteme stellen begrenzte Anmeldedaten aus und setzen Limits durch. Identitätsplattformen verwalten Eigentümerschaft, Lebenszyklus und Audit-Aufzeichnungen.

Diese Aufteilung benötigt weiterhin gemeinsame Standards. Ohne sie wird jeder Anbieter Agenten, delegierte Autorität und Aktionsprotokolle anders beschreiben. Unternehmen könnten am Ende mehrere inkompatible Identitätsdatensätze für denselben autonomen Prozess haben.

Für Engineering-Teams ist dies auch ein Wissensproblem. Sicherheitsrichtlinien setzen voraus, dass nachvollziehbar ist, welcher Agent auf welche lokalen Dokumente, Repositories und internen Tools zugegriffen hat. Eine durchsuchbare Engineering-Wissensdatenbank kann den Kontext verbessern, doch die Autorisierung muss von der Suche getrennt bleiben.

Die entscheidende Grenze ist einfach. Zugang zu nützlichem Kontext bedeutet nicht automatisch die Berechtigung, das Quellsystem zu verändern. Abruf, Schlussfolgern und Ausführung erfordern getrennte Kontrollen.

Die Identitätsthese löst Zugriffsfragen, nicht jedes KI-Risiko

Agenten als Identitäten zu behandeln, schafft einen notwendigen Kontrollpunkt, macht ihre Schlussfolgerungen jedoch nicht vorhersehbar und ihre Anweisungen nicht vertrauenswürdig.

Die stärkste Kritik an der Identitätsthese lautet nicht, dass Zugriffskontrolle irrelevant sei. Sie lautet, dass Identitätsanbieter ein umfassenderes KI-Sicherheitsproblem möglicherweise mit den Produkten rahmen, die sie bereits zu verkaufen wissen.

Ein authentifizierter Agent kann weiterhin eine schädliche Handlung ausführen. Das System weiß möglicherweise genau, welcher Agent einen Datensatz gelöscht hat, und verhindert die Löschung dennoch nicht. Identität schafft Verantwortlichkeit, nicht Korrektheit.

Auch das Prinzip der minimalen Rechte hängt von präzisen Richtlinien ab. Wenn ein Agent für eine komplexe Aufgabe legitimerweise weitreichenden Zugriff benötigt, bleibt der erlaubte Schadensradius groß. Eine eng begrenzte Berechtigung kann innerhalb dieses Rahmens dennoch die falsche Operation erlauben.

Prompt Injection schafft eine weitere Lücke. Eine bösartige Anweisung, die in einem Dokument oder auf einer Webseite verborgen ist, kann das Verhalten eines Agenten umleiten. Der Agent bleibt dabei korrekt authentifiziert, obwohl er auf eine nicht vertrauenswürdige Eingabe reagiert.

Laufzeitautorisierung kann die Folgen begrenzen, aber nur, wenn die Richtlinie erkennt, dass die angeforderte Aktion über die beabsichtigte Aufgabe hinausgeht. Diese Erkenntnis wird schwieriger, wenn die bösartige Anfrage normaler Arbeit ähnelt.

Delegation erschwert die Zuordnung zusätzlich. Ein Nutzer kann einen Agenten autorisieren, der dann über einen externen Dienst einen weiteren Agenten aufruft. Der zweite Agent könnte mehrere Tools unter Anmeldedaten verwenden, die aus der ersten Anfrage abgeleitet wurden.

Sicherheitsteams benötigen eine Beweiskette, die den menschlichen Auftraggeber, den primären Agenten, delegierte Agenten, ausgestellte Anmeldedaten, Tool-Aufrufe und die daraus resultierenden Änderungen verbindet. Fehlt ein Glied, kann ein vollständiges Audit unmöglich werden.

Forscher haben zudem hinterfragt, ob die Behandlung von Agenten wie menschlichen Identitäten die falsche Abstraktion schafft. Eine menschliche Identität ist relativ dauerhaft und rechtlich verantwortlich. Ein Agent kann innerhalb eines Workflows dupliziert, verändert, beendet oder neu erstellt werden.

Einige Architekten bevorzugen es, Agenten als temporäre Workload-Principals zu behandeln. Ein Principal ist eine Entität, die von einem Autorisierungssystem erkannt wird. Diese Sichtweise betont den konkreten Laufzeitprozess, statt einem Agenten eine dauerhafte, mit Mitarbeitenden vergleichbare Identität zu geben.

Der Unterschied mag semantisch klingen, beeinflusst jedoch das Richtliniendesign. Eine dauerhafte Identität hilft, Historie und Eigentümerschaft nachzuverfolgen. Ein temporärer Principal begrenzt die Wiederverwendung von Anmeldedaten und bildet kurzlebige Ausführungen besser ab.

Eine ausgereifte Architektur könnte beides erfordern. Die Organisation braucht einen dauerhaften Datensatz, der den Agenten und seinen Eigentümer beschreibt. Jede Ausführung sollte zusätzlich eine eigene Laufzeitidentität mit begrenzter Autorität erhalten.

Eine weitere Unsicherheit betrifft Anbieterbehauptungen. Sicherheitsunternehmen können zeigen, dass sie bekannte Agenten erkennen und unterstützte Verbindungen vermitteln. Nachzuweisen, dass sie jeden Schattenagenten, jede kopierte Berechtigung oder jeden indirekten Tool-Aufruf abdecken, ist deutlich schwieriger.

Die Abdeckung verändert sich zudem, wenn Mitarbeitende neue Agent-Tools einsetzen. Ein Entwickler könnte einen Assistenten mit einem persönlichen Token an ein Repository anbinden. Eine Abteilung könnte einen Agenten über einen Softwaredienst bereitstellen, ohne das Sicherheitsteam zu informieren.

Erkennungssysteme können Cloud-Umgebungen und Softwareintegrationen scannen, doch kein Tool garantiert vollständige Sichtbarkeit. Käufer sollten Bestandsquoten und automatisierte Eigentümerschaftsangaben als Anbieterangaben betrachten, sofern sie nicht unabhängig getestet wurden.

Auch Umfragedaten erfordern ähnliche Vorsicht. CyberArk berichtete, dass bereits fast 40 Prozent der befragten Finanz- und Softwareunternehmen agentische KI produktiv einsetzen. Berichten zufolge hatte weniger als eines von zehn Unternehmen Sicherheitskontrollen für Agenten skaliert.

Die Untersuchung umfasste 104 Sicherheitsverantwortliche in Nordamerika und Europa. Sie beschreibt eine besorgniserregende Lücke innerhalb dieser Stichprobe, nicht den gesamten globalen Unternehmensmarkt.

Breitere Berichterstattung zeigt dieselbe Richtung, allerdings mit anderen Schätzungen. Eine Analyse zu Agentenidentitäten stellte fest, dass Sicherheitsanbieter um die Governance autonomer Systeme konkurrierten, während Unternehmen ihre Agenten-Piloten ausweiteten.

Der Bericht hielt außerdem eine entscheidende operative Idee fest: Organisationen benötigen eine Möglichkeit, einen Agenten sofort zu widerrufen. Ein Kill Switch löst nicht jeden Fehlerfall, bietet jedoch eine letzte Kontrollmöglichkeit, wenn automatisierte Richtlinien und Überwachung versagen.

Käufer sollten diese Fähigkeit unter Belastung testen. Der Widerruf muss sich über aktive Sitzungen, zwischengespeicherte Tokens, delegierte Agenten und nachgelagerte Tools hinweg ausbreiten. Es genügt nicht, ein sichtbares Konto zu deaktivieren, wenn dessen temporäre Kopien aktiv bleiben.

Identitätssicherheit adressiert damit den Teil des KI-Risikos, den Unternehmen am unmittelbarsten steuern können. Sie kontrolliert Autorität, protokolliert Handlungen und begrenzt Exposition. Sie garantiert weder sichere Schlussfolgerungen noch korrekte Entscheidungen oder vertrauenswürdige Eingaben.

Diese Einschränkung schwächt die Kategorie nicht. Sie verdeutlicht, was die Kategorie beweisen muss.

Der Markt konsolidiert sich rund um die Control Plane

Die Chance im Identitätsmarkt zieht sowohl fokussierte Startups als auch große Sicherheitsplattformen an, weil Agentenzugriff zwischen wertvollen Daten und automatisierten Aktionen liegt.

Die Übernahme von CyberArk durch Palo Alto Networks machte die strategische Bedeutung besonders deutlich. Die Kombination stellt Identitätssicherheit neben Produkte für Netzwerk, Cloud, Endpunkte und Security Operations.

Die Transaktion legt nahe, dass Identität zu einer horizontalen Ebene über Sicherheitsportfolios hinweg wird. Wenn KI-Agenten Anwendungen, Infrastruktur und sensible Daten berühren, verbinden ihre Berechtigungen mehrere Märkte, die Anbieter zuvor getrennt verkauft haben.

Die Übernahme von Wiz durch Google lieferte einen weiteren Bezugspunkt für die israelische Cybersicherheitsbranche. Wiz baute seine Position auf Cloud-Transparenz und Risikozusammenhängen auf. Agentenidentität erweitert diesen Graphen um die Frage, welcher autonome Prozess auf welcher Ressource handeln darf.

Große Plattformen können Zugriffsdaten mit Netzwerksignalen, Cloud-Konfigurationen und Threat Intelligence kombinieren. Diese Breite hilft ihnen zu erkennen, wenn sich eine legitime Identität ungewöhnlich verhält.

Sie kann jedoch auch Integrationsrisiken schaffen. Eine durch Übernahmen zusammengesetzte Plattform kann mehrere Richtlinien-Engines, Identitätsdatensätze und Verwaltungsoberflächen offenlegen. Kunden werden beurteilen, ob die Komponenten als ein Kontrollsystem funktionieren oder lose verbundene Produkte bleiben.

Fokussierte Startups argumentieren, ältere Plattformen seien für menschliche Nutzer, herkömmliche Anwendungen oder statische Service Accounts entwickelt worden. Ihr Vorteil besteht darin, kurzlebige Agenten und Berechtigungen auf Aufgabenebene von Beginn an modellieren zu können.

Etablierte Anbieter halten mit Vertriebskraft und installierter Infrastruktur dagegen. Unternehmenskäufer vertrauen ihnen bereits bei der Verwaltung privilegierter Konten oder der Authentifizierung von Mitarbeitenden. Agenten zu einer bestehenden Identitätsplattform hinzuzufügen, kann einfacher sein als einen weiteren Sicherheitsanbieter einzuführen.

Cloud-Anbieter nehmen eine dritte Position ein. Sie stellen viele Workload-Anmeldedaten aus und kontrollieren die Infrastruktur, auf der Agenten laufen. Sie können kurzlebige Identitäten, Richtlinienauswertung und Protokollierung nah an der Ausführungsumgebung integrieren.

Anwendungsanbieter halten ein weiteres Puzzleteil. Ein Agent, der über einen Softwaredienst auf Kundendaten zugreift, hängt vom Autorisierungsmodell dieses Dienstes ab. Externe Identitätskontrollen können keine feingranularen Berechtigungen schaffen, die die zugrunde liegende Anwendung nicht unterstützt.

Der Markt könnte sich daher auf mehrere Ebenen aufteilen:

• Identitätsplattformen verwalten Agenten-Eigentümerschaft, Lebenszyklus und organisationsweite Richtlinien.

• Cloud-Systeme stellen Workload-Identitäten und temporäre Anmeldedaten aus.

• Agent-Frameworks legen Aufgaben-Kontext, Delegation und Tool-Aktivitäten offen.

• Enforcement-Gateways bewerten risikoreiche Operationen vor der Ausführung.

• Sicherheitsanalyseprodukte erkennen anormales Verhalten, nachdem Zugriff gewährt wurde.

• Anwendungen setzen die endgültige Berechtigung auf Ressourcenebene durch.

Diese Struktur schafft Partnerschaftsmöglichkeiten, lädt aber auch zur Konsolidierung ein. Käufer werden weniger Richtlinienoberflächen bevorzugen, insbesondere wenn jede zusätzliche Integration zu einem weiteren Fehlerpunkt werden kann.

Der Vorteil der israelischen Branche liegt in ihrem dichten Netzwerk an Expertise für Identität, Cloud und Unternehmenssicherheit. Gründer und Mitarbeitende wechseln häufig zwischen militärischen Technologieeinheiten, Startups, multinationalen Forschungszentren und börsennotierten Sicherheitsunternehmen.

Dieses Netzwerk garantiert keine Marktführerschaft. Amerikanische Plattformanbieter, Cloud-Anbieter und Identitätsspezialisten wie Okta und 1Password verfolgen dieselbe Chance.

Auch Open-Source-Frameworks können beeinflussen, wo die Durchsetzung erfolgt. Wenn Agent-Entwickler gemeinsame Schnittstellen für Identität und Autorisierung übernehmen, können Anbieter bei der Umsetzung konkurrieren. Wenn jedes Framework ein eigenes Modell schafft, könnten größere Plattformen durch ihre Integrationsabdeckung an Einfluss gewinnen.

Standards werden dieses Gleichgewicht prägen. Die Arbeit von NIST fragt, wie Organisationen Agenten identifizieren, autorisieren, ihre Handlungen auditieren und Aktivitäten verantwortlichen Menschen zuordnen können.

Ein gemeinsames Modell würde Integrationskosten senken und Anbieterbehauptungen leichter vergleichbar machen. Es könnte zudem Versuche begrenzen, proprietäre Agentenidentitätsformate in Kundenbindung zu verwandeln.

Die Control Plane wird nicht automatisch dem Unternehmen mit dem größten bestehenden Identitätsgeschäft gehören. Sie wird der Architektur gehören, die vertrauenswürdigen Kontext, unabhängige Durchsetzung, breite Integration und nutzbare Betriebsabläufe kombiniert.

Worauf Käufer nach dem Google-News-Zyklus achten sollten

Die nächste Phase wird durch technische Validierung und das Verhalten von Unternehmen entschieden, nicht durch die Menge der Google-News-Schlagzeilen.

Das erste Signal ist, ob die Laufzeitautorisierung komplexe Delegation übersteht. Produktdemonstrationen zeigen häufig einen Agenten, der Zugriff auf eine Ressource anfordert. Reale Deployments werden Agenten umfassen, die Tools aufrufen, Teilprozesse starten und Arbeit über Organisationsgrenzen hinweg delegieren.

Käufer sollten fragen, ob jede delegierte Aktion eine eigene nachvollziehbare Identität und Berechtigung erhält. Sie sollten außerdem testen, ob der Widerruf der ursprünglichen Anfrage jeden nachgelagerten Zugriff deaktiviert.

Wenn Anbieter diese Kette konsequent durchsetzen können, wird die Identitätsthese überzeugender. Verschwindet die Kontrolle nach der ersten Delegation, löst der Markt weiterhin eher einfache Automatisierung als Sicherheitsfragen autonomer Agenten.

Das zweite Signal ist eine Annäherung bei Standards. NIST hat Agentenidentität und -autorisierung bereits als formellen Arbeitsbereich definiert. Entscheidend wird eine interoperable Umsetzung sein, nicht eine weitere Sammlung von Grundsätzen.

Unternehmen sollten auf gemeinsame Formate für Agenteneigentümerschaft, delegierte Befugnisse, Aktionsherkunft und Berechtigungsumfang achten. Eine Übernahme durch Cloud-Plattformen und Agenten-Frameworks wäre bedeutender als Unterstützung allein durch Sicherheitsanbieter.

Ein gemeinsamer Standard würde den Markt stärken, indem er Richtlinien portabel macht. Anhaltende Fragmentierung würde große Plattformen begünstigen, die Integrationskosten auffangen und proprietäre Identitätsgraphen pflegen können.

Das dritte Signal sind Belege für den routinemäßigen Einsatz in Unternehmen. Finanzierungsrunden und Anbieterumfragen belegen Interesse, beweisen jedoch nicht, dass Organisationen diese Kontrollen im großen Maßstab betreiben können.

Nützliche Indikatoren sind etwa, wie viele Agentenaktionen temporäre Zugangsdaten erhalten, wie häufig Richtlinien unsichere Anfragen blockieren und wie schnell Teams delegierte Aktivitäten untersuchen können. Käufer sollten zudem Fehlalarme und Verzögerungen bei Genehmigungen messen.

Ein Autorisierungssystem, das zu wenig blockiert, schafft Risiken. Eines, das die alltägliche Arbeit unterbricht, wird umgangen. Die erfolgreichen Produkte müssen zeigen, dass sie Zugriffe gezielt einschränken können, ohne jeden Tool-Aufruf in ein manuelles Ticket zu verwandeln.

Sicherheitsverantwortliche können schon vor der Wahl einer Plattform beginnen. Sie sollten Agenten, Dienstkonten, API-Tokens und mit Agenten verbundene Anwendungen inventarisieren. Jeder Agent benötigt einen verantwortlichen Eigentümer und einen dokumentierten Weg für den sofortigen Entzug seiner Berechtigungen.

Teams sollten Lesezugriff von Schreibzugriff trennen und Routineaktionen von irreversiblen Vorgängen unterscheiden. Hochriskante Operationen benötigen strengere Genehmigungen, kürzere Gültigkeitsdauern für Zugangsdaten und eindeutigere Audit-Nachweise.

Entwickler sollten vermeiden, dauerhafte Geheimnisse in Prompts, Konfigurationsdateien oder dem Agentenspeicher abzulegen. Kurzlebige Zugangsdaten verringern die Angriffsfläche, müssen jedoch an die genehmigte Aufgabe und die Laufzeitidentität gebunden bleiben.

Auch Wissensarbeiter spielen eine Rolle. Die Verbindung eines Assistenten mit E-Mails, Dokumenten, Kalendern und Projektsystemen kann ihm mehr Befugnisse verleihen, als seine sichtbare Oberfläche vermuten lässt. Nutzer sollten verstehen, welche Aktionen eine Prüfung erfordern und welche automatisch erfolgen.

Die über Google News entstehende Geschichte ist daher glaubwürdig, aber unvollständig. Israelische Cybersicherheitsunternehmen haben Identität als durchsetzbare Grenze zwischen dem Schlussfolgern von Agenten und Unternehmensaktionen erkannt.

Sie haben jedoch noch nicht bewiesen, dass eine einzige Architektur jeden Agenten, jedes Tool, jede Zugangsinformation und jede delegierte Aufgabe steuern kann. Standards sind weiterhin unvollständig, Unternehmensmessungen bleiben begrenzt, und Behauptungen zur Anbieterabdeckung müssen getestet werden.

Die praktische Frage lautet nicht mehr, ob Agenten Zugriffskontrollen benötigen. Sie lautet, ob diese Kontrollen Befugnisse über einen gesamten autonomen Workflow hinweg verfolgen können.

Organisationen sollten die nächsten Produktintegrationen, Standardimplementierungen und Bereitstellungsnachweise genau beobachten. Stimmen diese drei Signale überein, wird Identität zur Betriebsebene für die Sicherheit von Unternehmens-KI. Tun sie es nicht, wird die aktuelle Aufmerksamkeit ein Problem offenlegen, bevor der Markt eine vollständige Antwort hervorgebracht hat.