KI-Agenten brauchen Identität, bevor sie ein Gateway brauchen

Hush Security schaffte es mit einer klaren Aussage in Google News: Unternehmen müssen jeden KI-Agenten identifizieren, bevor sie ein Gateway um dessen Datenverkehr legen. Der Konflikt ist relevant, weil viele Agenten weiterhin menschliche Berechtigungen übernehmen oder Anmeldedaten gemeinsam nutzen. Ein Gateway kann Verbindungen prüfen, aber keine Verantwortlichkeit herstellen, wenn jeder Aufrufer gleich aussieht.

Das Argument folgte auf die Finanzierungsankündigung von Hush Security im Juli 2026 und die Erweiterung seiner Plattform für nichtmenschliche Identitäten. Das Unternehmen sammelte 30 Millionen US-Dollar ein und stellte ein Identity Gateway vor, das Agenten erkennen, Identitäten zuweisen, begrenzten Zugriff vermitteln und ihre Aktionen aufzeichnen soll. Die zentrale Idee ist einfach: Sicherheitskontrollen können einen Agenten nicht zuverlässig steuern, solange sie nicht wissen, welcher Agent handelt.

Diese Position stellt einen Gateway-first-Ansatz infrage, der sich in der Unternehmens-KI zunehmend etabliert. Cisco, Palo Alto Networks, Microsoft und andere Sicherheitsanbieter platzieren inzwischen Kontrollen zwischen Agenten und Tools. Ein Gateway sieht jedoch Anfragen, nicht unbedingt die vollständige Identität, den Eigentümer, die delegierte Befugnis oder den Ausführungsverlauf dahinter. Das Ergebnis ist eine vertraute Sicherheitsgrenze mit einem ungewohnten Zurechnungsproblem.

Dabei geht es nicht um die Frage, ob Gateways wichtig sind. Sie bleiben nützliche Durchsetzungspunkte für Authentifizierung, Richtlinienprüfungen, Datenverkehrsinspektion und Tool-Beschränkungen. Die Frage lautet, ob Unternehmen den Kontrollpunkt installieren, bevor sie allen Beteiligten eindeutige Anmeldedaten ausstellen.

Die Google-News-Schlagzeile weist auf einen größeren Identitätswandel hin

Hush Security definiert die Sicherheit von KI-Agenten als Identitätsproblem neu, das Gateways allein nicht lösen können.

Das Unternehmen trat 2025 mit einem Fokus auf nichtmenschliche Identitäten aus dem Stealth-Modus. Dazu zählen Servicekonten, API-Schlüssel, Zugriffstoken und andere Anmeldedaten, die von Software statt von Beschäftigten verwendet werden. Hush widmete sich zunächst einem langjährigen Unternehmensproblem: Organisationen sammeln häufig Maschinenanmeldedaten an, die schwer zu inventarisieren, zu rotieren und zu widerrufen sind.

Autonome Agenten erhöhen den Einsatz. Sie können Anweisungen interpretieren, Tools auswählen, Daten abrufen und während einer Aufgabe Aktionen über mehrere Systeme hinweg ausführen. Eine herkömmliche Automatisierung folgt einer vorgegebenen Abfolge. Ein Agent kann seinen Weg nach Erhalt neuer Informationen ändern, wodurch seine effektiven Berechtigungen schwerer vorhersehbar werden.

In seinem Bericht vom 30. Juli beschrieb VentureBeat, wie Hush diese frühere Arbeit zu einem Agentenidentitäts-Gateway ausbaute. Die vorgeschlagene Plattform sitzt zwischen Agenten und Unternehmensressourcen. Hush zufolge kann sie Agenten erkennen, mit menschlichen Eigentümern verknüpfen, aufgabenspezifischen Zugriff ausstellen, Aktivitäten protokollieren und einen Agenten zentral widerrufen.

Hush nennt sein Zugriffsmodell „least agency“. Der Begriff adaptiert das Sicherheitsprinzip der minimalen Berechtigung, das einem Nutzer oder Workload nur den für eine Aufgabe erforderlichen Zugriff gewährt. Least agency ergänzt diese Entscheidung um das Ziel des Agenten, den Ausführungskontext und die delegierte Befugnis.

Stellen Sie sich einen Coding-Agenten vor, der einen Produktionsfehler diagnostizieren soll. Er könnte Lesezugriff auf Logs, Quellcode und Deployment-Metadaten benötigen. Er sollte nicht automatisch die Berechtigung erhalten, Abrechnungsdaten zu ändern, Kundendatenbanken herunterzuladen oder seine eigene Sicherheitsrichtlinie umzuschreiben.

Dieselbe Unterscheidung gilt für Produktivitätsagenten. Ein Assistent, der eine Besprechungsunterlage vorbereitet, könnte Kalender, Notizen und freigegebene Dokumente durchsuchen. Er benötigt keinen uneingeschränkten Zugriff auf jedes Postfach, Cloud-Laufwerk oder jede Administrationskonsole, die der Mitarbeiterin oder dem Mitarbeiter zur Verfügung steht, die bzw. der ihn gestartet hat.

Ein Gateway kann verbotene Ziele oder fehlerhafte Anfragen blockieren. Seine Richtlinien werden jedoch grob, wenn mehrere Agenten dasselbe OAuth-Token oder Servicekonto verwenden. Es kann wissen, dass eine genehmigte Anmeldedatenkombination eine Datei angefordert hat. Es weiß möglicherweise nicht, welcher Agent die Anfrage stellte, warum er handelte oder ob die Aktion innerhalb der ursprünglichen Delegation blieb.

Deshalb hat die Google-News-Schlagzeile mehr Gewicht als eine typische Finanzierungsstory. Hush fügt nicht bloß eine weitere Inspektionsschicht hinzu. Das Unternehmen argumentiert, dass Identität zum zentralen Datensatz für Eigentümer, Zweck, Berechtigungen, Sitzungen und Aktionen eines Agenten werden muss.

Dieses Modell verändert auch die Reaktion auf Vorfälle. Sicherheitsteams beginnen eine Untersuchung üblicherweise mit der Frage, wer auf eine Ressource zugegriffen hat. Gemeinsam genutzte Anmeldedaten können die Antwort auf eine Anwendung, einen Beschäftigten oder ein Servicekonto reduzieren. Eine eindeutige Agentenidentität bietet einen engeren Ausgangspunkt, insbesondere wenn mehrere autonome Prozesse unter der Befugnis einer Person arbeiten.

Gemeinsam genutzte Anmeldedaten lassen Gateways raten

Ein Gateway kann Richtlinien nur so präzise durchsetzen wie die Identität und der Kontext, die jeder Anfrage beigefügt sind.

Viele frühe Unternehmensagenten wurden wie Skripte bereitgestellt. Entwickler speicherten einen API-Schlüssel, wiesen ein Servicekonto zu oder reichten das OAuth-Token des menschlichen Nutzers durch. Dieser Ansatz macht einen Prototyp schnell funktionsfähig, fasst jedoch mehrere Akteure unter einer Sicherheitsidentität zusammen.

Der Mitarbeiter, der Agenten-Host, das Modell, der einzelne Agent und die Tool-Sitzung können alle unter derselben Autorisierung erscheinen. Wenn der Agent Subagenten erstellt, wird die Kette noch schwieriger zu rekonstruieren. Ein nachgelagerter Dienst kann ein gültiges Token erhalten, ohne zu wissen, welche Komponente die Aktion ausgelöst hat.

Die Umfrage von VentureBeat unter 107 Unternehmensbefragten vom Juni 2026 ergab, dass 69 Prozent gemeinsam genutzte API-Schlüssel in Agentenbereitstellungen verwendeten. Die Studie zur Agentensicherheit stellte zudem fest, dass 82 Prozent sich hauptsächlich auf Kontrollen von Modellanbietern oder Hyperscalern stützten.

Diese Kontrollen bieten nützliche Schutzmaßnahmen. Prompt-Filter können bekannte Injection-Muster erkennen, Systeme zur Verhinderung von Datenverlust können sensible Inhalte markieren und Cloud-Richtlinien können den Zugriff auf verwaltete Ressourcen beschränken. Keine dieser Funktionen erzeugt automatisch eine eindeutige Identität für jede Agenteninstanz.

Die Umfrage ergab für Microsoft Entra Agent ID eine Nutzung von 13 Prozent unter den Befragten. Andere identitätsspezifische Produkte lagen im einstelligen Bereich. Diese Lücke deutet darauf hin, dass Unternehmen allgemeine KI-Schutzmaßnahmen schneller bereitgestellt haben als agentenspezifische Rechenschaftspflicht.

Das Ungleichgewicht wird ernster, wenn ein Agent übermäßige Befugnisse erhält. Eine gemeinsam genutzte Administratoranmeldung wird nicht sicher, nur weil ein Gateway sie überwacht. Wenn die Richtlinie der Anmeldung erlaubt, eine Aktion auszuführen, kann das Gateway eine gefährliche Anfrage genehmigen, die technisch gültig ist.

Prompt Injection veranschaulicht das Problem. Ein Agent könnte nicht vertrauenswürdigen Text lesen, der ihn anweist, vertrauliches Material abzurufen oder eine Konfiguration zu ändern. Die Anweisung kann über ein Dokument, eine Website, E-Mail, Tool-Antwort oder einen Datenbankeintrag eingehen. Ein Sprachfilter steht dann vor der schwierigen Aufgabe, legitime Absicht von manipulierter Absicht zu unterscheiden.

Identitätskontrollen adressieren eine andere Ebene. Sie müssen nicht entscheiden, ob jeder Satz böswillig ist. Sie können die maximale Befugnis begrenzen, die dem Agenten zur Verfügung steht – unabhängig davon, was das Modell entscheidet.

Beispielsweise kann ein Recherche-Agent mit schreibgeschütztem Zugriff nach einer feindlichen Anweisung kein Quell-Repository löschen. Ein temporärer Support-Agent kann seinen Zugriff auf Kundendaten nicht behalten, nachdem sein Ticket geschlossen wurde. Ein Finanzagent, der berechtigt ist, eine Zahlung vorzubereiten, kann diese Zahlung nicht zugleich genehmigen, sofern die Richtlinie nicht beide Aktionen erlaubt.

Kurzlebige Anmeldedaten reduzieren die Gefährdung zusätzlich. Statt ein wiederverwendbares Geheimnis in einer Agentenumgebung zu hinterlegen, kann ein Identitätssystem ein Token für eine Aufgabe, Ressource und ein Zeitfenster ausstellen. Das Token läuft automatisch ab und kann widerrufen werden, wenn die Sitzung endet.

Dieses Modell unterstützt auch bessere Protokolle. Ein Audit-Datensatz sollte den Agenten, seinen menschlichen Sponsor, die Aufgabe, die Richtlinienentscheidung, die verwendeten Anmeldedaten und die daraus resultierende Aktion identifizieren. Wenn nur die Gateway-Anfrage protokolliert wird, müssen Ermittler nach einem Vorfall zu viel ableiten.

Unternehmen bewahren bereits Kontext bei der Verwaltung wichtiger menschlicher Aktivitäten. Sie erfassen Nutzer, Gerät, Anwendung, Sitzung, Authentifizierungsmethode und Ressource. Autonome Software benötigt mindestens vergleichbare Details, weil sie viele Aktionen ausführen kann, ohne für eine menschliche Prüfung anzuhalten.

Die Herausforderung ist das Volumen. Eine Organisation kann Agenten schneller erstellen, kopieren oder beenden, als sie Beschäftigte einstellt. Die Identitätsbereitstellung muss daher automatisiert werden. Eine manuelle Registrierung würde Verzögerungen verursachen, Umgehungen fördern und Schattenagenten außerhalb der Governance zurücklassen.

Dieser Druck macht Lifecycle-Management unverzichtbar. Jede Agentenidentität benötigt ein Erstellungsereignis, einen Eigentümer, einen genehmigten Zweck, ein Richtlinienset, eine Ablaufregel und einen Widerrufspfad. Wenn irgendein Teil undefiniert bleibt, erhält das Gateway Datenverkehr von einem Akteur, den die Organisation nicht vollständig erklären kann.

Ein Gateway kontrolliert den Datenverkehr, doch Identität begründet Befugnis

Die stärkste Architektur behandelt Identität als Quelle der Befugnis und das Gateway als einen Ort, an dem diese Befugnis durchgesetzt wird.

Ein KI-Gateway vermittelt üblicherweise die Kommunikation zwischen Modellen, Agenten, Tools und Datendiensten. Es kann Verbindungen authentifizieren, Anfragen prüfen, Ratenlimits anwenden, Inhalte filtern und Logs erzeugen. Ein MCP-Gateway übernimmt ähnliche Aufgaben für Model Context Protocol-Verbindungen.

MCP ist ein offenes Protokoll, das KI-Anwendungen über eine gemeinsame Schnittstelle externe Tools entdecken und aufrufen lässt. Es verringert den Bedarf an individuellem Integrationscode, doch standardisierte Verbindungen können auch die für einen Agenten erreichbare Angriffsfläche erweitern.

Ein Gateway ist nützlich, weil es einen zentralen Kontrollpunkt für Richtlinien bietet. Sicherheitsteams können Regeln vor vielen Tools platzieren, statt jedes Backend zu ändern. Diese architektonische Bequemlichkeit beantwortet nicht, wer der Agent ist oder woher seine Befugnis stammt.

Identität liefert diese Grundlage. Eine eindeutige Identität kann den Agenten mit seinem Code, Host, Eigentümer, seiner Aufgabe und seinen genehmigten Fähigkeiten verknüpfen. Die Autorisierung kann dann entscheiden, was diese Identität unter den aktuellen Bedingungen tun darf.

Die Unterscheidung ähnelt einer Sicherheitskontrolle am Flughafen. Die Kontrolle jedes Reisenden ist wertvoll, doch der Prozess hängt davon ab, zu wissen, welcher Reisende welches Dokument vorlegt. Gepäck zu prüfen, ohne die Identität festzustellen, erzeugt einen unvollständigen Sicherheitsdatensatz.

Das US National Institute of Standards and Technology ordnete dieselben Komponenten 2026 in einen umfassenderen Rahmen ein. Sein Projekt zur Agentenidentität identifizierte Agentenidentifikation, Autorisierung, Delegation, Protokollierung, Transparenz und Datenherkunft als miteinander verbundene Arbeitsbereiche.

NIST verwies zudem auf etablierte Technologien, statt eine proprietäre Lösung vorzuschlagen. OAuth kann delegierte Autorisierung übertragen, OpenID Connect kann Authentifizierungsinformationen ausdrücken und SCIM kann die Identitätsbereitstellung unterstützen. SPIFFE und SPIRE können kryptografisch überprüfbare Identitäten für Software-Workloads ausstellen.

Diese Technologien lösen unterschiedliche Teile des Problems. OAuth beschreibt, welchen Zugriff ein Token vermittelt. OpenID Connect hilft dabei, eine authentifizierte Partei zu beschreiben. SCIM kann Identitätsdatensätze erstellen oder deaktivieren. SPIFFE kann bestätigen, dass ein Workload, der in kontrollierter Infrastruktur läuft, tatsächlich der Workload ist, für den er sich ausgibt.

Keine davon erfasst unabhängig den vollständigen Lebenszyklus eines autonomen Agenten. Ein Unternehmen muss weiterhin eine Workload-Identität mit menschlicher Delegation, Richtlinien, Aufgabenbereich und Aktionsverlauf verknüpfen.

Dieser fehlende Zusammenhang erklärt, warum es nicht ausreicht, einem Agenten einfach einen Namen zuzuweisen. Eine selbst deklarierte Kennung innerhalb einer Anfrage kann geändert oder kopiert werden. Eine vertrauenswürdige Identität muss von einem System ausgestellt oder verifiziert werden, das der empfangende Dienst akzeptiert.

Die Identität muss auch bei Bewegungen über Infrastruktur hinweg bestehen bleiben. Agenten können in Desktop-Anwendungen, Cloud-Containern, Entwicklungsumgebungen, verwalteten Plattformen und Diensten Dritter laufen. Ein Credential, das nur in einem Cluster verankert ist, kann seine Bedeutung verlieren, wenn ein Agent eine Organisationsgrenze überschreitet.

Ein Papier der OpenID Foundation zum Identitätsmanagement für Agenten beschreibt diese Portabilitätsherausforderung. Es weist darauf hin, dass eine MCP-Client-Kennung nicht zwingend eine verlässliche Workload- oder Agentenidentität ist. Außerdem erläutert es, warum infrastrukturbasierte Attestierung schwieriger wird, wenn Agenten Vertrauensdomänen überschreiten.

Dieses Problem trennt Authentifizierung von Handlungsbefugnis. Authentifizierung bestätigt, dass eine Softwarekomponente ein Credential kontrolliert. Handlungsbefugnis beschreibt, warum diese Komponente handelt, für wen sie handelt und welche Delegation sie derzeit besitzt.

Ein Gateway benötigt beide Arten von Informationen. Es sollte einen nicht verifizierten Aufrufer ablehnen, aber auch einen verifizierten Agenten, der seine delegierte Aufgabe überschreitet. Eine erfolgreiche Authentifizierung darf nicht zur Berechtigung werden, jede für den unterstützenden Nutzer verfügbare Aktion auszuführen.

Hushs Ansatz platziert identitätsvermittelnde Prozesse, die von Richtlinien gesteuert werden, vor dem Ressourcenzugriff. Das Gateway wird dann zu einem Durchsetzungsmechanismus für diese vermittelte Autorität. Diese Reihenfolge ermöglicht engere Berechtigungen und eine klarere Zuordnung als ein Gateway, das die Identität erst aus dem Datenverkehr ableitet.

Die Architektur ist weiterhin von Integration abhängig. Anwendungen und Tool-Server müssen die Identitätsansprüche, Scopes oder Capability-Tokens berücksichtigen, die sie erhalten. Wenn nachgelagerte Systeme jede Anfrage in einem einzigen privilegierten Backend-Konto zusammenführen, verliert der Identitätsnachweis seinen Durchsetzungswert.

Sicherheitsanbieter konzentrieren sich auf denselben Kontrollpunkt

Der Markt bewegt sich in Richtung Agentenidentität, doch die Anbieter unterscheiden sich darin, ob Identität, Netzwerkverkehr oder Endpoint-Verhalten die Durchsetzung anführen soll.

Hush ist nicht allein damit, Agenten als neue Klasse nichtmenschlicher Akteure zu behandeln. Microsoft, Cisco, Palo Alto Networks, 1Password, Okta, Ping Identity und mehrere Start-ups haben auf Agenten ausgerichtete Funktionen für Identität oder Governance eingeführt.

Ciscos Duo Agentic Identity registriert Agenten als eigenständige Objekte, die menschlichen Eigentümern zugeordnet sind. Seine umfassendere Sicherheitsarchitektur kann Tool-Aufrufe über ein MCP-Gateway leiten. Palo Alto Networks hat innerhalb von Prisma AIRS ein Agentenregister, einen Identitätsanbieter für Agenten und Gateway-Kontrollen vorgestellt.

Microsoft verteilt die Agenten-Governance auf Entra, Purview, Defender und Sentinel. Entra Agent ID konzentriert sich auf das Erstellen und Verwalten von Identitäten für Agenten. Andere Microsoft-Dienste befassen sich mit Datenkontrollen, Bedrohungserkennung und Überwachung.

CrowdStrike betont Endpoint-Aktivitäten. Dieser Ansatz verfolgt, was Softwareprozesse auf einem Gerät tun, statt sich nur auf die von einem Modell geäußerte Absicht zu verlassen. Er kann helfen, Dateiänderungen, Prozessstarts und andere konkrete Aktionen nach erfolgreicher Authentifizierung zu erkennen.

Die unterschiedlichen Ansätze ergänzen einander, konkurrieren jedoch darum, zur primären Kontrollebene zu werden. Identitätsanbieter argumentieren, dass jede Aktion mit einem vertrauenswürdigen Akteur und klar abgegrenzter Autorität beginnen sollte. Netzwerkanbieter sehen Gateways als zentrale Inspektionspunkte. Endpoint-Anbieter konzentrieren sich auf beobachtbare Ausführung.

Die RSAC 2026 zeigte, wie schnell diese Kategorien zusammenwachsen. Die VentureBeat-Analyse zu Sicherheitsframeworks für Agenten stellte fest, dass große Anbieter Register, Gateways, Identitätsobjekte und Runtime-Monitoring eingeführt hatten.

Die verbleibenden Lücken zeigen, warum keine einzelne Kontrolle ausreicht. Ein Agent könnte jede Credential-Prüfung bestehen und dennoch die Richtlinie ändern, die sein eigenes Verhalten steuert. Ein Gateway könnte jeden Tool-Aufruf sehen, ohne eine Delegationskette rekonstruieren zu können. Ein Endpoint-Sensor könnte eine Aktion beobachten, ohne zu wissen, ob der Agent über gültige geschäftliche Autorität verfügte.

Die Delegation über mehrere Agenten hinweg schafft den schwierigsten Fall. Angenommen, ein Beschaffungsagent bittet einen Rechercheagenten, Lieferanten zu vergleichen. Der Rechercheagent erstellt anschließend einen Browsing-Agenten, der Dokumente von einem Dienst eines Drittanbieters anfordert.

Jede Übergabe sollte Autorität einschränken oder erhalten, sie jedoch niemals stillschweigend erweitern. Der endgültige Dienst benötigt genügend Nachweise, um zu bestimmen, wer die Aufgabe initiiert hat, welche Agenten beteiligt waren und ob die angeforderte Aktion zum ursprünglichen Zweck passt.

Herkömmliche Nutzer-Impersonation funktioniert hier schlecht. Wenn jeder untergeordnete Agent die Identität des Mitarbeiters erbt, können nachgelagerte Systeme den ursprünglichen Nutzer nicht von autonomen Delegierten unterscheiden. Das Sperren eines kompromittierten untergeordneten Agenten könnte die Beendigung der gesamten Nutzersitzung erfordern.

Ein besseres Modell verleiht jedem Agenten eine eigene Identität und behält zugleich eine signierte Delegationskette bei. Der untergeordnete Agent erhält nur die Teilmenge an Berechtigungen, die für seinen Auftrag erforderlich ist. Protokolle bewahren die Beziehung zwischen menschlichem Eigentümer, übergeordnetem Agenten, untergeordnetem Agenten und der resultierenden Aktion.

Diese Struktur ähnelt dem Austausch kurzlebiger Credentials durch sichere Cloud-Workloads. Agenten bringen jedoch unsicheres Verhalten und Ziele in natürlicher Sprache mit. Richtlinien müssen sowohl die technische Identität als auch den sich verändernden Aufgabenkontext berücksichtigen.

Hinzu kommt ein praktisches Integrationsproblem. Unternehmen betreiben bereits Identitätsanbieter, Systeme für privilegierten Zugriff, API-Gateways, Service Meshes, Endpoint-Agenten und Plattformen für Sicherheitsmonitoring. Eine separate Ebene für Agentenidentitäten kann eine weitere Konsole und Quelle der Wahrheit schaffen.

Die erfolgreichen Ansätze müssen sich mit bestehender Identitätsinfrastruktur verbinden. Sicherheitsteams werden Systeme ablehnen, die verlangen, dass jede Anwendung ein proprietäres Protokoll übernimmt oder ein doppeltes Mitarbeiterverzeichnis pflegt.

Dieser Druck begünstigt standardbasierte Claims, kurzlebige Tokens und portable Audit-Aufzeichnungen. Er begünstigt zudem Produkte, die Schattenagenten erkennen können, bevor diese eine formelle Registrierung beantragen.

Erkennung ist wichtig, weil Mitarbeitende Coding-Assistenten installieren oder lokale Agenten ohne Sicherheitsfreigabe verbinden können. Eine perfekte Identitätsrichtlinie bewirkt nichts für einen Agenten, von dessen Existenz die Organisation nichts weiß. Netzwerk-, Endpoint-, Cloud- und Identitätstelemetrie tragen alle dazu bei, solche Deployments zu finden.

Die Konvergenz des Marktes stützt daher Hushs Prämisse, ohne jede Produktbehauptung zu bestätigen. Identität wird notwendig, wird aber neben Gateways, Sandboxes, Endpoint-Monitoring und Datenkontrollen arbeiten. Der eigentliche Wettbewerb betrifft die Frage, welche Ebene den maßgeblichen Datensatz definiert.

Identität macht einen Agenten nicht sicher

Eine verifizierte Identität verbessert Kontrolle und Rechenschaftspflicht, beweist jedoch nicht, dass das Verhalten eines Agenten vertrauenswürdig ist.

Diese Einschränkung ist die stärkste Herausforderung für ein identitätsorientiertes Narrativ. Ein authentifizierter Agent kann dennoch eine schlechte Entscheidung treffen, einer böswilligen Anweisung folgen, Daten offenlegen oder ein unsicheres Tool aufrufen. Identität zeigt Verteidigern, wer gehandelt hat. Sie garantiert nicht, dass die Handlung sinnvoll war.

Die traditionelle Sicherheit liefert eine Warnung. Legitime Konten verursachen viele schädliche Vorfälle, weil Angreifer Credentials stehlen, Mitarbeitende zu weitreichenden Zugriff erhalten oder genehmigte Software sich unerwartet verhält. Eine gültige Identität ist nur der Beginn einer Richtlinienentscheidung.

Agentensysteme erhöhen die Unsicherheit, weil sich ihre Pläne während der Ausführung ändern können. Ein Modell kann nach dem Lesen neuer Informationen ein anderes Tool auswählen. Es kann eine Einschränkung missverstehen oder nicht vertrauenswürdige Inhalte als Anweisung behandeln.

Deshalb bleibt Sandboxing wichtig. Eine Sandbox isoliert die Ausführung, damit ein kompromittierter oder fehlerhafter Agent das Hostsystem nicht frei beeinflussen kann. Identität kann zulässige Ressourcen begrenzen, während Isolation einschränkt, was der Prozess technisch erreichen kann.

Auch Prompt- und Output-Kontrollen behalten eine Rolle. Sie können bekannte Angriffsmuster, sensible Daten oder verbotene Inhalte erkennen, bevor eine Anfrage ein anderes System erreicht. Ihre Schwäche liegt darin, semantische Interpretation als einzige Verteidigung zu behandeln.

Eine vollständige Architektur benötigt mehrschichtige Verteidigung. Die Identitätsebene etabliert den Akteur und die delegierte Autorität. Das Gateway setzt Verbindungsrichtlinien durch. Die Sandbox begrenzt die Ausführung. Endpoint- und Cloud-Monitoring zeichnen tatsächliches Verhalten auf. Datenkontrollen beschränken sensible Informationen.

Die Policy Engine muss außerhalb der Kontrolle des Agenten bleiben. Wenn ein Agent die Regeln bearbeiten kann, die seine eigenen Berechtigungen definieren, kann eine gültige Identität Ermittlern zwar helfen, den Schaden zuzuordnen, ihn jedoch nicht verhindern.

Der Schutz von Credentials stellt ein weiteres Risiko dar. Jedem Agenten ein einzigartiges langlebiges Geheimnis zu geben, würde die Zuordnung verbessern, zugleich aber die Zahl der Geheimnisse vervielfachen, die Angreifer stehlen können. Identitätssysteme sollten kurzlebige Credentials ausstellen und wiederverwendbare Geheimnisse außerhalb der Umgebung des Agenten halten.

Organisationen müssen zudem permanenten Agentenwildwuchs vermeiden. Identitäten automatisch zu erstellen ist nützlich, aber inaktive Identitäten benötigen einen automatischen Ablauf. Andernfalls ersetzt das Unternehmen unverwaltete API-Schlüssel durch unverwaltete Agentenkonten.

Auch menschliche Eigentümerschaft kann irreführend werden. Einen Agenten einem Mitarbeiter zuzuordnen bedeutet nicht, dass dieser Mitarbeiter jede Aktion überprüft hat. Aufzeichnungen zur Rechenschaftspflicht sollten Sponsoring, Genehmigung, Betrieb und Ausführung unterscheiden.

Ein Manager kann einen Workflow genehmigen, während ein Entwickler den Agenten bereitstellt und ein anderer Mitarbeiter eine Aufgabe startet. Alle drei Rollen in einem einzigen Feld „Eigentümer“ zusammenzufassen, kann falsche Gewissheit erzeugen.

Auch die Datenherkunft erfordert ähnliche Sorgfalt. Ein Agent kann Dokumente, generierten Text, Tool-Antworten und gespeicherten Kontext kombinieren. Sicherheitsprotokolle sollten bewahren, welche Informationen wichtige Aktionen beeinflusst haben, ohne mehr sensible Inhalte als nötig zu erfassen.

Für Wissensarbeiter reicht dieses Problem über die Cybersicherheit hinaus. Agenten handeln zunehmend mit persönlichen Notizen, Projektdokumenten, Transkripten und früheren Entscheidungen. Eine gut organisierte persönliche Wissensbasis kann den Kontext verbessern, doch der Zugriff benötigt weiterhin klare Grenzen.

Ein Agent, der ein wöchentliches Update vorbereitet, benötigt möglicherweise ausgewählte Projektunterlagen. Er sollte nicht uneingeschränkten Zugriff auf jede private Notiz erben, nur weil alle Informationen einem Nutzer gehören. Identität und Aufgabenbereich helfen, nützlichen Kontext von unnötiger Offenlegung zu trennen.

Hushs Behauptungen erfordern daher eine unabhängige Validierung in Produktionsumgebungen. Käufer sollten fragen, ob das System Agenteninstanzen kryptografisch identifiziert, sich in bestehende Identitätsanbieter integriert und Identität an nachgelagerte Tools weitergibt.

Sie sollten außerdem die Geschwindigkeit des Widerrufs, das Verhalten bei Richtlinienfehlern, die Verfolgung von Delegationen und die Vollständigkeit der Protokolle testen. Eine Kontrollebene, die während eines Tool-Aufrufs den Kontext verliert oder bei einem Ausfall standardmäßig weitreichenden Zugriff gewährt, kann das Risiko erneut schaffen, das sie zu verringern verspricht.

Die Finanzierungs- und Produktankündigung des Unternehmens belegen Marktabsicht, keine gemessenen Sicherheitsresultate. Öffentliche Nachweise zeigen bislang nicht, wie die Plattform in jeder Desktop-, Cloud- und Umgebung für verwaltete Agenten funktioniert.

Diese Unsicherheit entkräftet keine identitätsorientierte Architektur. Sie definiert den Maßstab, an dem Produkte bewertet werden sollten. Die nützliche Frage ist nicht, ob ein Dashboard einen Agenten auflistet. Sie lautet, ob Identität die Autorität dieses Agenten zuverlässig begrenzt, zuordnet und beendet.

Worauf Google-News-Leser als Nächstes achten sollten

Drei Signale werden zeigen, ob Agentenidentität zu echter Infrastruktur wird oder eine Kategorie des Sicherheitsmarketings bleibt.

Das erste Signal ist die Einführung eigenständiger Identitäten in der Produktion. Sicherheitsteams sollten über die Zahl der erkannten oder registrierten Agenten hinausblicken. Die aussagekräftige Kennzahl ist, wie viele aktive Agenten keine gemeinsamen Credentials oder uneingeschränkten menschlichen Tokens mehr verwenden.

Belege für Veränderungen wären kurzlebige Anmeldedaten, aufgabenbezogene Zugriffe, automatische Abläufe und nachgelagerte Dienste, die die Agentenkennung beibehalten. Bleiben gemeinsame Schlüssel verbreitet, wird die Einführung eines Gateways allein die Lücke bei der Verantwortlichkeit nicht schließen.

Dieses Signal wird das Identity-First-Argument stärken, wenn Unternehmen weniger gemeinsam genutzte Dienstkonten und mehr widerrufbare Agentensitzungen melden. Es wird das Argument schwächen, wenn Identitätsprodukte auf Bestands-Dashboards beschränkt bleiben, während sich der Laufzeitzugriff nicht verändert.

Das zweite Signal ist die Unterstützung von Delegationsketten. Unternehmensagenten werden zunehmend Teilaufgaben erstellen, spezialisierte Agenten aufrufen und organisatorische Grenzen überschreiten. Produkte müssen die Berechtigung über diese Übergaben hinweg bewahren.

Eine glaubwürdige Implementierung sollte den ursprünglichen menschlichen Auftraggeber, jeden beteiligten Agenten, die übertragenen Berechtigungen und die daraus resultierenden Aktionen ausweisen. Jede untergeordnete Identität sollte nicht mehr Berechtigung erhalten, als ihre übergeordnete Instanz delegieren kann.

Beobachten Sie Standardisierungsgremien und Anbieter auf interoperable Möglichkeiten, diese Beziehungen auszudrücken. Proprietäre Delegationsaufzeichnungen können innerhalb einer Plattform funktionieren, doch Unternehmen nutzen Agenten mehrerer Anbieter. Die plattformübergreifende Verifizierung wird darüber entscheiden, ob die Identität außerhalb der Umgebung eines Anbieters erhalten bleibt.

Dieses Signal stärkt die These, wenn MCP-Tools, Agentenplattformen und Identitätsanbieter überprüfbare Delegationsnachweise austauschen können. Es schwächt sie, wenn jede Plattform Agenten an der Grenze wieder in gewöhnliche Benutzertokens übersetzt.

Das dritte Signal ist die Eindämmung von Vorfällen. Identität ist besonders wichtig, wenn sich ein Agent fehlerhaft verhält oder kompromittiert wurde. Anbieter müssen zeigen, dass Verteidiger einen einzelnen Agenten isolieren können, ohne einen Mitarbeiter, eine Anwendung oder einen gesamten Workflow außer Betrieb zu setzen.

Sinnvolle Tests umfassen den sofortigen Widerruf, die Sperrung bestehender Sitzungen, das Blockieren untergeordneter Agenten und die Rekonstruktion der Aktionskette. Unternehmen sollten außerdem prüfen, dass die Durchsetzung von Richtlinien sicher fehlschlägt, wenn die Identitätsinfrastruktur nicht verfügbar ist.

Sicherheitsteams sollten Protokolle aus Identitätssystemen, Gateways, Endpunkten und nachgelagerten Anwendungen vergleichen. Lassen sich diese Aufzeichnungen nicht korrelieren, fehlt dem Unternehmen weiterhin ein verlässlicher Gesamtbericht über den Vorfall.

Erfolg würde Hushs Position stärken, indem er zeigt, dass Agentenidentität Ergebnisse verändert und nicht nur die Sichtbarkeit verbessert. Wiederholte Vorfälle mit authentifizierten, aber nicht eingedämmten Agenten würden zeigen, dass der Markt Identität als eigenständige Verteidigung überschätzt hat.

Die Einordnung von Google News liegt mit der Reihenfolge weitgehend richtig. Unternehmen sollten zunächst feststellen, wer ein Agent ist, wessen Berechtigung er trägt und wie lange diese Berechtigung gilt, bevor sie ein Gateway als ausreichende Governance betrachten.

Der nächste Schritt ist praktisch: Prüfen Sie einen Produktionsagenten von seiner Erstellung bis zu seinem letzten Tool-Aufruf. Kann Ihr Team seinen Eigentümer, seine Aufgabe, Anmeldedaten, Berechtigungen, Subagenten, Datenzugriffe und den Widerrufspfad identifizieren? Wenn eine Antwort von einem gemeinsamen Token oder einer Schlussfolgerung aus dem Datenverkehr abhängt, kam das Gateway, bevor die Identitätsgrundlage bereit war.