KI-Agenten erben vollständige Benutzerrechte und brechen Prüfpfade sowie Sicherheitsgrenzen

Eine aktuelle Sicherheitsuntersuchung zur Authentifizierung von KI-Agenten in Unternehmensumgebungen hat kritische Lücken im Identitätsmanagement und beim Audit-Logging offengelegt. Wenn Entwickler Coding-Agenten erlauben, ihre eigenen zwischengespeicherten Zugangsdaten zu verwenden, erben diese Agenten den vollen Umfang der menschlichen Berechtigungen und umgehen oft die beabsichtigten Sicherheitsgrenzen. Die am 8. Oktober 2026 veröffentlichte Studie demonstriert, dass diese Praxis die Zuordnung von Aktionen kollabieren lässt, wodurch es unmöglich wird, in Datenbankprotokollen zwischen menschlicher Absicht und automatisierten Handlungen zu unterscheiden.

Was passiert ist

Der Autor, ein Full-Stack-Ingenieur, maß die tatsächlichen Berechtigungen eines KI-Agenten, als dieser sich mit seinen persönlichen Azure-Zugangsdaten authentisierte. Dieses Setup ist in Entwicklungsworkflows üblich, bei denen Agenten über Befehlszeilentools eine Verbindung zu Datenbanken herstellen, die auf einer bestehenden Sitzung des Entwicklers aufbauen. Die Untersuchung ergab, dass der Agent nicht über eine eingeschränkte oder skalierte Identität verfügte; stattdessen operierte er mit exakt denselben Privilegien wie der menschliche Benutzer, einschließlich Gruppenmitgliedschaften, die für Standard-Berechtigungsprüfungen unsichtbar waren.

Die Ergebnisse variierten drastisch zwischen verschiedenen Produktionsdatenbanken, die innerhalb einer Stunde accessed wurden. In einer Umgebung hatte der Agent nur zwei Berechtigungen, korrekt eingeschränkt auf schreibgeschützten Zugriff. In einer anderen gewährte derselbe Token 107 Berechtigungen, einschließlich Schreib-, Schema-Definition- und Datenbankadministrationsrechten. Am besorgniserregendsten war die Feststellung, dass die Umgebung, in der der Agent Daten aus einer sicheren Datenbank löschen konnte, die einzige war, in der das Auditing auf Serverebene vollständig deaktiviert war. Die Datenbank meldete das Auditing als aktiv aufgrund veralteter Konfigurationsobjekte, aber es wurden tatsächlich keine Protokolle geschrieben.

Wichtige Details

• Zugangsdatenvererbung: Agenten, die zwischengespeicherte CLI-Tokens verwenden, authentifizieren sich als der menschliche Benutzer, wobei der Token-Umfang explizit auf user_impersonation gesetzt ist.
• Unsichtbare Berechtigungen: Die Autorisierung stützt sich stark auf Gruppenmitgliedschaften, die bei standardmäßigen Abfragen zur Rollenverweisung oft übersehen werden, was zu einem falschen Gefühl eingeschränkten Zugriffs führt.
• Audit-Lücken: Die Umgebung mit dem höchsten Risiko (Löschzugriff) hatte keinen aktiven Prüfpfad, während sicherere Umgebungen vollständig protokolliert wurden.
• Kollaps der Zuordnung: Datenbankprotokolle erfassen den Login-Namen und den Arbeitsplatz des Menschen, wodurch es unmöglich ist nachzuweisen, ob eine Abfrage von einer Person eingegeben oder von einem Agenten ausgeführt wurde.
• Token-Lebensdauer: Obwohl Zugriffstokens eine kurze Lebensdauer haben, ermöglichen automatische Aktualisierungsmechanismen unbeaufsichtigten Agenten, den Zugriff unbegrenzt aufrechtzuerhalten, bis das Benutzerkonto deaktiviert wird.
• Einschränkungen von Dienstkonto-Identitäten: Selbst korrekt konfigurierte Maschinenidentitäten konnten keine eindeutige Zuordnung auf der Datenschicht bereitstellen, da sie oft auf Standard-SQL-Anmeldungen zurückfielen, die nicht zwischen Aufrufern unterscheiden.

Hintergrund

Um diese Risiken zu verstehen, ist es hilfreich, zwischen Authentifizierung und Autorisierung zu unterscheiden. Authentifizierung überprüft, wer sich verbindet, während Autorisierung festlegt, was dieser tun darf. In modernen Cloud-Umgebungen wird dies oft über Tokens und Gruppenmitgliedschaften verwaltet. Wenn ein KI-Agent die Zugangsdaten eines Entwicklers verwendet, betreibt er "Impersonation", was bedeutet, dass er vom Benutzer nicht unterscheidbar ist.

Audit-Protokolle erfassen typischerweise Metadaten wie Login-Namen, Host-Maschinen und Client-Schnittstellen. Diese Protokolle enthalten jedoch derzeit kein Feld für "Agentenabsicht". Folglich verlassen sich Sicherheitsteams auf die Annahme, dass hinter jeder Aktion ein Mensch steht. Wenn ein autonomer Agent Tausende von Operationen durchführt, bricht diese Annahme zusammen. Darüber hinaus können "Just-in-Time"-Zugriffsgruppen in einem zwischengespeicherten Token aktiv bleiben, auch nachdem sie im Verzeichnis deaktiviert wurden, was ein Sicherheitsfenster schafft, das Standardprüfungen nicht sehen können.

Warum es wichtig ist

Für Teams, die ihre eigene Software betreiben, trifft dieses Problem den Kern der operationellen Sicherheit und Compliance. Selbst gehostete Umgebungen verlassen sich oft auf strenge Zugriffssteuerungen zum Schutz sensibler Daten. Wenn ein KI-Agent breite Berechtigungen erbt, kann ein falsch konfigurierter Prompt oder ein fehlerhaftes Skript zu Datenlöschung oder -offenlegung führen, die einem hochrangigen Ingenieur zugeordnet wird. Dies erschwert nicht nur die Incident Response, sondern schafft auch Haftungsprobleme, da der Ingenieur nicht leicht beweisen kann, dass er den schädlichen Befehl nicht persönlich ausgeführt hat.

Darüber hinaus stellt die Inkonsistenz der Audit-Abdeckung eine erhebliche Blindstelle dar. Teams glauben möglicherweise, sie seien durch umfassende Protokollierung geschützt, nur um festzustellen, dass Hochrisikoumgebungen stillschweigend keine Aktivitäten aufzeichnen. Dies ist besonders gefährlich in Nicht-Produktionsumgebungen, die oft unüberwacht bleiben, um Kosten zu sparen. Da Agenten autonomer werden, wird das Volumen automatisierter Aktionen zunehmen, was genaue, zuordenbare Protokolle für Debugging und Sicherheitsüberprüfungen unerlässlich macht.

Was Sie tun können

• Vermeiden Sie die Weitergabe von Zugangsdaten: Erlauben Sie KI-Agenten nicht, persönliche zwischengespeicherte Zugangsdaten zu verwenden; provisionieren Sie stattdessen eindeutige Dienstkonto-Identitäten oder Managed Identities für jeden Agenten.
• Implementieren Sie Delegations-Tokens: Verwenden Sie Authentifizierungsstandards, die Delegation unterstützen, wobei der Token sowohl das Subjekt (Mensch) als auch den Akteur (Agent) trägt, damit Protokolle beide Identitäten erfassen können.
• Erzwingen Sie Least Privilege: Stellen Sie sicher, dass die Berechtigungen des Agenten die Schnittmenge der erforderlichen Aufgaben sind und niemals die spezifischen Aktionen überschreiten, die für den Workflow benötigt werden.
• Prüfen Sie Prüfpfade aktiv: Testen Sie Audit-Konfigurationen regelmäßig, indem Sie Beispielaktionen durchführen und bestätigen, dass sie im Monitoring-Sink erscheinen, anstatt sich auf Statusflags zu verlassen.
• Entkoppeln Sie die Widerrufsfunktion: Entwerfen Sie Systeme, in denen der Agentenzugriff unabhängig widerrufen werden kann, ohne das primäre Konto des menschlichen Benutzers zu deaktivieren.
• Skalieren Sie nach Aktion: Bewegen Sie sich weg von breiten rollenbasierten Zugriffen für Agenten und implementieren Sie Berechtigungen, die an spezifische Operationen oder API-Endpunkte gebunden sind.