Unternehmen können ihre KI-Agenten nicht mehr von ihren Mitarbeitern unterscheiden

Die meisten Enterprise-Sicherheitsteams haben ihre Abwehr um eine einfache Annahme herum aufgebaut: Ein Login repräsentiert eine Person. Diese Annahme ist irgendwann in den letzten zwei Jahren zerbrochen, und die meisten Organisationen haben noch nicht damit Schritt gehalten. Heutige AI Agents authentifizieren sich bei internen Diensten, rufen APIs auf, ziehen vertrauliche Datensätze und verketten mehrstufige Workflows miteinander – ohne dass an jeder Station ein Mensch auf „Genehmigen" klickt. Die Identity-Layer, die eine Zero-Trust-Architektur schützen sollte, deckt sich nicht mehr sauber mit dem, wer – oder was – tatsächlich handelt.

Die Zahlen machen das Ausmaß des Wandels konkret. In traditionellen Unternehmensumgebungen übersteigen Maschinenidentitäten menschliche Nutzer bereits um etwa 50 zu 1. In Microservice-lastigen Architekturen – der Norm für jedes Unternehmen, das moderne Cloud-Infrastruktur betreibt – steigt dieses Verhältnis laut einer Untersuchung der Cloud Security Alliance auf fast 500 zu 1. Jede dieser Maschinenidentitäten ist ein Credential, ein Service Account oder ein API-Key, der kompromittiert, falsch genutzt oder einfach vergessen werden kann.

Die Überberechtigungs-Epidemie

Das tiefere Problem ist nicht die schiere Anzahl der Maschinenidentitäten – es ist, was sie tun dürfen. Rund 99 % der nicht-menschlichen Identitäten besitzen Berechtigungen, die weit über das hinausgehen, was ihre tatsächlichen Workloads benötigen, so die Cloud Security Alliance. Die meisten dieser Überprovisionierungen passieren aus banalen Gründen: Ein Entwickler gewährt breiten Zugriff, um ein Deployment zu entblocken, niemand überprüft die Gewährung, und das Credential sitzt mit Dauerberechtigungen dort, die es nie gebraucht hätte.

AI Agents erben dasselbe Muster, nur sind die Einsätze höher, weil Agents mit delegierten Berechtigungen innerhalb von Workflows handeln, die als Routine konzipiert wurden. DTEX Systems führte kontrollierte Simulationen durch, die zeigten, wie schnell ein überberechtigter Agent handeln kann: In einem Test eskalierte ein Agent von vertrauenswürdigem Salesforce-Zugriff zum Verfassen einer E-Mail in Outlook in 24 Minuten. In einem anderen wurde lokaler Dateizugriff innerhalb von 10 Minuten zu einem archivierten Datentransfer über einen Coding Assistant. Keine der Aktionen löste einen Alarm aus, weil keine eine explizite Zugriffsregel verletzte – der Agent tat genau das, was seine Credentials erlaubten.

68 % können nicht sagen, wer was getan hat

Hier mündet die Identitätskrise in eine Auditkrise. Wenn Sicherheitsteams einen Vorfall untersuchen, lautet die erste Frage immer „Wer hat das getan?". Mit AI Agents, die in den täglichen Betrieb eingewoben sind, kann ein wachsender Anteil der Organisationen diese Frage nicht mehr sauber aus ihren Logs beantworten. Die Unterscheidung zwischen einer legitimen menschlichen Aktion und einem autonomen Agenten, der unter denselben delegierten Anmeldedaten handelt, erfordert eine Verhaltens-Telemetrie, die die meisten Unternehmen nie aufgebaut haben: Tastenanschlagmuster, Mausbewegungen, Navigationssequenzen und API-Aufruf-Zeitpunkte, statt eines statischen Benutzernamens in einem Zugriffslog.

Anthropics eigenes Zero-Trust-Framework für Enterprise AI Agents – als interne Richtlinie veröffentlicht und branchenweit in diesem Jahr aufgegriffen – formuliert die zentrale Sicherheitsfrage neu. Es geht nicht mehr darum, „Darf dieses Tool ausgeführt werden?" Diese Frage war immer mit einer statischen Policy zu beantworten. Die schwierigere Frage ist, ob eine Organisation die vollständige Kette von menschlicher Absicht über Agentenhandlung bis hin zu Datenbewegung und Ergebnis rekonstruieren kann. Die meisten Unternehmen können das derzeit nicht.

Was das tatsächlich behebt

Der Fix sind nicht mehr Access Control Lists. Es ist ein Wandel hin zu vier spezifischen Praktiken, die jede Agentenidentität als ephemer statt dauerhaft behandeln:

• Ephemere, aufgabenbezogene Credentials. Frameworks wie SPIFFE (Secure Production Identity Framework for Everyone) geben Identitäten aus, die nach einer einzelnen Transaktion verfallen, statt unbegrenzt zu bestehen. Das verkleinert den Schadensradius von „alles, was dieser Agent theoretisch tun könnte" auf „diese eine spezifische Aktion, für diese eine spezifische Aufgabe".
• Automatisiertes Non-Human Identity Inventory. Die meisten Unternehmen haben keine vollständige Liste aller API-Keys, Service Accounts und Agentenidentitäten, die in ihren Cloud- und On-Premises-Systemen laufen. Discovery muss kontinuierlich erfolgen, nicht als vierteljährliches Audit.
• Behavioral Continuous Verification. Identity Threat Detection and Response (ITDR)-Plattformen, die auf anomale Muster während einer Sitzung achten – nicht nur beim Login – fangen den Agenten, der beginnt, etwas zu tun, was seine Aufgabe nie erforderte.
• Just-in-Time Access Provisioning. Dauerberechtigungen sind die Hauptursache des 99%-Überprovisionierungsproblems. Kontextbezogene, zeitlich begrenzte Autorisierung, die mit dem Ende der Aufgabe verfällt, schließt diese Lücke durch Design, statt durch Policy Enforcement im Nachhinein.

Nichts davon ist exotisch. Zero-Trust-Architektur ging bereits davon aus, dass keinem Actor implizit vertraut wird – das Problem der AI Agents ist eigentlich ein Test dafür, ob Organisationen dieses Prinzip tatsächlich umgesetzt oder nur die Vokabeln übernommen haben. Sicherheitsteams, die jedes Agenten-Credential als dauerhaft vertrauenswürdige Identität behandeln, betreiben dieselbe Architektur, die Unternehmen schon vor der Existenz von Zero Trust in die Bredouille gebracht hat. Die Agents sind nur schneller als die Menschen, die diesen Fehler früher gemacht haben.

Was Sie dieses Quartal tun sollten

Wenn Ihre Organisation AI Agents in Produktionsworkflows einsetzt – und die meisten tun das, ob die Sicherheit Einblick hat oder nicht – beginnen Sie mit dem Inventory-Problem. Sie können nicht sichern, was Sie nicht sehen. Führen Sie einen Non-Human Identity Discovery Pass über Cloud IAM, Service Accounts und jedes Coding-Assistant- oder Automatisierungstool mit API-Zugriff durch. Verschieben Sie dann die höchstberechtigten Agenten-Credentials zuerst auf ephemere, aufgabenbezogene Tokens. Diese einzelne Änderung schließt den weitesten Schadensradius mit der geringsten architektonischen Störung und verschafft Zeit, um Behavioral Monitoring aufzubauen, bevor der nächste Vorfall die Frage aufwirft.