Verwaiste Schlüssel von KI-Agenten bleiben lange nach Projektende aktiv

Da KI-Agenten in Entwicklungsworkflows immer üblicher werden, hinterlassen sie oft aktive Identity-and-Access-Management-Schlüssel (IAM), lange nachdem ihre Aufgaben abgeschlossen sind. Dies führt zu einer erheblichen Sicherheitslücke, da gültige Zugangsdaten ohne Besitzer oder Zweck existieren. Aktuelle Analysen zeigen, wie diese verwaisten Schlüssel über Monate hinweg bestehen bleiben können und Angreifern einen potenziellen Einstiegspunkt in Cloud-Umgebungen bieten.

Was passiert ist

Ein hypothetisches, aber repräsentatives Szenario verdeutlicht das Kernproblem: Ein IAM-Benutzer namens _research-agent-2 behält einen Zugriffsschlüssel, der vor vierzehn Monaten erstellt wurde. Der Schlüssel wurde zuletzt vor elf Monaten verwendet, ist aber weiterhin aktiv. Das unterstützte Projekt wurde geschlossen, und der Mitarbeiter, der die Erstellung genehmigte, arbeitet nicht mehr im Unternehmen. Im Gegensatz zu menschlichen Mitarbeitern, bei denen beim Ausscheiden Offboarding-Prozesse ausgelöst werden, beenden fertige KI-Agenten einfach ihren Betrieb und lassen ihre Zugangsdaten in einem Schwebezustand zurück.

Dieses Lifecycle-Problem ist nicht auf Nachlässigkeit zurückzuführen, sondern auf eine strukturelle Lücke im Management nicht-menschlicher Identitäten. AWS-IAM-Benutzerzugriffsschlüssel laufen nicht automatisch ab. Folglich bleibt ein vergessener Schlüssel unbegrenzt gültig, bis jemand ihn manuell deaktiviert oder löscht. Das Open Web Application Security Project (OWASP) listete unsachgemäßes Offboarding als das größte Risiko in seiner Top 10 für nicht-menschliche Identitäten 2025 und betonte die Notwendigkeit, ungenutzte Assets stillzulegen und den verbleibenden verantwortliche Eigentümer zuzuweisen.

Die Dringlichkeit dieses Problems wird durch die Geschwindigkeit moderner Angriffe unterstrichen. Im September 2026 dokumentierte GreyNoise eine KI-gesteuerte Kampagne gegen PaperCut-Server. Die Angreifer bewegten sich von einem leeren Workspace zur Remote Code Execution in weniger als vier Stunden. Nach dem Start kompromittierte die Kampagne mindestens elf Organisationen in nur sechsundzwanzig Sekunden. Obwohl dieser spezifische Angriff keine verlassenen AWS-IAM-Schlüssel nutzte, zeigt er, wie schnell exponierter Zugang für Gegner nützlich wird. Langsame Inventarisierungs- und Widerrufsprozesse sind in diesem Kontext gefährlich unzureichend.

Wichtige Details

• AWS-IAM-Benutzerzugriffsschlüssel haben kein automatisches Ablaufdatum und bleiben gültig, bis sie manuell widerrufen werden.
• OWASPs Top 10 für nicht-menschliche Identitäten 2025 stuft unsachgemäßes Offboarding als primäres Risiko ein.
• Ein GreyNoise-Bericht vom September 2026 zeigte einen KI-getriebenen Angriff, der elf Organisationen in 26 Sekunden kompromittierte.
• CloudQuery kann AWS-IAM-Credential-Berichte synchronisieren, um Schlüssel zu identifizieren, die länger als 90 Tage ungenutzt waren.
• Time-to-Live-Einstellungen (TTL) für Umgebungen können helfen, wegwerfbare Zugangsdaten zu verwalten, garantieren jedoch keinen sofortigen Widerruf, wenn Löschvorgänge fehlschlagen.
• Root-Konto-Zugriffsschlüssel erfordern separate, dringende Audits und sollten grundsätzlich nicht existieren.

Hintergrund

Nicht-menschliche Identitäten beziehen sich auf Servicekonten, Bots und KI-Agenten, die mit Cloud-Infrastrukturen interagieren. Im Gegensatz zu menschlichen Benutzern haben diese Entitäten keine natürlichen Wechselereignisse wie Kündigung oder Ruhestand. Ihre Zugangsdaten, wie Zugriffsschlüssel oder Tokens, werden oft für spezifische Aufgaben bereitgestellt, verfügen aber über kein integriertes Lifecycle-Management. Wenn die Aufgabe endet, kann der Zugangsdatensatz aktiv bleiben, wenn er nicht explizit decommissioned wird.

Die Inventarisierung dieser Identitäten ist schwierig, weil Cloud-Anbieter nicht immer nachverfolgen, welcher spezifische Agent ein Konto genutzt hat. Eine Korrelation der Aktivität mit Audit-Logs und benannten Eigentümern ist notwendig, um festzustellen, ob ein Schlüssel noch benötigt wird. Darüber hinaus können Deployment-Plattformen zwar Policies während der Infrastrukturerstellung erzwingen, aber sie können nicht immer Zugangsdaten kontrollieren, die über Konsolen oder externe Skripte erstellt wurden. Diese Unterscheidung zwischen Deployment-Identität und bereitgestellten Zugangsdaten erschwert Governance-Bemühungen.

Warum es wichtig ist

Für Teams, die ihre eigene Software betreiben, stellen verwaiste Schlüssel eine stille Sicherheitsverschuldung dar. Eine vergessene virtuelle Maschine verursacht finanzielle Kosten, aber ein vergessener Zugangsdatensatz gewährt potenziellen Zugriff auf sensible Daten und Systeme. Angreifer müssen nicht wissen, dass ein Schlüssel verwaist ist, um ihn auszunutzen; sie benötigen lediglich, dass er gültig ist. Da KI-Agenten proliferieren, wird das Volumen dieser nicht-menschlichen Identitäten wachsen, was die Angriffsfläche erhöht, wenn keine angemessene Governance implementiert wird.

Manuelle jährliche Audits sind angesichts der Geschwindigkeit automatisierter Angriffe unzureichend. Teams benötigen kontinuierliche Sichtbarkeit in die Nutzung von Zugangsdaten. Ohne automatisierte Abfragen und Policies könnten Security-Leads unwissentlich über aktive Schlüssel bleiben, die mit defekten Projekten verbunden sind. Diese Verzögerung zwischen Projektabschluss und Widerruf der Zugangsdaten schafft Fenster der Verwundbarkeit, die ausgefeilte Angreifer schnell ausnutzen können.

Darüber hinaus reicht die alleinige Abhängigkeit von Infrastructure-as-Code-Tools nicht aus. Während Tools wie Terraform die Schlüsselerstellung verwalten können, widerrufen sie Schlüssel nicht automatisch, wenn der Zerstörungsprozess fehlschlägt oder wenn Schlüssel außerhalb der verwalteten Umgebung erstellt werden. Teams müssen den Widerruf aktiv überprüfen, anstatt Countdown-Timern oder Deployment-Skripten zu vertrauen.

Was Sie tun können

• Führen Sie SQL-Abfragen gegen synchronisierte IAM-Credential-Berichte aus, um aktive Schlüssel zu finden, die länger als 90 Tage ungenutzt sind.
• Implementieren Sie Genehmigungs-Policies in Deployment-Plattformen, um die Erstellung langlebiger Zugangsdaten in Terraform- oder OpenTofu-Plänen zu blockieren.
• Bevorzugen Sie OIDC-basierte Federation für Deployments, um temporäre Zugangsdaten zu verwenden, die mit der Sitzung ablaufen.
• Legen Sie TTLs für Umgebungen für wegwerfbare Zugangsdaten fest, überprüfen Sie aber den tatsächlichen Widerruf durch State-Checks.
• Deaktivieren Sie verdächtige Schlüssel zunächst, um Authentifizierungsfehler zu überwachen, bevor Sie sie dauerhaft löschen.
• Weisen Sie allen nicht-menschlichen Identitäten explizite Eigentümer zu und dokumentieren Sie die Eigentümerschaft in Ihrem Credential-Inventar.

Der abschließende Abschnitt folgt unten.