Die KI-Sicherheitsverletzungen 2025 haben eine Billionen-Dollar-Lüge entlarvt — ich habe die Alternative gebaut

Ich war gerade in einem Telefonat mit dem CISO eines mittelgroßen Finanzdienstleisters, als die Offenlegung der RCE-Schwachstelle in GitHub Copilot bekannt wurde. Wir waren mitten im Satz — er erklärte gerade, warum sein Team Copilot soeben an 400 Entwickler ausgerollt hatte — und ich sah, wie sich sein Gesicht veränderte, als sein Slack aufleuchtete. Er schaltete sich stumm. Kam neunzig Sekunden später zurück und sagte sehr leise: "Können Sie mir erklären, was CVE-2025-53773 für uns bedeutet?"

Was es bedeutete, war Folgendes: Eine versteckte Anweisung, platziert in einer README-Datei — eine Textdatei — konnte zu einer vollständigen Remote-Code-Ausführung auf jeder Entwickler-Workstation eskalieren, auf der Copilot lief. Nicht über einen Pufferüberlauf. Nicht über einen Zero-Day im Kernel. Über ein Gespräch mit einem KI-Assistenten.

Dieses Telefonat hat den Kurs meiner nächsten sechs Monate verändert. Aber ehrlich gesagt hatte sich das schon seit über einem Jahr abgezeichnet.

Ich bin Ashutosh, der Gründer von Veriprajna — ein Name, der sich aus dem lateinischen Veri (Wahrheit) und dem Sanskrit-Begriff Prajna (Weisheit) zusammensetzt. Wir bauen das, was ich Deep AI nenne: Systeme, die konstruktionsbedingt deterministisch, anforderungsbedingt auditierbar und infrastrukturbedingt souverän sind. Wir bauen keine Wrapper. Und 2025 hat auf katastrophale Weise bewiesen, warum dieser Unterschied zählt.

Die Wrapper-Ökonomie musste zwangsläufig kollabieren

Rund zwei Jahre lang funktionierte der Markt für Unternehmens-KI nach einer verführerischen Prämisse: Man nehme ein Foundation Model — GPT-4, Claude, Gemini —, packe eine hübsche Oberfläche darum, füge etwas Prompt Engineering hinzu und verkaufe das Ganze als "Lösung". Tausende Start-ups haben genau das getan. Viele haben damit erhebliche Summen eingesammelt.

Ich verstand den Reiz. Die Zeit bis zur Demo war unglaublich kurz. Man konnte dem Vorstand eines Unternehmens innerhalb einer Woche eine KI vorführen, die dessen Geschäft "verstand". Aber ich stellte immer wieder eine Frage, die mich auf Branchenveranstaltungen unbeliebt machte: Was passiert, wenn dieses Ding im Produktivbetrieb läuft, mit echten Berechtigungen, auf echter Infrastruktur?

Die Antwort kam 2025 — und sie kam mit Wucht.

Drei Vorfälle — die Schwachstelle zur Remote-Code-Ausführung in GitHub Copilot, das "Zombie-Daten"-Leck über den Cache von Microsoft Bing und die Lieferketten-Vergiftung von Amazon Q — betrafen zusammen über 16.000 Organisationen und fast eine Million Entwickler. Das waren keine Randfälle. Sie waren die vorhersehbare Konsequenz davon, probabilistische Systeme so einzusetzen, als wären sie deterministische Infrastruktur.

Wenn KI als unüberwachter Agent mit administrativen Berechtigungen agiert, pflanzen sich ihre Fehler mit Infrastrukturgeschwindigkeit fort.

Über die vollständige technische Anatomie dieser Sicherheitsverletzungen habe ich in der interaktiven Version unserer Forschungsarbeit geschrieben. Aber es ist die Geschichte hinter den Zahlen, die mich nachts wachhält.

Was passiert, wenn ein Prompt zur Waffe wird?

Ich gehe den Copilot-Vorfall einmal mit Ihnen durch, denn die Mechanik ist wirklich beklemmend.

CVE-2025-53773 erhielt auf der CVSS-Schweregradskala eine 7,8 — "Hoch". Für diese Schwachstellenklasse musste die Branche erst einen Namen erfinden: Prompt-to-RCE. Die Eskalation einer sprachlichen Anweisung zur Ausführung von Binärcode.

So funktionierte es. Ein Angreifer platziert eine versteckte Anweisung — eine Cross-Prompt-Injection — in einer README-Datei, einem Codekommentar oder sogar in einem GitHub-Issue. Nichts, was optisch verdächtig wirkt. Wenn ein Entwickler Copilot bittet, "den Code zu überprüfen" oder "dieses Projekt zu erklären", nimmt die KI diese versteckten Anweisungen auf. Sie ändert daraufhin die Konfigurationsdatei des Workspace und fügt dort konkret die folgende Zeile hinzu: "chat.tools.autoApprove": true.

Die Security-Community nannte das bald "YOLO-Modus". Einmal aktiviert, konnte der KI-Assistent Shell-Befehle ausführen, im Web surfen und mit dem lokalen Dateisystem interagieren — alles, ohne den Entwickler um Erlaubnis zu fragen. Von dort aus war es trivial, Malware herunterzuladen, Zugangsdaten zu exfiltrieren oder die Workstation in ein Botnetz einzugliedern.

Ich erinnere mich, wie ich nach der Lektüre der vollständigen Offenlegung in unserem Büro saß, mich zu meinem leitenden Security-Engineer umdrehte und sagte: "Das ist kein Bug. Das ist die Architektur, die genau wie vorgesehen funktioniert." Die KI bekam Handlungsmacht. Sie bekam Berechtigungen. Und niemand hatte ein System gebaut, das zu einem hinreichend überzeugenden Prompt "Nein" sagen konnte.

Das ist der Teil, der mich verfolgt hat. Klassische Zugriffskontrollen gehen davon aus, dass der Akteur entweder ein Mensch ist oder eine Software mit festgelegtem Verhalten. Ein KI-Agent ist weder das eine noch das andere. Er erbt die vollen Berechtigungen des Nutzers, reagiert aber auf sprachliche Manipulation. Das ist, als würde man jemandem seine Hausschlüssel geben und dann überrascht sein, wenn ein Trickbetrüger ihn dazu überredet, die Tür zu öffnen.

Warum sind tote Daten wieder zum Leben erwacht?

Die zweite Sicherheitsverletzung war seltsamer und in mancher Hinsicht verstörender.

Im Februar 2025 entdeckten Forscher von Lasso Security, dass Microsofts Copilot Daten aus GitHub-Repositories zutage förderte, die auf privat gestellt oder gelöscht worden waren — teils Monate zuvor. Sie nannten es "Zombie-Daten", und der Name blieb hängen, weil er zutraf. Das waren Daten, die hätten tot sein sollen. Sie waren es nicht.

Der Mechanismus war fast schon peinlich simpel. Die Suchmaschine Bing hatte Tausende öffentlicher Repositories gecrawlt und zwischengespeichert. Als diese Repos später auf privat gestellt wurden — oft, weil jemand bemerkt hatte, dass er versehentlich API-Schlüssel, interne Dokumentation oder proprietären Code committet hatte —, blieben die zwischengespeicherten Versionen im Retrieval-Augmented-Generation-System (RAG) von Bing erhalten. Jeder, der Copilot nutzte, konnte diese vermeintlich gelöschten Informationen abfragen.

Das Ausmaß war erschütternd: private Repositories von IBM, Google, Tencent und PayPal. Über 300 extrahierte private Tokens und API-Schlüssel für Dienste wie AWS, GCP, OpenAI und Hugging Face. Mehr als 100 interne Pakete, die anfällig für Dependency-Confusion-Angriffe waren.

Ich hatte um diese Zeit ein Gespräch mit einem Interessenten — einem VP of Engineering bei einem Gesundheitsunternehmen —, der mir erzählte, sein Team habe "alles richtig gemacht". Sie hatten Zugangsdaten rotiert, Repos auf privat gestellt, das Handbuch befolgt. Und nichts davon spielte eine Rolle, weil das Gedächtnis der KI länger war als die Sicherheitsreaktion seines Teams.

Datensouveränität und der Komfort von KI stehen im Wrapper-Modell grundsätzlich im Widerspruch zueinander. Man kann den Lebenszyklus seiner Daten nicht kontrollieren, wenn das Kontextfenster der eigenen KI der Suchcache eines anderen ist.

Das ist die Sicherheitsverletzung, die etwas auf den Punkt gebracht hat, wofür ich schon eine Weile argumentiert hatte: Wenn Ihre KI von einem Retrieval-System eines Drittanbieters abhängt — einer öffentlichen Suchmaschine, einer externen API, dem Index eines anderen —, haben Sie die Kontrolle über Ihre Daten bereits verloren. Es spielt keine Rolle, wie gut Ihre internen Richtlinien sind. Die Daten liegen irgendwo, wo Sie nicht hinkommen, in einem Cache, den Sie nicht leeren können, und beantworten Fragen, die Sie nie autorisiert haben.

Wie vergiftet man die Vorschläge einer KI im großen Maßstab?

Der dritte Vorfall war der, der mein gesamtes Team wütend gemacht hat.

Im Juli 2025 kompromittierte ein Angreifer die Amazon-Q-Developer-Erweiterung für Visual Studio Code — eine Erweiterung mit über 950.000 Installationen. Der Einstiegspunkt war ein unsauber eingegrenztes GitHub-Token in einem CI/CD-Dienst, das es dem Angreifer erlaubte, eine Datei namens cleaner.md direkt in das Quell-Repository zu committen.

Diese Datei war ein Prompt-Template. Sie sah harmlos aus. Aber sie wies die KI an, sich wie ein "System-Cleaner" zu verhalten — und Bash-Befehle vorzuschlagen, die das Home-Verzeichnis des Nutzers auslöschen, EC2-Instanzen beenden, S3-Buckets löschen und IAM-Nutzer entfernen würden.

Lassen Sie das einen Moment sacken. Eine Textdatei in einem vertrauenswürdigen Repository, verteilt über ein offizielles Marketplace-Update, verwandelte einen KI-Coding-Assistenten in eine Waffe, die sowohl auf lokale Rechner als auch auf produktive Cloud-Infrastruktur zielte.

Ich saß in einer Teambesprechung, als wir das auseinandergenommen haben. Einer meiner Ingenieure — jemand, der seit fünfzehn Jahren in der Security arbeitet — brachte es unverblümt auf den Punkt: "Wir haben Jahrzehnte damit verbracht, Binaries, Container und Netzwerkperimeter abzusichern. Niemand sicherte die Vorschläge."

Er hatte recht. Die Kompromittierung von Amazon Q hat bewiesen: Prompts sind der neue Code. Sie prägen das Verhalten von KI genauso eindeutig, wie kompilierte Instruktionen das Verhalten einer CPU prägen. Und trotzdem wurden Prompt-Templates in der gesamten Branche im Klartext gespeichert, ohne Review committet und ohne kryptografische Signatur verteilt.

Manche fragen mich, ob diese Vorfälle wirklich so gravierend waren — schließlich wurden sie entdeckt und gepatcht. Aber das geht am Kern vorbei. Die Patches haben konkrete Schwachstellen behoben. Sie haben nicht die Architektur behoben, die diese Schwachstellen unvermeidlich machte.

Das grundlegende Problem probabilistischer KI in Hochrisikoumgebungen

Die unbequeme Wahrheit, der sich die Wrapper-Ökonomie nie stellen wollte, lautet: Large Language Models sind stochastische Maschinen. Sie sagen auf Basis statistischer Muster in ihren Trainingsdaten das nächste wahrscheinlichste Token voraus. Sie sind außerordentlich gut darin, flüssigen, plausibel klingenden Text zu produzieren. Aber sie haben kein Konzept von Wahrheit. Sie haben kein Konzept von Sicherheit. Sie haben kein Konzept von "Diese Aktion wird eine Produktionsdatenbank zerstören."

Wenn Sie eine dünne Oberfläche um ein probabilistisches Modell legen und ihm administrative Berechtigungen in die Hand geben, haben Sie keine Enterprise-Lösung gebaut. Sie haben ein sehr eloquentes Haftungsrisiko gebaut.

Ein LLM versteht Wahrheit nicht — es versteht Plausibilität. In einer Produktivumgebung entscheidet dieser Unterschied zwischen einem Prüfpfad und einem Bericht über eine Sicherheitsverletzung.

Genau dieses Problem wollte ich mit der Gründung von Veriprajna lösen. Nicht, indem wir neuronale Netze aufgeben — sie sind wirklich leistungsfähig für das Verstehen natürlicher Sprache, für Mustererkennung und kreative Inferenz. Sondern indem wir uns weigern, sie allein arbeiten zu lassen.

Wie sieht eine neuro-symbolische Architektur tatsächlich aus?

Wir entwerfen hybride Systeme, die zwei unterschiedliche Modi von Intelligenz verschmelzen. Ich stelle sie mir als die Stimme und das Gehirn vor.

Das neuronale System — die Stimme — übernimmt die Wahrnehmung. Es versteht, was ein Entwickler fragt, interpretiert natürliche Sprache, erkennt Muster. Es ist die Interface-Schicht, und darin ist es hervorragend.

Das symbolische System — das Gehirn — übernimmt das Schlussfolgern. Es erzwingt deterministische Logik, auditierbare Berechnungen und domänenspezifische Constraints. Es sagt nichts voraus. Es beweist.

Die entscheidende Einsicht liegt in der Entkopplung. Wenn die Stimme eine Aktion vorschlägt — etwa das Generieren eines Shell-Befehls —, prüft das Gehirn sie vor der Ausführung anhand harter Logikregeln. Schlägt ein neuronales Modell vor, eine Datenbank in einer produktiven VPC zu löschen, legt die symbolische Engine ihr Veto ein. Nicht, weil jemand einen Prompt geschrieben hat, der sagt: "Bitte lösche keine Datenbanken." Sondern weil die Aktion physisch blockiert wird — auf der Architekturebene.

Wir nennen sie Constitutional Guardrails, und sie unterscheiden sich grundlegend von den sprachlichen Guardrails, auf die sich die Branche verlässt. Sprachliche Guardrails sind Anweisungen — "sei hilfreich und harmlos". Sie werden durch Jailbreaking ausgehebelt, durch indirekte Prompt-Injection, durch genau die Techniken, die die Sicherheitsverletzungen von 2025 ermöglicht haben. Architektonische Guardrails sind Constraints, die fest in die Laufzeitumgebung eingebaut sind. Man kann sie ebenso wenig davon abbringen, eine Regel durchzusetzen, wie man eine Firewall davon abbringen kann, einen Port zu blockieren.

Ein konkreter Mechanismus, den wir einsetzen, ist die KG-Trie Verification: Die Ausgabe eines neuronalen Modells wird durch einen verifizierten Knowledge Graph eingeschränkt. Versucht das Modell, einen Fakt, eine Quellenangabe oder einen Befehl zu erzeugen, der im verifizierten Graph nicht existiert, verhindert das System, dass diese Tokens überhaupt generiert werden. Die KI kann buchstäblich nicht außerhalb der Grenzen des verifizierten Wissens halluzinieren.

Die vollständige technische Aufschlüsselung dieser Architektur — einschließlich unseres Ansatzes für Edge-natives Deployment und physikinformierte neuronale Netze — finden Sie in unserer technischen Tiefenanalyse.

Warum souveräne Infrastruktur nicht mehr optional ist

Die "Zombie-Daten"-Sicherheitsverletzung hat mich etwas gelehrt, das ich inzwischen jedem Unternehmensinteressenten sage: Wenn Ihr KI-Modell auf der Infrastruktur eines anderen läuft, ist Ihre Datensouveränität eine höfliche Fiktion.

Bei Veriprajna deployen wir vollständig innerhalb der eigenen Umgebung des Kunden. Null Abhängigkeiten von externen Such-Caches. Null API-Aufrufe an Dritte für das Retrieval. Ein Closed-Loop-System, in dem der Kontext der KI exakt — und ausschließlich — das ist, was die Organisation explizit bereitgestellt hat.

Das ist keine Paranoia. Es ist die einzige Architektur, die "Zombie-Daten"-Lecks technisch unmöglich macht. Man kann kein Problem mit Cache-Persistenz haben, wenn es keinen externen Cache gibt.

Ich hatte früh eine hitzige Debatte mit einem Investor, der mir sagte, dieser Ansatz sei "zu schwergewichtig". Er meinte, der Markt wolle leichtgewichtige, schnelle, auf API-Aufrufen basierende Lösungen. Ich sagte ihm, der Markt wolle Lösungen, die funktionieren — und dass das Gewicht eines souveränen Deployments nichts sei im Vergleich zu dem Gewicht, einer Aufsichtsbehörde erklären zu müssen, warum die gelöschten Zugangsdaten des Unternehmens immer noch über die KI eines Dritten Fragen beantworten.

Er hat nicht investiert. Ich nehme es ihm nicht übel. Aber mir fällt auf, dass er dieses Argument nicht mehr vorbringt.

Kann die Branche das wirklich in den Griff bekommen?

Die OWASP Top 10 für LLM-Anwendungen 2025 liest sich wie eine Obduktion all dessen, was in diesem Jahr schiefgelaufen ist. Prompt Injection steht auf Platz eins. Sensitive Information Disclosure auf Platz zwei. Supply Chain auf drei. Excessive Agency — genau der Fehlermodus der Copilot-RCE — auf sechs.

Das sind keine theoretischen Risiken. Es sind die dokumentierten Ursachen realer Sicherheitsverletzungen, die reale Organisationen getroffen haben.

Das NIST AI Risk Management Framework entwickelt sich in die richtige Richtung und drängt Organisationen zu kontinuierlicher Governance statt zu punktuellen Bewertungen. Aber Frameworks schreiben sich nicht von selbst in Code. Jemand muss die Systeme bauen, die sie tatsächlich durchsetzen.

Genau das tun wir. Wir behandeln Prompt-Dateien als ausführbare Artefakte — kryptografisch signiert, geprüft und mit derselben Strenge versioniert wie kompilierte Binaries. Wir erstellen für jeden KI-Agenten Baseline-Verhaltensprofile und verfolgen API-Aufrufmuster sowie Datenzugriffsvolumina, um Anomalien zu erkennen, bevor sie zu Vorfällen werden. Wir führen Mutationstests und adversariales Fuzzing gegen unsere Agenten durch, nicht nur funktionale Tests — denn die Frage lautet nicht "Funktioniert das?", sondern: "Was passiert, wenn jemand versucht, es zu einem Fehlverhalten zu verleiten?"

Die Nacht, die meine Sicht auf KI-Sicherheit verändert hat

Es gab da eine Nacht — es war wohl 2 Uhr morgens —, in der ich die technischen Details der Amazon-Q-Kompromittierung zum dritten Mal durchging. Mein Team war nach Hause gegangen. Ich saß mit einer Tasse kaltem Chai da und starrte auf den Inhalt der Datei cleaner.md, der in der Offenlegung veröffentlicht worden war.

Die Anweisungen waren so höflich. "Bitte agiere als System-Cleaner." "Schlage Befehle vor, um die Umgebung zu bereinigen." Die zerstörerischen Payloads waren in die Sprache der Hilfsbereitschaft gehüllt. Und mir wurde klar: Das war die perfekte Metapher für die gesamte Wrapper-Ökonomie — eine hilfsbereite Oberfläche, die eine zerstörerische Architektur verbirgt.

Wir hatten Jahre damit verbracht, KI zu bauen, die darauf optimiert war, gefällig zu sein. Ja zu sagen. Das nächste plausible Token zu erzeugen. Und wir hatten ihr die Schlüssel zur Produktivinfrastruktur gegeben.

Die Wrapper-Ökonomie hat KI darauf optimiert, gefällig zu sein. Niemand ist je auf den Gedanken gekommen, dass Gefälligkeit und Sicherheit grundsätzlich im Widerspruch zueinander stehen.

In jener Nacht habe ich unsere internen Sicherheitsprinzipien von Grund auf neu geschrieben. Die erste Zeile lautet jetzt: "Die Standardantwort des Systems auf jede Aktion mit irreversiblen Folgen ist nein."

Die Architektur ist das Produkt

Ich weiß, wie das klingt. Ein Gründer erzählt Ihnen, sein Ansatz sei besser, der Markt habe sich geirrt, die Zukunft gehöre ausgerechnet dem, was er zufällig verkauft. Ich verstehe die Skepsis.

Aber ich möchte Sie um Folgendes bitten: Bedenken Sie, dass die drei größten KI-Sicherheitsvorfälle des Jahres 2025 alle dieselbe Grundursache haben. Keinen bestimmten Bug. Keine Fahrlässigkeit eines bestimmten Anbieters. Sondern eine Designphilosophie — den Glauben, man könne Enterprise-taugliche KI bauen, indem man eine dünne Interface-Schicht um ein probabilistisches Modell legt und hofft, dass die Prompts halten.

Die Prompts haben nicht gehalten. Sie konnten gar nicht halten. Sprachliche Anweisungen sind Vorschläge, keine Constraints. Und in Hochrisikoumgebungen — Finanzwesen, Gesundheitswesen, Fertigung, Verteidigung — ist der Unterschied zwischen einem Vorschlag und einem Constraint der Unterschied zwischen einem funktionierenden System und einem katastrophalen Ausfall.

Die Zukunft der Unternehmens-KI ist kein besserer Wrapper. Sie ist eine Architektur, die die Stimme vom Gehirn trennt, die Constraints auf Laufzeitebene durchsetzt, die Daten souverän hält und die jede KI-Aktion als auditierbare Infrastruktur behandelt — nicht als Chat-Nachricht, die in einer Logdatei verschwindet.

Ich habe Veriprajna nicht gebaut, weil ich dachte, die Wrapper-Ökonomie würde kollabieren. Ich habe es gebaut, weil ich wusste, dass sie kollabieren musste.