Die Sicherheit von KI-Agenten beginnt mit Identität, doch Unternehmen brauchen mehr als Zugangsdaten

Google News machte am 2. September auf eine Warnung zu KI-Agenten aufmerksam, doch der Konflikt reicht weit über eine weitere Sicherheits-Checkliste hinaus. Der Artikel argumentiert, dass Unternehmen drei Fragen beantworten müssen, bevor sich Agenten weiter verbreiten: Wo befinden sie sich, womit können sie sich verbinden, und was können sie tun?

Diese Einordnung erschien in einem Gastbeitrag von Ariel Zommer, einem Sicherheitsproduktmarketing-Experten bei Okta, für GuidePoint Security. Die zentrale Aussage ist einfach: Sobald ein Agent sich authentifizieren, Unternehmenssysteme erreichen oder ohne ständige menschliche Anleitung handeln kann, wird er zu einem Identitätsproblem.

Der Zeitpunkt ist bedeutsam. NIST veröffentlichte am 27. August eine separate Warnung zur Identität – weniger als eine Woche vor dem Erscheinen des GuidePoint-Artikels. Microsoft, Okta und andere Identitätsanbieter machen Agentenidentitäten ebenfalls zu formalen Produktobjekten.

Diese Konvergenz verändert die Debatte in Unternehmen. Die zentrale Frage lautet nicht mehr, ob ein Modell eine präzise Antwort liefern kann. Entscheidend ist, ob jede daraus resultierende Aktion einen sichtbaren Akteur, begrenzte Befugnisse, einen verantwortlichen Eigentümer und eine widerrufbare Verbindung hat.

Das Argument klingt vertraut, weil das Identitätsmanagement bereits Mitarbeitende, Anwendungen und traditionelle Workloads steuert. Agenten verkomplizieren dieses Modell, weil ihre Aktionen probabilistisch sind, sich ihre Verbindungen ändern und eine Anfrage viele nachgelagerte Vorgänge auslösen kann.

Identität ist daher notwendig, aber nicht ausreichend. Eine Zugangsinformation kann einen Agenten identifizieren, ohne zu belegen, dass seine aktuelle Aktion sicher ist. Der eigentliche Konflikt besteht zwischen rechenschaftspflichtiger Autonomie und bequemem Zugriff, den Organisationen nicht vollständig nachverfolgen können.

Was Google News tatsächlich aufgegriffen hat

Die Nachricht ist keine neue Offenlegung einer Sicherheitslücke. Sie ist eine koordinierte Warnung, dass die Einführung von Agenten die Identitätskontrollen in Unternehmen überholt.

Das ursprüngliche Identitätsargument wurde am 2. September 2026 von GuidePoint Security veröffentlicht. Es stammt von einem Okta-Mitarbeiter und wurde als Partnerperspektive präsentiert.

Diese Unterscheidung ist wichtig. Leser sollten den Artikel als anbietergestützte Analyse betrachten, nicht als unabhängigen Beleg dafür, dass eine einzelne kommerzielle Plattform jedes Sicherheitsproblem bei Agenten löst. Seine drei Fragen bleiben nützlich, weil sie messbare Kontrolllücken beschreiben.

Die erste Frage lautet, wo die Agenten einer Organisation existieren. Ein Inventar muss intern entwickelte Agenten, in SaaS-Produkte eingebettete Funktionen, cloudgehostete Agenten, von Mitarbeitenden autorisierte Tools und experimentelle Systeme umfassen.

Herkömmliche Asset-Inventare übersehen diese Kategorien häufig. Ein Entwickler kann innerhalb eines genehmigten Cloud-Kontos einen Agenten erstellen, ohne ihn als eigenständige Geschäftsanwendung zu registrieren. Mitarbeitende können zudem ein externes Tool über OAuth autorisieren.

OAuth ist ein Autorisierungsstandard, der einer Anwendung begrenzten Zugriff auf einen anderen Dienst ermöglicht. Seine Bequemlichkeit kann dauerhafte Vertrauensbeziehungen vor Teams verbergen, die den zugrunde liegenden Agenten nie genehmigt haben.

Die Erfassung erfordert daher mehr als das Scannen von Code-Repositories. Sicherheitsteams benötigen außerdem Cloud-Inventare, Anwendungsregistrierungen, OAuth-Freigaben, Dienstkonten, Browsersignale, API-Gateway-Protokolle und Model Context Protocol-Verbindungen.

Model Context Protocol oder MCP ermöglicht KI-Anwendungen, über eine gemeinsame Schnittstelle mit Tools und Daten zu interagieren. Es kann die Integration vereinfachen und zugleich die Zahl erreichbarer Systeme erhöhen.

Die zweite Frage lautet, womit sich jeder erfasste Agent verbinden kann. Diese Karte sollte Geschäftsanwendungen, interne APIs, Datenbanken, Kollaborationssysteme, Geheimnisse, Dienstkonten und andere Agenten abdecken.

Eine Verbindung offenbart nicht das vollständige Risiko. Sicherheitsteams benötigen außerdem Informationen über die Autorisierungsmethode, den Berechtigungsumfang, die Laufzeit der Zugangsinformation, den geschäftlichen Eigentümer, die Genehmigungshistorie und den Widerrufspfad.

Die dritte Frage lautet, was ein Agent nach der Verbindung tun kann. Lesezugriff, das Ändern von Datensätzen, Code-Ausführung, Geldbewegungen und die Nachahmung von Nutzern haben sehr unterschiedliche Folgen.

Diese Berechtigungen können sich auch kombinieren. Ein Agent, der E-Mails liest und Support-Tickets erstellt, wirkt begrenzt, wenn jede Verbindung separat geprüft wird. Er wird folgenreicher, wenn er Anweisungen extrahieren und externe Aktionen auslösen kann.

Google News half dabei, die Warnung einem breiteren Publikum zugänglich zu machen. Das wichtige Ereignis spielte sich jedoch unterhalb der Aggregationsebene ab. Identitätsanbieter und öffentliche Standardisierungsgremien nähern sich Agenten als erstklassigen Akteuren in Unternehmen an.

Dieser Wandel verschafft Sicherheitsverantwortlichen einen klareren Ausgangspunkt. Er erhöht zugleich den Druck, die Identität eines Agenten von dem Nutzer, der Anwendung oder dem Dienstkonto zu unterscheiden, die ihn gestartet haben.

Ein geliehenes Mitarbeitertoken kann diese Unterscheidung nicht sauber leisten. Dasselbe gilt für einen gemeinsamen API-Schlüssel, den mehrere Agenten verwenden. Beide Konstellationen schwächen die Zuordnung bei Audits und Untersuchungen von Sicherheitsvorfällen.

Die unmittelbare Veränderung ist konzeptionell, aber operativ. Unternehmen benötigen nun separate Lebenszyklusdatensätze für Agenten, einschließlich Erstellung, Eigentümerschaft, Autorisierung, Überprüfung, Aussetzung und Stilllegung.

Identität ist zur KI-Steuerungsebene geworden

Ein Agent benötigt eine eigene Identität, weil Befugnisse ohne Zuordnung alltägliche Automatisierung in ein grenzenloses Untersuchungsproblem verwandeln.

Identity and Access Management oder IAM bestimmt, wer unter welchen Bedingungen auf eine Ressource zugreifen kann. Bestehende IAM-Systeme bieten bereits Verzeichnisse, Policy-Engines, Zugriffsüberprüfungen, Token-Dienste und Audit-Protokolle.

Diese Komponenten geben Unternehmen eine praktische Grundlage. Sie können einen Agenten registrieren, ihm einen Eigentümer zuordnen, spezifische Berechtigungen gewähren und diese Berechtigungen widerrufen, wenn sich der Agent ändert oder stillgelegt wird.

NIST bekräftigte diese Position in seiner jüngsten Analyse zu Identitätsgrundlagen. Die Behörde warnte, dass frühe Implementierungen Funktionen und unmittelbaren Nutzen gegenüber etablierten Identitätspraktiken priorisieren.

NIST hob zudem die gemeinsame Nutzung von Zugangsinformationen als Kernproblem hervor. Geteilte Zugangsinformationen untergraben die Rechenschaftspflicht, weil Untersuchende nicht zuverlässig feststellen können, welche Person, welcher Dienst oder welcher Agent eine Transaktion ausgeführt hat.

Das Problem verschärft sich, wenn Agenten Aufgaben delegieren. Ein Nutzer könnte einen Agenten bitten, ein Vertriebsbriefing vorzubereiten. Dieser Agent könnte ein anderes System für Kontodaten und einen dritten Dienst für Wettbewerbsrecherchen aufrufen.

Jede Übergabe schafft eine Autorisierungsentscheidung. Das Unternehmen muss den ursprünglichen Nutzer, den handelnden Agenten, die angeforderte Ressource und den Zweck hinter der Anfrage bewahren.

Ohne diese Kette können Protokolle zeigen, dass ein Dienstkonto auf eine Datenbank zugegriffen hat. Sie können jedoch nicht erklären, welcher Agent die Aktion initiiert hat, welcher Nutzer sie angefordert hat oder ob sie einem genehmigten Workflow entsprach.

Eine erstklassige Identität kann einen Teil dieses Kontexts wiederherstellen. Jeder Agent erhält eine eindeutige Kennung, statt ein allgemeines Konto zu übernehmen. Richtlinien können dann gezielt auf den jeweiligen Agenten angewendet werden.

Dieses Modell unterstützt das Prinzip der minimalen Rechtevergabe, das eine Identität auf den geringsten für ihre zugewiesene Aufgabe erforderlichen Zugriff beschränkt. Es ermöglicht zudem den Widerruf, ohne nicht beteiligte Anwendungen oder Mitarbeitende zu beeinträchtigen.

Kurzlebige Tokens stärken das Design. Ein Token ist eine signierte Zugangsinformation, die gewährte Befugnisse für einen begrenzten Umfang und Zeitraum repräsentiert. Kurze Laufzeiten verringern den Wert gestohlener Zugangsinformationen.

Föderierte Zugangsinformationen bieten eine weitere Verbesserung. Sie ermöglichen einem vertrauenswürdigen Workload, ein Token anzufordern, ohne ein wiederverwendbares Geheimnis in Code, Konfigurationsdateien oder dem Speicher eines Agenten abzulegen.

Eigentümerschaft vervollständigt den grundlegenden Datensatz. Jeder Produktiv-Agent benötigt eine benannte Person oder ein verantwortliches Team, das für seinen Zweck, seine Berechtigungen, Überprüfungen und Stilllegung zuständig ist.

Der Eigentümer kann nicht lediglich der Entwickler sein, der den ersten Prototyp erstellt hat. Geschäftliche Eigentümerschaft ist wichtig, weil jemand entscheiden muss, ob der Zugriff des Agenten weiterhin erforderlich ist.

Auch der Lebenszyklusstatus ist wichtig. Ein experimenteller Agent sollte nach Ende eines Tests keine Produktionsberechtigungen behalten. Ein ersetzter Agent sollte nicht aktiv bleiben, nur weil sein API-Schlüssel noch funktioniert.

Diese Struktur ähnelt der Governance für Mitarbeitende und Anwendungen. Agenten erfordern jedoch häufigere Bewertungen, weil sich ihre Tools, Anweisungen, Modelle und delegierten Aufgaben unabhängig voneinander ändern können.

Unternehmen sollten das Identitätsverzeichnis daher als Steuerungsebene behandeln, nicht als statisches Adressbuch. Die Registrierung startet die Governance, doch kontinuierliche Durchsetzung von Richtlinien verleiht ihr Bedeutung.

Diese Unterscheidung schützt auch legitime Experimente. Entwickler können einen klar definierten Weg zur Registrierung eines Agenten erhalten, statt nach der Bereitstellung auf eine umfangreiche Sicherheitsprüfung warten zu müssen.

Ein nutzbarer Registrierungsprozess sollte Zweck, Eigentümer, Umgebung, Tools, Datenklassen, Berechtigungen und erwartete Betriebsgrenzen erfassen. Er sollte außerdem ein Ablauf- oder Überprüfungsdatum zuweisen.

Wenn der genehmigte Weg langsamer ist als die Erstellung eines nicht registrierten Agenten, werden Teams ihn umgehen. Das Identitätsprogramm muss daher sicheres Onboarding einfacher machen als eine verdeckte Bereitstellung.

Hier können Praktiken des Wissensmanagements die Governance unterstützen. Teams benötigen durchsuchbare Aufzeichnungen, die Entscheidungen, Eigentümer, Anforderungen, Genehmigungen und spätere Änderungen miteinander verbinden.

Ein Inventar allein beantwortet, wo ein Agent registriert wurde. Vernetztes Betriebswissen erklärt, warum er existiert und ob sein aktuelles Verhalten weiterhin diesem Zweck entspricht.

Die drei Fragen decken drei unterschiedliche Fehler auf

Erfassung, Verbindungskontrolle und Aktions-Governance sind getrennte Disziplinen, und das Bestehen in einer gleicht das Versagen in einer anderen nicht aus.

„Wo sind meine Agenten?“ prüft die Sichtbarkeit. Sicherheitsteams können einen Agenten nicht steuern, der nur im Konto eines Entwicklers, im Browser eines Mitarbeitenden oder in der Konfiguration eines SaaS-Administrators erscheint.

Ein nützliches Inventar muss genehmigte und nicht genehmigte Bereitstellungen umfassen. Es muss außerdem aktive Agenten von Vorlagen, aufgegebenen Experimenten, deaktivierten Instanzen und gewöhnlichen Anwendungen mit KI-Funktionen unterscheiden.

Das Inventar sollte die Umgebung und den Betriebsstatus jedes Agenten identifizieren. Für Entwicklungs-, Test- und Produktiv-Agenten sollten nicht dieselben Genehmigungsannahmen gelten.

Sicherheitsteams müssen zudem entscheiden, was als Agent zählt. Ein Chatbot, der nur Text zurückgibt, weist ein anderes Befugnisprofil auf als ein System, das Tools aufruft oder Datensätze verändert.

Die Definition sollte sich auf das Verhalten konzentrieren. Wenn Software Aktionen auswählt, verbundene Tools aufruft oder mit begrenzter menschlicher Überprüfung Arbeit delegiert, gehört sie zur gesteuerten Population.

„Womit können sie sich verbinden?“ prüft den Vertrauensgraphen der Organisation. Ein Vertrauensgraph erfasst Beziehungen zwischen Identitäten, Zugangsinformationen, Anwendungen, Ressourcen und delegierten Diensten.

Dieser Graph sollte direkte und indirekte Reichweite zeigen. Ein Agent verfügt möglicherweise nicht über Datenbankzugriff, aber über die Berechtigung, einen Dienst aufzurufen, der dieselbe Datenbank abfragen kann.

Agent-zu-Agent-Verbindungen erschweren die Zuordnung. Ein Agent kann Kontext oder Befugnisse an einen anderen weitergeben und so eine Kette schaffen, die Plattformen und administrative Grenzen überschreitet.

Unternehmen müssen erfassen, ob jede Verbindung dauerhaften Zugriff oder aufgabenspezifische Autorisierung nutzt. Dauerhafter Zugriff bleibt zwischen Aufgaben verfügbar und erhöht das Risiko, wenn der Agent kompromittiert wird.

„Was können sie tun?“ prüft die Laufzeitkontrolle. Die Antwort kann nicht aus einer Liste von API-Berechtigungen bestehen, die aus einer Anwendungsregistrierung kopiert wurde.

Eine Berechtigung kann die Änderung von Dateien erlauben, doch Richtlinien sollten weiterhin zwischen routinemäßiger Bearbeitung und dem Löschen eines Repositorys unterscheiden. Dieselbe technische Berechtigung kann Aktionen mit unterschiedlichen geschäftlichen Folgen abdecken.

Die Laufzeitautorisierung bewertet eine vorgeschlagene Aktion, wenn sie stattfindet. Sie kann den handelnden Agenten, den ursprünglichen Nutzer, die Sensibilität der Ressource, die angeforderte Operation, den Ort und aktuelle Risikosignale berücksichtigen.

Einige Entscheidungen sollten automatisiert bleiben. Für jede risikoarme Abfrage eine menschliche Freigabe zu verlangen, würde den Produktivitätsgewinn zunichtemachen, den Agenten versprechen.

Folgenreiche Aktionen verdienen stärkere Hürden. Änderungen an Produktionssystemen, Geldtransfers, die Offenlegung regulierter Informationen und irreversible Löschvorgänge benötigen ausdrückliche Schutzmaßnahmen.

Eine Human-in-the-loop-Freigabe ist eine Option. Sie bindet eine Person an einem definierten Entscheidungspunkt ein, bevor der Agent eine sensible Aktion abschließt.

Eine Freigabe muss aussagekräftigen Kontext liefern. Eine Aufforderung wie „Aktion erlauben“, die Ressource, Daten, Zweck und erwartete Wirkung nicht benennt, wird zu einem rein formalen Kontrollkästchen.

Organisationen benötigen außerdem eine zuverlässige Deaktivierung. Ein Kill Switch sollte dem Agenten den aktiven Zugriff auf alle verbundenen Systeme entziehen, statt nur seine sichtbare Schnittstelle zu deaktivieren.

Diese Fähigkeit hängt von der Credential-Architektur ab. Eine zentrale Sperrung funktioniert schlecht, wenn Agenten verstreute API-Schlüssel, zwischengespeicherte Tokens oder in externe Dienste kopierte Zugangsdaten verwenden.

Die drei Fragen bilden daher eine Abfolge. Discovery identifiziert das Subjekt, die Zuordnung von Verbindungen definiert die potenzielle Reichweite, und die Aktionsgovernance kontrolliert die ausgeübte Befugnis.

Das Überspringen dieser Abfolge schafft falsches Vertrauen. Eine Organisation kann ein vollständiges Agentenverzeichnis pflegen und dennoch jedem aufgeführten Agenten zu weitreichende Berechtigungen gewähren.

Sie kann auch eng begrenzte Tokens ausgeben und gleichzeitig von Mitarbeitenden erstellte Agenten übersehen. Alternativ kann sie Agentenaktionen protokollieren, ohne genügend Identitätskontext zu speichern, um sie zuzuordnen.

Der Wert des Frameworks liegt in diesen Fehlergrenzen. Jede Frage gibt Auditoren und Sicherheitsverantwortlichen eine konkrete Behauptung zum Prüfen, statt nur eine allgemeine Zusicherung zu „verantwortungsvoller KI“.

Identitätskontrollen können nicht entscheiden, ob eine Aktion sinnvoll ist

Eine gültige Identität beantwortet die Frage, wer handelt, garantiert aber nicht, dass der Agent die Anfrage verstanden oder eine sichere Aktion gewählt hat.

Diese Einschränkung bestimmt den zentralen Zielkonflikt des Artikels. Unternehmen benötigen identitätsbasierte Kontrollen, doch Agenten bleiben weniger vorhersehbar als traditionelle Anwendungen, die dieselben Zugangsdaten verwenden.

Ein konventioneller Dienst führt Code für einen bekannten Workflow aus. Ein Agent kann Anweisungen interpretieren, Tools auswählen, Parameter generieren und seinen Weg anhand zurückgegebener Informationen anpassen.

Diese Flexibilität schafft Wert. Sie bedeutet jedoch auch, dass eine erfolgreiche Authentifizierung nicht als Beleg dafür dienen kann, dass die nächste Entscheidung der Absicht des Nutzers entspricht.

Prompt Injection veranschaulicht diese Lücke. Ein Agent kann bösartige Anweisungen in einem Dokument, einer E-Mail, einer Webseite oder einem abgerufenen Datensatz vorfinden und sie als Teil seiner Aufgabe behandeln.

Der Angreifer muss die Identität des Agenten nicht stehlen. Er kann versuchen, einen ordnungsgemäß authentifizierten Agenten dazu zu manipulieren, seine legitimen Berechtigungen zu missbrauchen.

OWASP führt Identitäts- und Berechtigungsmissbrauch unter seinen agentischen Sicherheitsrisiken auf. Die Kategorie umfasst die Manipulation von Delegationsketten, geerbten Rollen, zwischengespeicherten Zugangsdaten und Agentenkontexten.

Der Missbrauch von Tools schafft ein weiteres Problem. Ein Agent kann ein zugelassenes Tool mit unsicheren Argumenten oder in der falschen Phase eines Workflows aufrufen.

Identitätskontrollen können den Zugriff auf ein nicht zugelassenes Tool verweigern. Sie können jedoch nicht eigenständig bestimmen, ob jeder erlaubte Aufruf das tatsächliche Ziel des Nutzers unterstützt.

Die Sicherheitsarchitektur muss das Modell daher als nicht vertrauenswürdige Entscheidungskomponente behandeln. Deterministische Kontrollen sollten überall dort außerhalb des Modells bleiben, wo Folgen relevant sind.

Eine deterministische Kontrolle folgt expliziten Regeln, statt eine probabilistische Antwort zu erzeugen. Beispiele sind Berechtigungsprüfungen, Schemavalidierung, Transaktionslimits und verpflichtende Freigabeschranken.

Die Policy Engine sollte bewerten, was der Agent vorschlägt, und sich nicht darauf verlassen, dass der Agent sich selbst überwacht. Der Agent sollte die Regeln, die seine Befugnisse steuern, nicht umschreiben können.

Die Validierung von Ein- und Ausgaben bleibt wichtig. Tool-Parameter sollten erwarteten Schemata, Ressourcenlimits, Datenklassifizierungen und zugelassenen Zielorten entsprechen.

Netzwerkkontrollen können die Reichweite weiter reduzieren. Ein Agent, der niemals öffentlichen Internetzugang benötigt, sollte ihn nicht standardmäßig erhalten.

Datenkontrollen sind wichtig, weil Identität eine unangemessene Offenlegung gegenüber einem zugelassenen Empfänger nicht verhindert. Richtlinien müssen auch Datensensibilität, Zweck und Aufbewahrung berücksichtigen.

Das Monitoring muss sich ebenso auf Verhalten wie auf Anmeldungen konzentrieren. Einer erfolgreichen Authentifizierung folgende ungewöhnliche Aufzählungen, Massendownloads oder wiederholt abgelehnte Aktionen verdienen Untersuchung.

Hier muss die Identity-first-These sorgfältig formuliert werden. Identität bietet den Anker für Rechenschaftspflicht, Sperrung und Richtlinien. Sie ist kein vollständiges Sicherheitsmodell für Agenten.

Eine kommerzielle Identitätsplattform kann Registrierung und Tokens zentralisieren. Sie kann nicht garantieren, dass jedes verbundene Modell Manipulation widersteht oder mehrdeutige Ziele korrekt interpretiert.

Auch die Herstellerneutralität bleibt unsicher. Agenten werden sich über Microsoft, Google Cloud, Amazon Web Services, Salesforce, ServiceNow, interne Frameworks und spezialisierte SaaS-Produkte erstrecken.

Jede Plattform kann Agenten unterschiedlich repräsentieren. Plattformübergreifende Identität erfordert interoperable Tokens, konsistente Claims, vertrauenswürdige Aussteller und Richtlinien, die Übergaben überstehen.

MCP fügt eine weitere Grenze hinzu. Ein Unternehmen kann den Agenten kontrollieren, während es darauf angewiesen ist, dass ein externer Server Tools korrekt bereitstellt und seine eigenen Zugangsdaten schützt.

Auch eine Identitätsschicht benötigt Schutz vor Kompromittierung. Zentralisierte Verzeichnisse und Token-Dienste werden zu wertvollen Zielen, weil sie viele Agenten gleichzeitig betreffen können.

Unternehmen sollten administrative Aufgaben trennen, Änderungen mit hohen Berechtigungen schützen und ungewöhnliche Richtlinienänderungen überwachen. Die Agenten-Governance darf nicht auf einem einzigen, weitreichend privilegierten Konsolenkonto beruhen.

Audit-Logs verdienen dieselbe Skepsis. Ein großes Ereignisvolumen erzeugt nicht automatisch nützliche Belege.

Ermittler benötigen Aufzeichnungen, die die Nutzeranfrage, die Agentenidentität, delegierte Agenten, das ausgewählte Tool, die Autorisierungsentscheidung, die betroffene Ressource und das Endergebnis miteinander verknüpfen.

Aufbewahrungsrichtlinien müssen diese Kette lange genug für Untersuchungen und regulatorische Prüfungen erhalten. Sensible Prompts und Ausgaben können Datenminimierung oder eingeschränkten Zugriff erfordern.

Die richtige Schlussfolgerung ist enger gefasst als die Botschaft der Anbieter. Identität ist der Anfang der Agentensicherheit, weil Kontrolle ein bekanntes Subjekt benötigt.

Sicherheit erfordert weiterhin mehrschichtige Verteidigungen um dieses Subjekt herum. Zu diesen Schichten gehören eingeschränkte Tools, externe Richtlinien, geschützte Zugangsdaten, Datenkontrollen, Monitoring und menschliche Prüfung.

Microsoft und Okta machen das Modell zu Produkten

Die Identity-first-Idee wandert von der Konferenzsprache in Verzeichnisse, Token-Flüsse, Discovery-Systeme und Sperrkontrollen.

Microsoft Entra Agent ID veranschaulicht, wie eine große Plattform Agenten nun direkt repräsentiert. Microsoft beschreibt eine Agentenidentität als spezialisierten Service Principal mit einer eindeutigen Kennung.

Ein Service Principal repräsentiert eine Anwendung oder einen Workload innerhalb eines Identitäts-Tenants. Die Agentenvariante ermöglicht es Richtlinien und Logs, den Agenten von seinem zugrunde liegenden Blueprint zu unterscheiden.

Microsofts autonomer Authentifizierungsfluss trennt eine Agentenidentität von wiederverwendbaren Produktionsgeheimnissen. Die Dokumentation empfiehlt Managed Identities oder Zertifikate statt Client Secrets.

Autonome Agenten können Application Tokens für ihre eigene Identität anfordern. Interaktive Agenten können delegierte Flüsse verwenden, wenn sie für einen authentifizierten Nutzer handeln.

Dieser Unterschied ist wesentlich. Ein autonomer nächtlicher Reporting-Agent sollte nicht identisch erscheinen wie ein Assistent, der eine einzelne Aktion für einen angemeldeten Mitarbeitenden ausführt.

Die On-behalf-of-Autorisierung bewahrt die Nutzerbeziehung während der Delegation. Das resultierende Token kann den Nutzer als Subjekt und den Agenten als Akteur identifizieren.

Dieses Design gibt Ressourcenservern mehr Kontext für die Autorisierung. Ein System kann fragen, ob dieser Nutzer, handelnd über diesen Agenten, die angeforderte Operation ausführen darf.

Microsoft dokumentiert außerdem spezielle Agenten-Nutzerkonten für Ressourcen, die nutzerähnliche Objekte benötigen. Solche Konten können Postfächer oder kollaborative Funktionen unterstützen, ohne normale menschliche Zugangsdaten zu verwenden.

Diese Konten unterliegen Einschränkungen. Microsoft zufolge können sie keine privilegierten Administratorrollen erhalten, was eine Grenze gegen einige Formen der Rechteausweitung schafft.

Okta verfolgt denselben Markt aus einer plattformneutralen Identitätsperspektive. Sein April-Launch für Agentenidentitäten beschrieb Discovery, Registrierung, verwaltete Verbindungen, Governance und Deaktivierung.

Das Unternehmen erklärt, dass sein Verzeichnis Agenten von externen Plattformen importieren und benutzerdefinierte Agenten registrieren kann. Außerdem beschreibt es die Erkennung von Shadow Agents über OAuth-Consent-Signale.

Okta rahmt sein Produkt um dieselben drei Fragen, die im Gastartikel von GuidePoint wiederholt werden. Diese Überschneidung bestätigt den kommerziellen Kontext des Artikels.

Die Produktbotschaft verdient Prüfung, doch die Umsetzungskategorien sind konkret. Unternehmen benötigen Verzeichnisse für Agenten, eng begrenzte Tokens für Verbindungen und Richtliniendurchsetzung für Aktionen.

Wettbewerb sollte Käufern zugutekommen, wenn Plattformen interoperable Kontrollen bereitstellen. Das Modell von Microsoft kann zu Organisationen passen, die auf Entra und Microsoft Graph ausgerichtet sind.

Okta betont Governance über mehrere Clouds, Anwendungen und Agenten-Frameworks hinweg. Cloud-Anbieter werden ihre Agentendienste naturgemäß mit ihren bestehenden Workload-Identity-Systemen integrieren.

Die Gefahr ist Fragmentierung. Ein Unternehmen könnte für jede Cloud ein Agenteninventar erhalten, ein weiteres beim Identitätsanbieter und mehrere in SaaS-Administrationsportalen.

Diese Inventare werden voneinander abweichen, sofern die Organisation keinen kanonischen Prozess für Eigentümerschaft und Lebenszyklus definiert. Discovery-Tools sollten diesen Prozess speisen, statt parallele Quellen der Wahrheit zu schaffen.

Die Token-Kompatibilität ist ein weiteres Thema. OAuth kann Autorisierungsmechanismen standardisieren, doch Anbieter können sich bei Identitäts-Claims, Delegationsnachweisen und Laufzeit-Richtlinienkontrollen unterscheiden.

Die Kommunikation zwischen Agenten erhöht den Einsatz. Der erste Agent könnte die delegierte Befugnis eines Nutzers tragen, während ein nachgelagerter Agent autonom unter Anwendungsberechtigungen arbeitet.

Die Autorisierungskette muss zeigen, wo sich die Befugnis geändert hat. Andernfalls kann aus einer genehmigten Nutzeranfrage eine weitreichende Maschinenaktion ohne sichtbare Eskalation werden.

Beschaffungsteams sollten Produkte anhand realer Workflows testen. Eine ausgefeilte Verzeichnisschnittstelle ist weniger wichtig als die Frage, ob die Plattform den Zugriff über jeden betroffenen Connector hinweg sperren kann.

Sie sollten auch die Exportierbarkeit testen. Audit-Daten müssen für Incident Response, Compliance und Migration zugänglich bleiben, ohne von einer proprietären Untersuchungsansicht abhängig zu sein.

Sicherheitsteams sollten einer neuen Agentenplattform nicht uneingeschränkten Zugriff gewähren, nur um die Transparenz zu verbessern. Die Discovery-Architektur benötigt ihre eigene Least-Privilege-Prüfung.

Der Markt bewegt sich daher in Richtung Identität als gemeinsamer Infrastruktur. Die Gewinner werden Agenten nicht bloß registrieren.

Sie werden die Zuordnung plattformübergreifend bewahren, dauerhafte Zugangsdaten reduzieren, eine granulare Sperrung ermöglichen und Richtlinienentscheidungen in Datensätzen offenlegen, die externe Tools auswerten können.

Was Unternehmen vor der Skalierung von Agents prüfen sollten

Die nächste Phase wird an Nachweisen aus der Bereitstellung gemessen werden – nicht daran, wie viele Anbieter die Formulierung „erstklassige Identität“ wiederholen.

Das erste Signal ist, ob Unternehmen vollständige Inventare erstellen, die auch Schatten-Agents umfassen. Ein Verzeichnis, das nur durch formales Onboarding befüllt wird, übersieht die risikoreichsten Bereitstellungen.

Organisationen sollten Identitätsdaten mit OAuth-Freigaben, Cloud-Ressourcen, Browser-Telemetrie, API-Nutzung und SaaS-Konfigurationen abgleichen. Große Lücken würden das Versprechen eines Identity-First-Ansatzes schwächen.

Das zweite Signal ist, ob kurzlebige, klar begrenzte Autorisierungen statische Secrets ersetzen. Migrationszahlen sind wichtiger als die Fähigkeit einer Plattform, für neue Agents moderne Tokens auszustellen.

Teams sollten vorhandene Agents identifizieren, die eingebettete API-Schlüssel, gemeinsam genutzte Servicekonten und langlebige Refresh-Tokens verwenden. Anschließend sollten sie messen, wie schnell diese Zugangsdaten verschwinden.

Die Dokumentation von Microsoft bietet Unternehmen einen technischen Referenzpunkt. Die Produktionsleitlinien bevorzugen föderierte Zugangsdaten und verwaltete Identitäten gegenüber gespeicherten Client-Secrets.

Das dritte Signal ist, ob Laufzeitkontrollen plattformübergreifende Delegierung überstehen. Daran wird sich entscheiden, ob die Identität von Agents zu echter Infrastruktur wird oder zu einer weiteren isolierten Produktkategorie.

Ein sinnvoller Test beginnt mit einer menschlichen Anfrage, die mehrere Agents und Tools auslöst. Prüfer sollten die vollständige Kette rekonstruieren können, ohne unabhängige Logs manuell miteinander abgleichen zu müssen.

Der Datensatz sollte die auslösende Person, jeden beteiligten Agent, jeden Token-Austausch, die angewandte Richtlinie und jede betroffene Ressource ausweisen.

Die Sperrung sollte über dieselbe Kette hinweg funktionieren. Das Deaktivieren des auslösenden Agents darf nicht dazu führen, dass delegierte Zugangsdaten oder nachgelagerte Sitzungen aktiv bleiben.

Unternehmen sollten außerdem adversariale Tests durchführen. Ein Red Team kann bösartige Anweisungen in Inhalte einfügen, die ein autorisierter Agent voraussichtlich abrufen soll.

Der Test sollte zeigen, ob externe Richtlinien gefährliche Aktionen blockieren, nachdem das Modell die Anweisungen angenommen hat. Identität allein wird dieses Ergebnis nicht herbeiführen.

Unternehmensverantwortliche benötigen einen Entscheidungsrahmen für akzeptable Autonomie. Nicht jeder Agent erfordert dieselbe Prüfung, da die Folgen stark variieren.

Ein Rechercheassistent, der öffentliche Dokumente liest, birgt andere Risiken als ein Agent, der Produktionscode bearbeitet. Ein Agent für die Kreditorenbuchhaltung schafft wiederum eine völlig andere Kategorie.

Zugriffsprüfungen sollten diese Unterschiede widerspiegeln. Agents mit hoher Wirkung benötigen kürzere Zertifizierungszyklen, engere Grenzen, stärkere Überwachung und festgelegte Punkte für menschliche Freigaben.

Pläne für die Reaktion auf Sicherheitsvorfälle müssen Agents als Akteure einbeziehen. Teams sollten wissen, wie sie eine Identität suspendieren, Tokens ungültig machen, Konnektoren isolieren, Logs sichern und betroffene Daten identifizieren.

Der Plan sollte auch kompromittierte Drittanbieter-Agents abdecken. Vorab gewährtes OAuth-Vertrauen kann gefährlich bleiben, selbst wenn der interne Code des Unternehmens nie kompromittiert wurde.

Sicherheitsteams sollten Anbieter fragen, wie schnell sie Kompromittierungen von Konnektoren offenlegen und erteilte Zugriffe widerrufen. Vertragliche Regelungen sollten Logs, Benachrichtigungen und Unterstützung bei Untersuchungen abdecken.

Entwickler benötigen bereits zur Entwurfszeit klarere Standards. Jeder neue Agent sollte seinen Eigentümer, seine Tools, Datenklassen, das Autorisierungsmuster und die maximal zulässige Konsequenz angeben.

Diese Informationen können Teil eines internen Datensatzes für KI-Workflows werden. Produkt-, Sicherheits- und Engineering-Teams können Änderungen dann am ursprünglichen Zweck messen.

Der Beitrag in Google News bietet einen nützlichen Zwischenstand, doch Wiederholung sollte nicht mit einer Lösung verwechselt werden. Identitätsanbieter haben das Problem klarer definiert, als Unternehmen die Antwort umgesetzt haben.

Die drei Fragen bilden eine praktische erste Überprüfung. Kann Ihre Organisation jeden Agent benennen? Kann sie jedes erreichbare System zuordnen? Kann sie jede wesentliche Aktion begrenzen und rekonstruieren?

Ein „Ja“ braucht Nachweise aus Verzeichnissen, Tokens, Richtlinien und Logs. Eine für ein Audit gepflegte Tabelle beweist keine Kontrolle zur Laufzeit.

Beginnen Sie mit einem Produktionsworkflow und verfolgen Sie ihn von der menschlichen Absicht bis zur endgültigen Wirkung. Entfernen Sie gemeinsam genutzte Zugangsdaten, begrenzen Sie jede Verbindung und legen Sie fest, wo automatische Aktionen enden müssen.

Testen Sie anschließend Sperrung und Rekonstruktion unter Druck. Wenn eines von beidem scheitert, verfügt der Agent über mehr Autonomie, als die Organisation sicher erklären kann.

Google News wird zur nächsten Schlagzeile weiterziehen. Die Identitätslücke bleibt bestehen, bis Unternehmen jede Agent-Aktion mit begrenzter Berechtigung, klarer Verantwortlichkeit und durchsetzbaren Richtlinien verknüpfen können.