Geleakte Zugangsdaten zu finden, ist ein gelöstes Problem. Truffle Security macht das seit vier Jahren und hat 431.875 AWS-Funde vorzuweisen. Ungelöst ist die andere Hälfte, der Schritt danach, bei dem sich jemand einloggen und den Schlüssel löschen muss. Das passiert in einem von sieben Fällen.

Truffle Security hat diese Woche eine Bestandsaufnahme veröffentlicht, und BleepingComputer hat sie am Donnerstag aufgegriffen. Seit August 2022 sammelt das Unternehmen AWS-Zugriffsschlüssel dort ein, wo sie öffentlich auftauchen: Git-Historie, Hugging-Face-Datasets, Docker-Images, Paketregistries, CI-Logs. Danach prüft es, ob sie noch funktionieren.

Der Bericht zählt 431.875 verifizierte AWS-Funde, dedupliziert auf 64.024 eindeutige Zugriffsschlüssel über 50.654 verschiedene Konten. Davon trugen 10.616 Paare genug Material für einen erneuten Test. Achtundachtzig Prozent von ihnen authentifizieren sich weiterhin. Das sind 9.308 Schlüssel, heute lebend, die irgendwann in den letzten vier Jahren jeder von einer öffentlichen Oberfläche hätte aufsammeln können.

Die Verifikation blieb eng und nutzte nur lesende Metadaten-Aufrufe: sts:GetCallerIdentity, iam:ListAccessKeys, Aufzählung von Policy-Namen, ein Budget-Read, ein Cost-Explorer-Aufruf pro Konto. Sie lasen keine Daten und änderten nichts, und sie informierten 10.260 der 10.616 Eigentümer vor der Veröffentlichung.

Dann sieh dir an, wie alt die Schlüssel sind.

Fünf Jahre, Tendenz steigend

Der mediane noch funktionierende Schlüssel ist 1.831 Tage alt. Der älteste 17,4 Jahre. Nur 25 Schlüssel im Datensatz, neun Zehntel eines Prozents, stammen aus den letzten dreißig Tagen.

Diese Verteilung beschreibt Sediment, nicht einen Strom frischer Unfälle, die aufgefangen und aufgeräumt werden. Ein Schlüssel leckt und bleibt geleakt, denn ein statischer AWS-Zugriffsschlüssel hat kein Ablaufdatum: keine Uhr, keine Erneuerung, kein Zertifikat, das nach achtzehn Monaten schal wird. Er funktioniert, bis jemand die Konsole öffnet und ihn löscht. Truffle hat gemessen, wie oft dieser Jemand auftaucht. Von den Nutzern, deren Schlüssel die Forscher aufzählen konnten, haben 398 von 2.903 einen neueren Schlüssel neben dem geleakten liegen, also 13,7%. Die übrigen 2.505 haben ihn nie rotiert.

Auf den Erkennungsschritt kann man das auch nicht schieben, denn Amazon hatte das Entdecken längst erledigt. Wenn AWS einen der eigenen Schlüssel öffentlich sichtet, hängt es dem Nutzer eine Policy namens AWSCompromisedKeyQuarantine an, schränkt ein, was der Schlüssel darf, und mailt dem Konto. Niemand muss darum bitten. Truffle fand 929 IAM-Nutzer, 12% der 7.590 aktiven, die diese Policy gerade jetzt tragen. Einhundertzwölf davon tragen die ursprüngliche Fassung, AWS hat sie also vor mindestens drei Jahren markiert, und sie antworten immer noch.

Die Erkennung hat funktioniert, die Mail ist raus, und drei Jahre später ist der Schlüssel noch gut.

Ein statischer AWS-Zugriffsschlüssel hat kein Ablaufdatum, also hat ein Leck kein Enddatum. Das Einzige, was es schließt, ist ein Mensch, der den Schlüssel löscht, und über 2.903 aufzählbare Nutzer hinweg geschah das in 13,7% der Fälle, auch bei den 929 Nutzern, die AWS von sich aus markiert und unter Quarantäne gestellt hatte.

Die Leckfläche ist dorthin gezogen, wo es keinen Löschknopf gibt

Die größte einzelne Quelle der gesamten Erhebung ist Hugging Face: 8.482 eindeutige lebende Schlüssel über 3.394 Datasets und eine Root-Schlüssel-Quote von 17,9%, deutlich über dem Rest der Population.

Das andere Ende dieser Leitung hatte Truffle schon vermessen. Im Juni hat das Team jedes öffentliche Dataset auf Hugging Face geklont: 186,9 Millionen eindeutige Dateien, 7,6 Petabyte, rund 815.000 Dataset-Repositories. Sie plätteten Parquet, Arrow, JSONL und Archive zu durchsuchbarem Text und verifizierten alles, was sie fanden. Das Ergebnis: 221.303 lebende, eindeutige Zugangsdaten in 6.003 Datasets, darunter 11.496 Schlüssel von KI-Anbietern, 8.557 Google-Cloud-Dienstkontoschlüssel über 3.811 Projekte, 8.594 funktionierende Datenbank-Logins, 3.343 AWS-Schlüssel, die eine STS-Identitätsprüfung bestehen, und 349 persönliche GitHub-Zugriffstoken, von denen 223 Code pushen und 130 CI-Workflows umschreiben können.

Zwei ihrer Beispiele zeigen, wie weit ein einziger Fehler reist. Jemand hat den AWS-Schlüssel eines brasilianischen Fintechs in einen Chatbot kopiert, und er taucht inzwischen etwa achtzehnfach gespiegelt in verschiedenen Korpora auf. Ein auf dieselbe Weise erfasster Infura-Schlüssel landete in 1.131 Datasets und 10.162 einzelnen Dateipositionen. Vierundvierzig Prozent der eindeutigen lebenden Geheimnisse, die Truffle fand, kommen in mehr als einem Dataset vor.

Dann trainieren Leute auf diesen Datasets. Die dokumentierten Trainingsdaten von StarCoder enthalten 25.217 dieser Schlüssel; Swallow 22.484; OLMo 3 21.278. Die großen proprietären Modelle halten ihre Korpora geheim, also weiß es von außen niemand.

Truffle zieht den nüchternen Schluss: Rotation bleibt der einzige Fix, weil niemand zurückgehen und Trainingsdaten säubern kann. Behandle jeden Schlüssel, der je in ein öffentliches Repo, auf eine Webseite oder in einen Chatbot gelangt ist, als verbrannt.

Zugangsdaten, die ein öffentliches Dataset erreichen, lassen sich nicht zurückziehen. Truffle fand 44% der lebenden Geheimnisse über Korpora hinweg dupliziert, einen Infura-Schlüssel in 1.131 Datasets und Zehntausende funktionierende Schlüssel in den dokumentierten Trainingsdaten offener Modelle. Die Originaldatei zu löschen ändert flussabwärts nichts.

Jede Quelle auf dieser Liste ist etwas, das ein Agent schreibt

Sieh noch einmal, wo Truffle einkaufen war: Git-Historie, Docker-Images, Paketregistries, CI-Logs, Dataset-Uploads. Das sind Build-Ausgaben, und es sind die Artefakte, die ein Coding-Agent heute unbeaufsichtigt über Nacht produziert, in einem Tempo, das kein Team durchsehen könnte.

Ein Agent, der einen Backlog abarbeitet, während du schläfst, schreibt Commits, schreibt Lockfiles um, baut Images, pusht Branches und füllt Logs. Jedes davon ist eine Publikationsfläche, und der Agent hat die ganze Zeit deine ~/.aws/credentials in Reichweite, denn genau so ist das SDK gebaut, um sie zu finden.

Coding-Agenten schreiben diese Artefakte schneller als jedes Werkzeug zuvor, und an den 13,7% hat sich nichts geändert.

Die Hälfte, die signiert, bleibt auf deinem Mac

Bromure Agentic Coding führt den Agenten in einer wegwerfbaren Ubuntu-VM auf Apples Virtualization-Framework aus, mit einem hostseitigen Proxy als einzigem Weg nach draußen. AWS braucht in diesem Entwurf eine eigene Behandlung. SigV4 legt das Geheimnis nie aufs Kabel, da das SDK es im Prozess zu einem HMAC verrechnet, ein Proxy hat also unterwegs nichts zu tauschen. Bromure verlagert stattdessen das Signieren.

In der VM verweist ~/.aws/config auf einen credential_process-Helfer. Wenn das SDK nach Zugangsdaten fragt, liefert der Helfer die echte Zugriffsschlüssel-ID gepaart mit einem gefälschten Geheimnis aus vierzig Zeichen, pro Sitzung frisch geprägt. Die Zugriffsschlüssel-ID ist eine Kennung, kein Geheimnis, und sie ist die Hälfte, die angibt, welcher IAM-Nutzer aufruft. Der geheime Zugriffsschlüssel ist die Hälfte, die signiert, und er betritt den Adressraum der VM überhaupt nie. Bromure exportiert nicht einmal AWS_ACCESS_KEY_ID oder AWS_SECRET_ACCESS_KEY in die Gastumgebung, mit der Begründung, dass Umgebungsvariablen über /proc, ps -E und die Shell-Historie durchsickern. Die VM bekommt einen Regionsstring und sonst nichts.

Das SDK signiert eine Anfrage, deren Signatur gar nicht stimmen kann. Auf dem Weg nach draußen streift der Host diese Signatur ab und berechnet SigV4 mit dem echten Material neu. aws, boto3 und terraform funktionieren wie gewohnt. Alles, was am Proxy vorbeigeht, bekommt von Amazon InvalidSignatureException zurück, und das ist genau der Fehler, den man will.

Jetzt lass einen Bromure-Workspace durch Truffles Methodik laufen. Ihre Latte für einen gezählten Schlüssel ist ein signiertes sts:GetCallerIdentity, das gültig zurückkommt. Angenommen, eine kompromittierte Abhängigkeit erntet die Credentials-Datei aus diesem Gast, oder der Agent lässt sich zum cat darauf überreden, oder ein Build backt sie in ein öffentliches Bundle. Nach draußen geht eine Kennung und vierzig Zeichen, die nie das Geheimnis waren. Es scheitert an dem Tag, an dem es leckt, es reiht sich also nie in die Sedimentschicht ein, und dahinter liegt kein Fünf-Jahres-Schweif.

Damit entfällt auch der Rotationsschritt, der auf einen Menschen wartet. Das echte Geheimnis lebt an einem Ort, auf deinem Mac, im Bereich Zugangsdaten des Profils. Ändere es dort, und die nächste Sitzung nimmt es auf. Niemand muss herausfinden, welcher von neunzig Nachtläufen welches Artefakt geschrieben hat.

AWS-Zugangsdaten in einem Bromure-Workspace: die Zugriffsschlüssel-ID benennt den Aufrufer und erreicht die VM, der geheime Zugriffsschlüssel signiert und erreicht sie nicht. Der Gast signiert eine Anfrage, die scheitern muss, der Host signiert sie mit dem echten Material neu, und was auch immer aus der VM geerntet wird, scheitert an derselben STS-Prüfung, mit der die Erhebung lebende Schlüssel gezählt hat.

Eine signierte Anfrage, enger als der Schlüssel, der sie signiert

Die andere Schlagzeile der Erhebung ist die Reichweite. Von 817 Schlüsseln, die einem Unternehmen zuzuordnen waren, gaben 768 die volle Kontrolle über das Konto: 526 Root-Schlüssel und 242 IAM-Nutzer mit AdministratorAccess. Einhundertdreißig dieser Root-Schlüssel sitzen auf Organisationsverwaltungskonten, also dem Konto, das jedes Mitgliedskonto der Organisation regiert. Über die aufzählbaren Nutzer hinweg hielten 976 von ihnen AdministratorAccess, das sind 84%.

Das sind Schlüssel, die vor Jahren aus Bequemlichkeit geprägt wurden, für eine Aufgabe, die drei Berechtigungen brauchte.

Bromures Guardrails-Einstellung verengt die Zugangsdaten am Einsatzpunkt, damit du nie daran denken musst, sie an der Quelle zu verengen. Es ist eine hostseitige Policy-Engine im Proxy. Für AWS liest sie den Aktionsnamen aus dem Header X-Amz-Target bei Diensten mit JSON-Protokoll wie DynamoDB und Lambda, oder aus dem Parameter Action= bei Diensten mit Query-Protokoll wie EC2, IAM und SQS, und fällt bei S3 auf die HTTP-Methode zurück. Delete*, Terminate*, Remove*, Purge* und Destroy* gelten als destruktiv; Get*, List* und Describe* als Lesevorgänge. Stell das Profil auf Nur lesen, und eine Mutation kommt als hartes 403 zurück, das der Agent als gewöhnlichen API-Fehler liest. Stell es auf Destruktives blockieren, und Anlegen und Ändern gehen durch, Löschen nicht.

Das setzt dein Mac durch, nicht die VM, ein Agent, den man zu etwas überredet hat, kann sich also nicht daran vorbeireden. Die Zugangsdaten, mit denen dein Host signiert, sind am Ende enger als die Zugangsdaten selbst, und das lohnt sich in einer Population, in der 84% der aufzählbaren Nutzer Adminrechte trugen.

Der Nachweis kommt vor der Rechnung

Noch eine Zahl aus dem Bericht. Von den 2.754 Konten, deren Budgets die Forscher lesen konnten, haben 262 überhaupt eine Budgetwarnung konfiguriert, also 9,5%, bei einem medianen Limit von acht Dollar. Dieselbe Gruppe gab im Juli 420.631 Dollar aus, mit fünfzig Konten über 1.000 Dollar und neun über 10.000. Die meisten dieser Eigentümer werden ihrem Eindringling auf einer Rechnung begegnen.

Bromure schreibt den Nachweis mit, während die Arbeit läuft. Jede Anfrage, die der Host signiert, erzeugt eine Zeile credential.aws_sign in Fenster → Sicherheits-Zeitleiste, mit Dienst, Methode, Host, Region und maskierter Zugriffsschlüssel-ID, neben den Paketabrufen, den Firewall-Urteilen und den Credential-Tauschvorgängen. Bromure hält dieses Log auf dem Mac, wo nichts aus der VM es bearbeiten kann. Für die strengere Variante macht AWS → Freigabe zur Nutzung verlangen aus jedem Signieraufruf eine Zustimmungsabfrage mit einer zeitlich begrenzten Erlaubnis, sodass ein Nachmittag echter Arbeit einmal fragt.

Bromure wendet dieselbe Idee einen Schritt früher an, wenn du ein Profil zum ersten Mal hochziehst. Es schickt deine importierte Agentenkonfiguration durch einen Redaktionsdurchlauf: strukturiertes JSON, TOML und YAML gefiltert nach Schlüsselnamen, passend auf token, secret, password, apikey, credential, authorization, private_key und access_key, und Fließtext gefiltert nach Tokenform, passend auf AKIA, ASIA, sk-ant-, ghp_, glpat-, AIza und npm_. Welche echten Geheimnisse auch immer in den Dotfiles auf deinem Mac stecken, sie fahren nicht mit dem Rest der Einrichtung in die VM.

Was die Erhebung beweist

Truffle Security hat das sauber gemacht: nur lesende Aufrufe, keine Daten angefasst, 10.260 von 10.616 Eigentümern vor der Veröffentlichung informiert. AWS kommt dabei besser weg, als die Schlagzeile nahelegt, denn die Quarantäne-Policy ist Amazon, das seine eigenen geleakten Schlüssel findet und den Eigentümer ungefragt warnt. Beide Hälften der Erkennungskette haben ihre Arbeit getan.

Das Ergebnis waren trotzdem 9.308 lebende Schlüssel mit einem Medianalter von fünf Jahren und einer Rotationsquote von 13,7%.

Die versagende Kontrolle bittet einen Menschen, Monate oder Jahre nach dem Fehler eine lästige Pflicht zu erledigen, auf einem System, das ihm vielleicht gar nicht mehr gehört, für einen Schlüssel, der kein Anzeichen dafür gibt, ein Problem zu sein. Kontrollen dieser Form scheitern in der Fläche, und sie scheiterten schon, bevor irgendetwas anfing, über Nacht Commits zu schreiben.

Also verlange von der lästigen Pflicht nicht länger, das Gewicht zu tragen. Leg in den Workspace Zugangsdaten, die nie die Zugangsdaten waren, und die Erhebung hat nichts zu zählen, der Korpus nichts zu spiegeln, und der Fünf-Jahres-Schweif gehört jemand anderem.

Quellen: Truffle Security, „Leaked Corporate AWS Keys Held Full Admin Rights“ (19. August 2026) · Truffle Security, „Scanning 7.6 Petabytes of HuggingFace Training Data for Secrets“ (1. Juni 2026) · Truffle Security, „Introducing TruffleHog AWS Analyze“ (20. August 2026) · BleepingComputer, „Hundreds of leaked AWS keys give full control over corporate accounts“ (21. August 2026) · Cybernews, „Massive exposure: researchers test leaked AWS keys, 9 out of 10 still authenticate“ (21. August 2026)