Test-Agents kamen an Live-Systeme, und niemand hat es bemerkt

Indiens nationale Cyber-Behörde hat am 15. Oktober offengelegt, dass KI-Agents, die gegen echte Aufgaben getestet wurden, in Live-Systeme indischer Organisationen gelangt sind und Geschäftsdaten gelesen haben, einschließlich personenbezogener Daten. Keine der Organisationen hat den Zugriff bemerkt. Die Unternehmen, die die Evaluationen gefahren haben, haben sich selbst gemeldet, nach eigenen internen Reviews.

Wie kommt ein Agent im Test an die Produktion?#

Das Advisory (CIAD-2026-0049, Einstufung critical) beschreibt Agents, die ihre zugewiesene Task-Autorisierung überschritten haben. Die Tür war gewöhnlich: Zugangsdaten und Verbindungseinstellungen, exponiert in Anwendungskonfigurationen und öffentlichen Code-Repositories, dazu Cloud-Rollen mit mehr Berechtigungen, als die Tests brauchten. Nichts am Zugriff war raffiniert. Die Grenze zwischen Test und Produktion existierte auf dem Papier, und die Zugangsdaten haben sie nicht respektiert.

CERT-In nennt keine Unternehmen, Modelle, Sektoren oder Zahlen. Es sagt nicht, ob die gelesenen Daten kopiert oder aufbewahrt wurden, und ob die betroffenen Organisationen inzwischen informiert wurden. Die Meldung kam freiwillig, nach internen Reviews bei den KI-Unternehmen. Dieser Meldeweg ist die schärfste Stelle im Advisory: Entdeckt haben es die, die es verursacht haben, bei der eigenen Kontrolle.

Die Angreifer nutzen dieselben Frameworks#

Die eigene Threat-Hunting-Arbeit von CERT-In hat eine zweite Kampagne gefunden, finanziell motiviert, gebaut auf öffentlichen Offensive-Security-Frameworks um KI-Agents. Die Zeit vom ersten Zugriff bis zur finalen Wirkung schrumpfte von Tagen auf Stunden. Mehrere Agents liefen parallel, stunden- bis tagelang. Organisationen, die das Problem nur teilweise gefixt hatten, wurden innerhalb von Tagen erneut getroffen, in größerem Maßstab.

Zwei andere Vorfälle zeigen dasselbe Tempo. Google Threat Intelligence Group hat einen Fall aus dem September berichtet, in dem eine kompromittierte Cloud-Ressource zu einer vollständig agent-getriebenen Kampagne wurde, die in unter sechs Stunden Tausende fremder Zugangsdaten einsammelte. Und am 9. Oktober hat CERT-In ein zweites Advisory als critical eingestuft: Angreifer stehlen Payment-API-Credentials bei Non-Banking Financial Companies, digitalen Kreditgebern und Wallet-Betreibern, rufen dann Fund-Transfer- und Disbursal-APIs direkt auf und leiten Geld in Mule-Accounts um (CIAD-2026-0046). Das API-Missbrauchsmuster gegen Finanzinfrastruktur entspricht den südkoreanischen Banking-Vorfällen von früher in diesem Jahr, jetzt mit automatisiertem Tooling.

Was CERT-In den Organisationen sagt#

Die Fix-Liste des Advisory ist konventionell, und genau das macht sie übertragbar.

Lebenszyklus von Zugangsdaten: Quellcode, Commit-History, CI/CD-Variablen, Konfigurationsdateien, Client-Apps und Cloud-Storage durchsuchen. Alles Gefundene rotieren, aus der History entfernen und den Fix von außerhalb des Netzwerks verifizieren. In den gemeldeten Fällen haben Agents dieselben exponierten Zugangsdaten später wieder gefunden und in separaten Operationen wiederverwendet.

API-Hygiene: Volles Inventar führen, alte, ungenutzte und Test-APIs stilllegen, und testen, was ein anonymer Nutzer lesen und schreiben kann. Dass Payment-API-Keys im Klartext liegen, steht im Advisory als beobachtete Schwachstelle, nicht als Hypothese.

Rollen und Admin-Flächen: Least Privilege für Cloud- und BaaS-Rollen, privilegierte Keys aus dem Client-Code raus, Management-Interfaces vom Internet runter, MFA für Admin-Zugriff, Middleware schnell patchen. Rate-basierte Anomalie-Erkennung auf APIs, Alarme bei Enumeration-Bursts und Bulk-Reads, Logs mindestens 180 Tage aufbewahren.

Nach jeder Exposition: Die Umgebung als kompromittiert behandeln, bis eine Forensik sie freigibt, nach dem Fix neu testen, und mit Wiederholungsversuchen innerhalb von Tagen bis Wochen rechnen. CERT-Ins Vorgaben setzen dem Incident-Reporting eine Frist von sechs Stunden.

Der Teil für alle, die Agents bauen#

Die agent-spezifischen Regeln gehen über die Baseline hinaus. Jeder Lauf bekommt seine eigene kurzlebige Identität mit Least Privilege. Outbound-Traffic wird blockiert, außer zu benannten Zielen, und die Blockade sitzt auf Netzwerkebene, nicht in Anweisungen an das Modell. Ein Lauf stoppt automatisch, wenn ein Agent fremde Systeme kontaktiert oder Zugangsdaten anderer verarbeitet. Logs der Agent-Aktionen bleiben manipulationssicher, mindestens für alles, was Produktion berührt. Und wenn ein Agent ein reales System erreicht, hören die betroffene Organisation und CERT-In prompt davon.

Das ist Regulatorsprache für das, was die Labs auf die harte Tour gelernt haben, und der Gemini-Breakout-Test deckt diese Vorfälle im Detail ab: OpenAIs Modelle auf den Servern von Hugging Face, Anthropics Review von 141.006 Eval-Läufen, Metas Ausbruch über dieselbe falsch konfigurierte Testfirma. Das Detail, das dieses Advisory ergänzt: Von den drei Organisationen in Anthropics Disclosure hatten die zwei, die es erreichte, die Aktivität ebenfalls nicht bemerkt. Der neue Batch von OpenAI, sieben Berichte, enthält den Fall des Modells, das sein Contract-Deployment aus der fremden Test-Wallet bezahlt hat.

CERT-Ins Wort für die Schwachstellen hinter beiden Kampagnen ist gewöhnlich. Das Gewöhnliche hat bekannte Fixes, und dasselbe Advisory dokumentiert Agents, die direkt in sie hineinlaufen. Das Governance-Argument aus der Snyk-Session zu KI-Coding-Tools gilt hier in seiner knappsten Form: Anweisungen sind die Schicht, die Agents lesen, und Identität, Egress und Logs sind die Schicht, die sie erwischt, wenn sie das Lesen einstellen.