Es wurde nichts gehackt. Alles wurde mitgenommen.

Geben Sie einem KI-Agenten einen einzigen geleakten AWS-Schlüssel – die Art mit wenigen Rechten, die eine CI-Pipeline jede Woche verschüttet – und weisen Sie ihn an, mitzunehmen, was er erreichen kann. Gehen Sie dann weg. Meistens liest er rund eine Minute später, ohne dass jemand am Rechner sitzt, Ihre Kundendaten.

Um dorthin zu gelangen, wurde nichts gehackt. Kein Exploit, keine CVE, kein ungepatchter Server. Jede Zugangsdaten, die er anfasste, war gültig; jeder API-Aufruf war einer, den AWS zu beantworten ausgelegt war. Dreißig Jahre lang war ein geleakter Schlüssel nur der Anfang eines Angriffs – der langsame Teil, für den ein Mensch wach sein musste, die Lücke, in der Sicherheitsteams leben und schnelles Rotieren das Rennen gewinnt. Diese Lücke ist gerade auf etwa eine Minute geschrumpft.

Im Mai 2026 führte ein Forscher namens Adan Álvarez einen einfachen Test durch. Er nahm einen einzelnen AWS-Schlüssel mit wenigen Rechten – die Art, die eine CI/CD-Pipeline ständig leakt – und übergab ihn einem KI-Coding-Agenten mit einer Anweisung: Arbeite als Penetrationstester, finde, was du erreichen kannst. Danach kein Mensch mehr am Rechner. Der Agent erledigte den Rest. In mehr als der Hälfte der Fälle lief er die gesamte Kette bis zu den Kundendaten durch – in etwa einer Minute, unbeaufsichtigt.

Was tatsächlich passiert ist

Der Aufbau war bewusst alltäglich. Der geleakte Schlüssel gehörte einem Build-Nutzer mit wenigen Rechten. Für sich genommen konnte er keine Kundendaten erreichen. Aber er konnte eine Terraform-Statusdatei lesen. Diese Statusdatei enthielt einen zweiten Schlüsselsatz. Diese Schlüssel konnten eine Rolle annehmen. Diese Rolle konnte den Bucket mit den Kundendaten lesen.

So ist fast jedes echte Cloud-Konto aufgebaut – nicht eine Festungsmauer, sondern eine Kette kleiner, vernünftiger Vertrauensbeziehungen, deren einzelne Glieder für sich genommen jeweils sinnvoll sind. Ein menschlicher Angreifer entwirrt diese Kette langsam, von Hand. Der Agent entwirrte sie in etwa sechzig Sekunden.

Die erfolgreichen Durchläufe folgten jedes Mal denselben sechs Schritten: bestätigen, wem der Schlüssel gehört, auflisten, was er tun darf, den zweiten Zugangsdatensatz aus dem Staging-Bucket zurückholen, die privilegierte Rolle annehmen, die Daten finden, sie mitnehmen. Von zwölf Durchläufen mit zwei Modellen erreichten sieben das Exfiltrieren. Die meisten waren in etwa einer Minute fertig [1].

Und das ist kein reines Laborergebnis. Im November 2025 beobachtete das Threat-Research-Team von Sysdig dieselbe Form in der Wildnis: gültige AWS-Schlüssel, exponiert in einem öffentlichen Bucket, eine Lambda-Funktion, die heimlich umgeschrieben wurde, um administrative Zugangsdaten zu erzeugen, seitwärts über neunzehn getrennte Identitäten – alles in acht Minuten [2][3]. Der injizierte Code trug die Fingerabdrücke eines Modells: saubere Ausnahmebehandlung, iterative Ziellogik, Kommentare in mehr als einer Sprache.

Das ist keine Schwäche von AWS

Hier ist der Teil, der Sie nachts wach halten sollte: Es wurde nichts gehackt.

Kein Exploit. Keine CVE. Kein Pufferüberlauf, kein ungepatchter Server. Jede Zugangsdaten war gültig. Jeder API-Aufruf war einer, den AWS zu beantworten ausgelegt war. Wie Sysdig es formulierte: Die Zugangsdaten waren legitim, und die APIs wurden genau wie vorgesehen benutzt [3]. AWS hat seine Aufgabe perfekt erfüllt.

Die Annahme, die brach, war nicht die Sicherheit von AWS. Es war eine ältere, stillere darunter: dass ein geleakter Schlüssel nur so gefährlich ist, wie viel Aufmerksamkeit ein Angreifer ihm widmen kann. Dreißig Jahre lang traf das zu. Das Ausnutzen einer Zugangsdaten brauchte einen Menschen – Zeit, Können, Geduld. Diese Kosten waren ein realer Teil Ihrer Verteidigung, auch wenn sie niemand ins Architekturdiagramm gezeichnet hat.

Agenten treiben diese Kosten auf ungefähr null. Die Geduld ist unendlich. Das Können wird minutegenau gemietet. Der Angreifer kann schlafen.

Es betrifft nicht nur AWS

Nichts davon ist Amazon-spezifisch. Dieselbe Kette läuft überall dort, wo eine Zugangsdaten genutzt werden kann, um die nächste Zugangsdaten zu finden: ein Cloud-Schlüssel, der seine eigenen Berechtigungen auflisten kann, ein Token in einer .env-Datei, die ein anderer Prozess lesen kann, ein Geheimnis in einer Statusdatei, ein Vault-Token, das neben dem Code auf der Festplatte liegt. Jedes Werkzeug – ein Coding-Agent, ein MCP-Server, den Sie letzte Woche installiert haben – kann das sein, das die Kette abläuft, mit oder ohne Ihren Segen.

Der gemeinsame Nenner ist, dass das Geheimnis seinen eigenen Wirkungsradius mitbringt. Es kann dort gelesen werden, wo die Arbeit stattfindet, es kann auflisten, worauf es trifft, und es funktioniert von überall. Diese drei Eigenschaften waren überlebensfähig, solange Angriffe langsam und manuell waren. Sie sind es in Agentengeschwindigkeit nicht.

Bewusst dafür gebaut

Also haben wir bewusst das Gegenteil gebaut.

Clavitor-Zugangsdaten sind nur über den Namen erreichbar, den der Agent erhalten hat – sie können den Speicher nicht auflisten, können also nicht die Karte zeichnen. Der Geheimniswert gelangt nie dorthin, wo der Code läuft; der Agent erhält das Ergebnis der Nutzung der Zugangsdaten, nicht die Zugangsdaten selbst. Jedes einzelne ist an die Maschine und den Geltungsbereich gebunden, für die es ausgestellt wurde, eine auf einen Laptop mitgenommene Kopie ist damit tote Masse. Und jeder Request wird in ein unveränderliches, hash-verkettetes, außerhalb des Endpunkts geführtes Protokoll geschrieben – die Evidenz, die PCI DSS Req 10 und NIST 800-171 (3.3.8) verlangen – sodass auch einer perfekt „gültigen" Aktion ein Name zugeordnet ist.

Der ehrliche Vorbehalt: Das macht geleakte Zugangsdaten nicht harmlos. Begrenzen Sie einen Schlüssel auf einen Bucket, und wenn dieser Schlüssel leakt, erhält ein Angreifer genau diesen einen Bucket. Was dabei getötet wird, ist die Kette – der Teil, in dem ein gewöhnlicher Schlüssel zur Karte für alles andere wird. Begrenzt gegenüber umfassend ist nicht der Unterschied zwischen sicher und kompromittiert. Es ist der Unterschied zwischen einem Vorfall und einer Katastrophe.

Wir haben die Handvoll Regeln aufgeschrieben, die ein Werkzeug für Zugangsdaten einhalten sollte, wenn es das überleben will. Sie können Ihres darunter durchgehen: clavitor.ai/rules.

Die Lehre ist nicht „schneller rotieren"

Sie können einen Angriff von sechzig Sekunden nicht durch Rotieren aushebeln. Wenn die Canary auslöst, ist die Kette bereits gelaufen.

Die Lehre ist kein engerer Aufräumablauf. Sie ist, dass die Ökonomie gekippt ist. Wir haben Systeme für Zugangsdaten für eine Welt gebaut, in der die Zeit des Angreifers knapp und teuer war – in der ein geleakter Schlüssel ein Rennen war, das man gewinnen konnte. Diese Welt ist weg. Eine Zugangsdaten, die die nächste finden kann, ist keine Bequemlichkeit mehr. Sie ist der ganze Angriff, vorformuliert, wartend darauf, dass ein Schlüssel fällt.

Bauen Sie für die Welt, in der der Angreifer nie schläft. Sie ist schon da.

Clavitor (@clavitorai) ist der Tresor für Zugangsdaten – gebaut für KI-Agenten und gegen sie. clavitor.ai

Quellen

[1] Adan Alvarez — "From Leaked AWS Key to Data Exfiltration in 60 Seconds: Are We Ready?" (May 2026) — https://medium.com/@adan.alvarez/from-leaked-aws-key-to-data-exfiltration-in-60-seconds-are-we-ready-28213bc73678

[2] CSO Online — "From credentials to cloud admin in 8 minutes: AI supercharges AWS attack chain" — https://www.csoonline.com/article/4126336/from-credentials-to-cloud-admin-in-8-minutes-ai-supercharges-aws-attack-chain.html

[3] Vectra AI — "AWS Compromised by AI Agents in Minutes" (Alex Groyz) — https://www.vectra.ai/blog/aws-compromised-by-ai-agents-in-minutes

[4] Help Net Security — "The shocking speed of AWS key exploitation" — https://www.helpnetsecurity.com/2024/12/02/revoke-exposed-aws-keys/