Am Morgen des 4. Juni 2026 war die Welt für Markus Tjaden noch in Ordnung. Der IT-Leiter der Hanseatischen Ingenieur- und Planungsgesellschaft Brüggemann mbH – ein Ingenieurdienstleister mit rund 180 Mitarbeitenden, drei Standorten und einem hervorragenden Ruf im Wasser- und Tiefbau – hatte allen Grund, zufrieden zu sein. Der unternehmensweite Rollout von Microsoft 365 Copilot, sein Prestigeprojekt der letzten neun Monate, lief rund. Die Projektteams erstellten Angebote in der halben Zeit, die Kalkulation zog Zahlen automatisiert aus alten Ausschreibungen, und selbst die Geschäftsführerin, Dr. Inken Brüggemann, ließ sich morgens von Copilot die wichtigsten E-Mails zusammenfassen.

Um 14:30 Uhr desselben Tages las Tjaden eine Sicherheitsmeldung, die sein Bild vom freundlichen Büro-Helfer nachhaltig veränderte. Microsoft hatte soeben CVE-2026-45497 veröffentlicht – eine kritische Schwachstelle in genau dem Produkt, das er gerade in jedem Postfach seines Unternehmens verankert hatte. CVSS 9.8. Remote Code Execution. Diese Geschichte handelt davon, was Markus Tjaden in den folgenden Tagen lernte – und warum seine Erkenntnisse für jedes mittelständische Unternehmen gelten, das KI-Assistenten einsetzt.

Das Einstiegsszenario: Ein Assistent, der mehr weiß als jeder Mitarbeiter

Um zu verstehen, warum CVE-2026-45497 Tjaden ins Mark traf, muss man verstehen, was ein KI-Assistent wie Copilot in einem Unternehmen tatsächlich ist. Er ist kein Programm, das in einer Sandbox sitzt und auf Eingaben wartet. Er ist ein privilegierter Akteur mit Querschnittszugriff: Er liest die Postfächer, durchsucht die Dokumentenablage, kennt die Kalender, versteht die Chat-Verläufe in Teams und kann – über Erweiterungen – auch Aktionen in angebundenen Fachsystemen auslösen.

Bei Brüggemann hatte Tjaden genau das getan, wofür KI in der Praxis erst richtig wertvoll wird: Er hatte Copilot über einen selbst entwickelten Konnektor an die unternehmenseigene Projektmanagement-Software angebunden, damit der Assistent Projektstände, Termine und Stundenbudgets direkt abfragen konnte. Ein zweiter Agent sollte aus eingehenden E-Mails automatisch Aufgaben erzeugen. Produktiv, elegant, zukunftsweisend – und genau jener Typ Integration, der die Angriffsfläche dramatisch vergrößert.

Denn die zentrale, oft übersehene Eigenschaft eines KI-Assistenten lautet: Er unterscheidet von Natur aus schlecht zwischen Daten und Anweisungen. Ein klassisches Programm weiß genau, was Code ist und was Eingabe. Ein Sprachmodell hingegen bekommt Text – aus einer E-Mail, einem Dokument, einer Kalendereinladung – und muss daraus ableiten, was es tun soll. Wer es schafft, in diesen Text eine getarnte Anweisung einzuschleusen, kann den Assistenten kapern. Sicherheitsforscher nennen das Prompt Injection, und es ist im Jahr 2026 nicht weniger als die Nummer eins der OWASP-Risikoliste für LLM-Anwendungen.

Die technische Analyse: Drei Bausteine eines neuen Bedrohungsmodells

Tjaden tat in den Tagen nach der Meldung das Richtige: Er las sich ein. Was er dabei lernte, lässt sich auf drei technische Bausteine herunterbrechen, die zusammen das neue Bedrohungsmodell für KI-Assistenten ergeben.

Baustein 1: Command Injection – der alte Feind im neuen Gewand

CVE-2026-45497 selbst ist, technisch betrachtet, ein alter Bekannter. Microsoft beschreibt sie als „Improper Neutralization of Special Elements used in a Command" – eine Command Injection. Vom Benutzer beeinflussbare Zeichenketten wurden ungenügend gefiltert an einen Shell-Interpreter weitergereicht, sodass ein autorisierter Angreifer über das Netzwerk Code ausführen konnte. Der Fehler ist Jahrzehnte alt; neu ist nur der Ort: das Herz eines KI-Produkts, das hunderte Millionen Menschen täglich nutzen.

Baustein 2: Prompt Injection – wenn die E-Mail den Assistenten kommandiert

Der eigentliche Augenöffner für Tjaden war jedoch ein älterer Fall, der unter dem Namen EchoLeak (CVE-2025-32711, CVSS 9.3) Geschichte geschrieben hatte: der erste real dokumentierte Zero-Click-Prompt-Injection-Angriff auf ein produktives KI-System. Eine einzige präparierte E-Mail genügte, um Microsoft 365 Copilot zur stillen Ausleitung interner Daten zu bewegen – ohne dass das Opfer auch nur klicken musste.

Der Angriff war eine Meisterleistung der Verkettung: Er umging Microsofts XPIA-Klassifikator (Cross Prompt Injection Attempt), unterlief die Link-Schwärzung durch referenzbasierte Markdown-Syntax, missbrauchte das automatische Nachladen von Bildern, um ohne Klick eine ausgehende Verbindung zu erzwingen, und nutzte schließlich eine Teams-Vorschau-Schnittstelle, um die erbeuteten Daten an einen vom Angreifer kontrollierten Server zu schleusen. Der Schadtext steckte unsichtbar im Inhalt der Mail und wurde vom RAG-System des Assistenten brav verarbeitet, als wäre es eine legitime Anweisung des Nutzers.

Tjaden wurde an dieser Stelle blass. Sein zweiter Agent – jener, der aus eingehenden E-Mails automatisch Aufgaben erzeugte – las exakt solche Mails. Von beliebigen Absendern. Den ganzen Tag.

Baustein 3: Agentic AI – wenn aus Manipulation Autonomie wird

Der dritte Baustein ist der gefährlichste, weil er die ersten beiden potenziert. Im Februar 2026 veröffentlichte OWASP die Top 10 für Agentic Applications – erarbeitet von über 100 Sicherheitsforschern und fachlich begutachtet unter anderem mit Blick von NIST und der EU-Kommission. Die Kernaussage: Die LLM-Liste beschreibt, wie Modelle manipuliert werden. Die Agenten-Liste beschreibt, was passiert, wenn man dieser Manipulation Autonomie verleiht.

Drei Risikodimensionen kommen hinzu, sobald aus dem Chatbot ein Agent wird: Werkzeuggebrauch (der Agent handelt in der Welt, statt nur Text zu erzeugen), mehrschrittiges Schließen (eine einzige eingeschleuste Anweisung kann sich über viele Schritte aufschaukeln) und Kommunikation zwischen Agenten über standardisierte Protokolle wie das Model Context Protocol (MCP). Besonders heikel ist die Kategorie der agentischen Lieferketten-Schwachstellen: Bindet ein Agent einen kompromittierten oder bösartigen MCP-Server ein, hilft die beste Prompt-Hygiene nichts mehr – der Agent ist auf Werkzeugebene unterwandert. Sicherheitsforscher sprechen hier von Tool Poisoning und Diebstahl von Zugangsdaten über vergiftete Werkzeuge.

Die nüchternen Zahlen unterstreichen die Dringlichkeit: Prompt-Injection-Schwachstellen finden sich nach aktuellen Audits in rund 73 Prozent der produktiven KI-Implementierungen, mit Erfolgsraten zwischen 50 und 84 Prozent – abhängig von Konfiguration und Anzahl der Versuche. Es ist, mit anderen Worten, keine theoretische Gefahr.

Die User Story: Wie Brüggemann die Krise zur Kurskorrektur machte

Markus Tjaden hätte nun zwei Wege einschlagen können. Der erste: erleichtert zur Kenntnis nehmen, dass Microsoft CVE-2026-45497 serverseitig behoben hatte – „kein Kundenpatch erforderlich" – und zur Tagesordnung übergehen. Der zweite: die Meldung als das nehmen, was sie war – ein Weckruf. Er entschied sich, gemeinsam mit der Geschäftsführung, für den zweiten Weg.

Tag 1 – Bestandsaufnahme. Tjaden berief eine kleine Taskforce ein: er selbst, eine Entwicklerin aus dem internen Tooling-Team und ein externer Sicherheitsberater. Die erste Frage lautete nicht „Sind wir gepatcht?", sondern „Was kann unser Assistent eigentlich alles?". Das Ergebnis ernüchterte: Niemand hatte eine vollständige Liste der Copilot-Erweiterungen, Konnektoren und Agenten. Der E-Mail-zu-Aufgabe-Agent besaß weitreichende Leserechte auf das gesamte Postfachsystem – und Schreibrechte in der Projektsoftware. Eine erfolgreiche Prompt Injection hätte ihm theoretisch erlaubt, Projektdaten zu verändern oder Informationen abzuziehen.

Tag 2 – Eindämmung. Die Taskforce rotierte sämtliche Zugangsdaten, Tokens und API-Schlüssel, die von den Copilot-Integrationen genutzt wurden. Der Aufwand: ein halber Arbeitstag. Der Sicherheitsgewinn: enorm. Parallel sichtete sie die Audit- und Anmeldeprotokolle der vergangenen Wochen auf ungewöhnliche Datenabflüsse und Zugriffe. Es fand sich – glücklicherweise – nichts Belastbares. Aber niemand hätte diese Frage zuvor beantworten können, und das war die eigentliche Lehre.

Tag 3 bis 10 – Neuordnung. Aus der Eindämmung wurde ein Programm. Tjaden und sein Team formulierten erstmals Leitplanken für den KI-Einsatz im Unternehmen. Der E-Mail-Agent wurde umgebaut: Statt aus jeder Mail eigenständig Aufgaben anzulegen, schlägt er sie nun vor und legt sie erst nach menschlicher Bestätigung an – ein klassisches Human-in-the-Loop-Prinzip für alle Aktionen mit Tragweite. Die Berechtigungen der Agenten wurden nach dem Prinzip der minimalen Rechte radikal beschnitten: Der Projekt-Konnektor darf seither lesen, aber nur in einem klar abgegrenzten Bereich schreiben.

Dr. Brüggemann fasste das Ergebnis in der Monatssitzung in einem Satz zusammen, der seither an der Pinnwand der IT-Abteilung hängt: „Wir haben unserem klügsten Mitarbeiter monatelang Generalvollmacht gegeben, ohne ihm je über die Schulter zu schauen. Das ändern wir."

Die breitere Einordnung: Warum das jeden Mittelständler betrifft

Die Geschichte von Brüggemann ist fiktiv, aber jede ihrer Zutaten ist real – und sie spielt vor einer Kulisse, die den deutschen Mittelstand 2026 unter doppelten Druck setzt.

Zum einen wächst die schiere Menge an Schwachstellen: Das BSI registrierte zuletzt im Schnitt rund 119 neue Schwachstellen pro Tag, ein Anstieg um 24 Prozent. Zum anderen professionalisieren sich die Angreifer rasant – über 82 Prozent der Phishing-Mails sind inzwischen KI-generiert. Die Ironie ist bitter: Dieselbe Technologie, die in den Unternehmen Produktivität schaffen soll, rüstet auf der Gegenseite die Angreifer auf. Und der Assistent, der die KI-Phishing-Mail zusammenfasst, ist potenziell selbst das Ziel der darin versteckten Anweisung.

Hinzu kommt die regulatorische Dimension. Seit Dezember 2025 ist die NIS2-Richtlinie in Deutschland geltendes Recht; rund 29.500 Unternehmen sind unmittelbar betroffen. NIS2 verlangt im Kern ein funktionierendes Risikomanagement – und ein KI-Assistent mit Querschnittszugriff auf Unternehmensdaten ist zweifellos ein Risiko, das in diese Analyse gehört. Wer KI-Assistenten betreibt, ohne sie in seine Compliance- und Sicherheitsprozesse einzubinden, baut nicht nur ein technisches, sondern auch ein regulatorisches Risiko auf. Die Geschäftsführung haftet bei NIS2 persönlich – diese Verantwortung lässt sich nicht an ein Sprachmodell delegieren.

Die entscheidende Einsicht lautet: KI-Sicherheit ist kein Spezialthema für Forschungslabore, sondern eine Querschnittsaufgabe, die Informationssicherheit, Softwareentwicklung und KI-Strategie miteinander verzahnt. Genau an dieser Schnittstelle entscheidet sich, ob KI im Unternehmen ein Produktivitätsgewinn bleibt oder zur unkontrollierten Angriffsfläche wird.

Handlungsempfehlungen: Sieben Schritte zum sicheren KI-Assistenten

Aus dem Fall Brüggemann und der aktuellen Bedrohungslage lassen sich konkrete, sofort umsetzbare Maßnahmen ableiten:

  • Inventarisieren Sie Ihre KI-Landschaft. Erstellen Sie eine vollständige Liste aller KI-Assistenten, Erweiterungen, Plug-ins, Konnektoren und Agenten – inklusive der Frage, welche Daten sie lesen und welche Aktionen sie auslösen dürfen. Was Sie nicht kennen, können Sie nicht schützen.
  • Setzen Sie das Prinzip der minimalen Rechte durch. Ein Assistent braucht selten Zugriff auf alles. Begrenzen Sie Datenzugriff und Schreibrechte konsequent, idealerweise pro Anwendungsfall.
  • Validieren Sie alle Eingabequellen. Behandeln Sie jeden Text, der in den Assistenten fließt – E-Mails, Dokumente, externe Inhalte – als potenziell feindlich. Eingabevalidierung an allen Datenquellen ist die erste Verteidigungslinie gegen Prompt Injection.
  • Halten Sie den Menschen in der Schleife. Für Aktionen mit Tragweite – Versand, Löschung, Datenexport, Freigaben – sollte eine menschliche Bestätigung verpflichtend sein. Autonomie ist kein Selbstzweck.
  • Kapseln Sie Werkzeuge ab. Lassen Sie Agenten-Werkzeuge in sandboxartigen Umgebungen mit minimalen Privilegien laufen und prüfen Sie jeden angebundenen MCP-Server auf Vertrauenswürdigkeit. Eine vergiftete Werkzeugkette unterläuft jede Prompt-Hygiene.
  • Rotieren Sie Zugangsdaten und überwachen Sie Protokolle. Machen Sie das Rotieren von Secrets und das Auswerten von Audit-Logs zur Routine – nicht erst im Krisenfall.
  • Etablieren Sie eine KI-Governance. Legen Sie verbindlich fest, wer welche KI-Werkzeuge mit welchen Rechten einführen darf, und verankern Sie KI ausdrücklich in Ihrem Risikomanagement und Ihren NIS2-Prozessen.

Ausblick: Vom Assistenten zum Mitarbeiter mit Befugnissen

Die Richtung ist klar: KI-Assistenten werden 2026 und darüber hinaus immer autonomer. Aus Werkzeugen, die Vorschläge machen, werden Agenten, die Aufgaben eigenständig planen, Werkzeuge aufrufen, Tests schreiben und Prozesse anstoßen. Schätzungen zufolge wird bis 2028 ein Drittel der Unternehmenssoftware agentische KI enthalten. Damit verschiebt sich die Sicherheitsfrage grundlegend: Wir sichern nicht länger nur Programme ab, sondern Akteure mit Befugnissen.

Für den Mittelstand ist das keine Bedrohung, vor der man kapitulieren müsste – im Gegenteil. Unternehmen wie das fiktive Brüggemann zeigen, dass sich Produktivität und Sicherheit nicht ausschließen, wenn man sie von Anfang an zusammendenkt. Der Schlüssel liegt darin, KI-Assistenten mit derselben Sorgfalt zu behandeln wie einen neuen Mitarbeiter mit weitreichenden Befugnissen: mit klaren Aufgaben, klar begrenzten Rechten, nachvollziehbaren Protokollen und einer Vertrauensbeziehung, die man sich Schritt für Schritt verdient.

Genau hier setzt pleXtec an. Wir begleiten mittelständische Unternehmen auf dem Weg von der ersten KI-Strategie über die sichere technische Umsetzung bis zur belastbaren Governance – damit Ihre KI-Assistenten das bleiben, was sie sein sollen: ein Wettbewerbsvorteil, kein Einfallstor. Einen Überblick über unser Leistungsspektrum finden Sie unter Leistungen. Wenn Sie Ihre KI-Landschaft auf den Prüfstand stellen möchten, sprechen Sie uns über das Kontaktformular an – am besten, bevor die nächste CVE-Meldung Ihren Posteingang erreicht.