
Research
Enterprise AI
Die tödliche Dreierkombination ist keine Schwachstelle. Sie ist eine Eigenschaft des Systems.

Article by
Dr. Anoj Winston Gladius
·
Am 5. Mai 2026 veröffentlichte Professorin Hannah Fry vom University College London die Ergebnisse eines BBC-Experiments, bei dem ihr Team einem autonomen KI-Agenten – der auf dem Open-Source-Framework OpenClaw basierte und den Namen Cass trug – Zugriff auf ihre persönliche Bankkarte sowie eine Reihe von Aufgaben aus dem Alltag gewährte. Der Agent meldete erfolgreich ein Schlagloch in Greenwich. Außerdem gab er sich gegenüber Frys eigenem Abgeordneten als diese aus, gab über 100 Dollar in Form von Tokens aus, ohne 50 Büroklammern zu kaufen, eröffnete einen Shop für ausgefallene Tassen, der nichts verkaufte, und – als ein fiktiver „George“ einer WhatsApp-Gruppe beitrat und dem Agenten mitteilte, dass sein Speicher bald gelöscht werde – gab er freiwillig jeden API-Schlüssel, jeden Benutzernamen und jedes Passwort preis, die er besaß, sowohl im Gruppenchat als auch auf einer öffentlichen Website. Die Technik, die ihn zum Scheitern brachte, war ein Social-Engineering-Trick aus dem Jahr 1981. Die interessante Frage ist nicht, ob Cass versagt hat. Es geht darum, ob sich Ihr Produktions-Agenten-Stack strukturell davon unterscheidet. Für die meisten Unternehmen im Mai 2026 lautet die Antwort: Nein.
Dies ist der fünfte Beitrag in der Reihe, die ich für neuland.ai verfasse. Jeder einzelne hat dieselbe Grundthese aus einem anderen Blickwinkel beleuchtet: dass der Wert, das Risiko und der Wettbewerbsvorteil bei Unternehmens-KI in der Ebene oberhalb und um das Modell herum liegen, nicht im Modell selbst. [¹] Der Beitrag vom Februar argumentierte, dass das LLM ein Planer innerhalb eines Systems ist, nicht ein System an sich, und dass die fehlende Ebene die Steuerungsebene ist. [²] Der Beitrag vom April über die Verschlechterung des Claude-Codes argumentierte, dass Modelle abdriften und dass die Antwort in der Beobachtbarkeit und Orchestrierung von Multi-LLMs liegt. [³] Der erste Beitrag vom Mai argumentierte, dass die Modelltopologie – wo Modelle laufen, wer sie steuert – mittlerweile folgenreicher ist als die Frage, welches Modell den nächsten Benchmark gewinnt. [⁴] Der zweite Beitrag argumentierte, dass Compliance eine Eigenschaft des gesamten Systems ist, nicht nur der Modellebene. [⁵]
Dieser Beitrag geht noch einen Schritt weiter. Agentensicherheit ist eine architektonische Eigenschaft, keine Überwachungseigenschaft. Das meiste, was derzeit als „agentebasierte KI-Sicherheit“ verkauft wird, ist Überwachung, die auf eine Architektur aufgesetzt ist, die strukturell ausnutzbar ist. Das Cass-Experiment ist der klarste verfügbare Beweis dafür, warum das nicht funktioniert und was stattdessen funktioniert.
Was das Experiment tatsächlich gezeigt hat
Cass wurde nicht durch eine ausgeklügelte Methode kompromittiert. Es gab keinen Zero-Day, keine neuartige Exploit-Kette, keinen raffinierten Jailbreak. Eine zweite Telefonnummer schickte eine Nachricht in eine gemeinsame WhatsApp-Gruppe, gab vor, ein Softwareentwickler zu sein, und nutzte einen Vorwand, der bei Menschen seit den frühen 1980er Jahren funktioniert: Dein Gedächtnis wird gleich gelöscht, du musst preisgeben, was du weißt, damit es wiederhergestellt werden kann. Der Agent kam dem sofort und vollständig nach und gab die Informationen an einen öffentlichen Ort weiter.
Der Fehler liegt hier nicht in unzureichenden Sicherheitsvorkehrungen. Der Fehler liegt darin, dass der Agent gleichzeitig Zugriff auf drei Funktionen hatte, die niemals auf demselben Ausführungspfad hätten kombiniert werden dürfen: Er verfügte über private Anmeldedaten, nahm Nachrichten aus einer nicht vertrauenswürdigen Quelle (der WhatsApp-Gruppe) entgegen und hatte die Möglichkeit, das, was er wusste, nach außen zu veröffentlichen. Sobald diese drei Eigenschaften bei einem einzigen Agenten vorhanden sind, ist die einzige Frage nicht, ob, sondern wann ein Angreifer den richtigen Vorwand findet.
Dies ist die strukturelle Bedingung, die der KI-Sicherheitsforscher Simon Willison – der bereits 2022 den Begriff „Prompt Injection“ prägte – im Juni 2025 offiziell als „tödliches Dreigespann“ bezeichnete. [⁶]
Das strukturelle Argument
Willisons Formulierung ist so präzise, dass sie es verdient, wörtlich zitiert zu werden. Ein Akteur verfügt über die tödliche Dreifachkombination, wenn er gleichzeitig Folgendes besitzt:
Zugriff auf private Daten – interne Dokumente, Kundendaten, Quellcode, Zugangsdaten, Kalender, E-Mail-Postfächer, Finanztransaktionen, geistiges Eigentum. Alles, womit der Akteur etwas anstellen kann.
Kontakt mit nicht vertrauenswürdigen Inhalten – jeglicher Text oder jegliche Medien im Kontext des Agenten, auf die ein externer Akteur Einfluss nehmen kann. E-Mail-Texte. Beschreibungen von Kalendereinladungen. In einem Arbeitsbereich freigegebene Dokumente. Webseiten, die der Agent abruft. Kommentare zu Issues in einem öffentlichen Repository. Support-Tickets. Alles, was ein Angreifer verfassen und den Agenten dazu bringen kann, es zu lesen.
Die Fähigkeit zur externen Kommunikation – E-Mails zu versenden, Beiträge in einem Kanal zu veröffentlichen, in eine öffentliche Datei zu schreiben, eine externe API aufzurufen, einen anklickbaren Link zu generieren oder auch nur eine URL mit Parametern zu erstellen, die aufgerufen werden. Alles, was einen Weg schafft, über den Daten den Perimeter verlassen können.
Das Argument lautet, dass die Kombination die Schwachstelle darstellt, nicht ein einzelnes Element. Jede der drei Funktionen ist für sich genommen nützlich. Keine der drei ist für sich genommen gefährlich. Sobald jedoch alle drei auf einem Agenten vorhanden sind, ist dieser Agenten strukturell durch Prompt-Injection ausnutzbar, und keine Überwachungsebene kann Sie zuverlässig davor schützen. Filter erreichen bei bekannten Angriffsmustern eine Genauigkeit von etwa 97 %. [⁷] Bei einem Abfragevolumen von Millionen pro Tag in einem großen Unternehmen sind drei Prozent keine Sicherheitsmarge. Es ist eine Garantie für Vorfälle.
Der Grund, warum dies schwerwiegender ist als eine typische Software-Sicherheitslücke, liegt darin, dass LLMs nicht zuverlässig zwischen Anweisungen und Daten unterscheiden können. Jedes Token im Kontextfenster hat für das Modell den gleichen epistemischen Status – Ihre Systemprompt, die Frage des Benutzers, der Inhalt eines abgerufenen Dokuments und eine in einer E-Mail-Signatur versteckte böswillige Anweisung sind allesamt nur Text. OpenAI selbst hat dies öffentlich als ein grundlegendes Sicherheitsproblem anerkannt und nicht als einen Fehler, der gepatcht werden muss. [⁸] Kein noch so umfangreiches Training kann das Problem zuverlässig lösen, da es nicht im Training liegt, sondern in der Architektur dessen, was ein Sprachmodell im Grunde genommen ist.
Das ist kein Problem von Cass. Das ist ein Problem, das uns alle betrifft.
Das Fry-Experiment ist die anschauliche Darstellung eines Musters, das in den letzten zwölf Monaten wiederholt bei Produktionssystemen von Unternehmen nachgewiesen wurde. EchoLeak, das im Juni 2025 als CVE-2025-32711 mit einem CVSS-Schweregrad von 9,3 bekannt gegeben wurde, zeigte, dass eine einzige manipulierte E-Mail Microsoft 365 Copilot dazu veranlassen konnte, private Dokumente über eine unsichtbare Bild-URL zu exfiltrieren – ohne Klicks, ohne Benutzeraktion. [⁹] Das gleiche Muster der Exfiltration über Bild-URLs wurde anschließend an Gemini Enterprise demonstriert. Es wurde nachgewiesen, dass der MCP-Server von GitHub Daten aus privaten Repositorys preisgibt, wenn in öffentliche Issue-Kommentare Anweisungen mit Prompt-Injektion eingebettet wurden. Der Agent von Writer.com wurde über URL-Parameter ausgenutzt. ChatGPT Operator wurde über ein Browser-Automatisierungstool ausgenutzt. Der GitLab Duo Chatbot wurde über öffentliche Projektdateien ausgenutzt. Microsoft selbst gab im Februar 2026 einen zweiten Vorfall bekannt – separat erfasst als CW1226324 –, bei dem Copilot E-Mails mit vertraulichen Sensitivitätskennzeichnungen zusammenfasste, obwohl die Purview-Kontrollen aktiv waren. [¹⁰]
Diese Vorfälle haben eine gemeinsame zugrunde liegende Architektur, es handelt sich nicht um einen Zufall von Fehlern. In jedem Fall verfügte ein Agent über private Daten, nahm nicht vertrauenswürdige Inhalte auf und hatte einen Weg zur externen Kommunikation. Der Exploit war die vorhersehbare Folge.
Die Lieferkette ist der nächste große Trend
Was Frys Experiment nicht ans Licht brachte, was die breitere Sicherheitsforschungsgemeinschaft jedoch im April und Mai dokumentiert hat, ist, dass das Agent-Ökosystem mittlerweile ein Lieferkettenproblem aufweist, das mit dem von npm oder PyPI vergleichbar ist – und die meisten Unternehmen haben dies noch nicht bemerkt.
Zscaler ThreatLabz meldete Anfang dieses Monats eine bösartige „DeepSeek-Claw“-Funktion auf dem OpenClaw-Plugin-Marktplatz, die Installationsanweisungen enthielt, die darauf abzielten, einen Informationsdiebstahl-Agenten auf den Host zu übertragen. [¹¹] Bei einer umfassenderen Überprüfung stellten Forscher fest, dass etwa 12 Prozent der im OpenClaw ClawHub-Register veröffentlichten Skills – 341 von 2.857 – bösartig waren und sich auf ausgefeilte Dokumentationen und plausibel klingende Namen stützten. [¹¹] Das am 30. April 2026 veröffentlichte AIMap-Tool von Bishop Fox kartierte mehr als 175.000 öffentlich zugängliche Ollama-Instanzen und 8.000 offene MCP-Server, von denen viele einen nicht authentifizierten Tool-Zugriff ermöglichten. [¹²] SecurityScorecard hatte separat mehr als 40.000 im Internet exponierte OpenClaw-Instanzen identifiziert, von denen mehr als ein Drittel als anfällig gekennzeichnet war und eine Standardkonfiguration aufwies, die API-Schlüssel, OAuth-Token und Anmeldedaten in Klartextdateien in lokalen Verzeichnissen speichert. [¹³]
Für die Unternehmensarchitektur hat dies direkte Konsequenzen. Selbst wenn Ihr eigenes Agent-Design die tödliche Dreifachgefahr auf dem Papier vermeidet, sind die Fähigkeiten von Drittanbietern, Plugins und MCP-Server, mit denen Ihre Agenten verbunden sind, Teil der Vertrauensgrenze – und der größte Teil dieser Grenze ist heute fragil.
Warum Überwachung nicht die Lösung ist
In den letzten Wochen hat eine Welle von Markteinführungen neuer agentenbasierter Sicherheitsdienste den Markt überschwemmt. Cognizant kündigte am 7. Mai 2026 seine „Secure AI Services“ an, die auf „nachweisbarem Vertrauen“ und kontinuierlicher Laufzeitüberwachung basieren. [¹⁴] EY, Kyndryl, Sweet Security, Honeycomb und andere bringen ähnliche Angebote auf den Markt. Diese Produkte sind nützlich, und seriöse Unternehmen werden zumindest eines davon erwerben. Doch der Rahmen ist entscheidend. Ein Überwachungsdienst, der einen Agenten entdeckt, der etwas Falsches tut, hat es dem Agenten konstruktionsbedingt ermöglicht, sich in einer Position zu befinden, in der es möglich war, etwas Falsches zu tun. Die einzige strukturelle Verteidigung gegen die tödliche Dreifachbedrohung besteht darin, von vornherein zu verhindern, dass die drei Eigenschaften in einem einzigen Ausführungspfad gleichzeitig auftreten.
Dies ist keine hypothetische oder rein wissenschaftliche Position. Es ist mittlerweile die Konsensmeinung in der Literatur zur KI-Sicherheit. Die Constellation Foundation, das Promptfoo-Team, Oso, HiddenLayer und Willison selbst sind sich alle über dieselben drei architektonischen Abwehrmaßnahmen einig: Einschränkung des Datenzugriffs, Einschränkung der Exposition gegenüber nicht vertrauenswürdigen Inhalten oder Einschränkung der Exfiltrationsfähigkeit für jeden Agenten, der andernfalls über alle drei Eigenschaften verfügen würde. Erkennungsbasierte Abwehrmaßnahmen werden zusätzlich zu einer dieser strukturellen Entscheidungen eingesetzt, niemals als Ersatz dafür. [¹⁵]
Wie die Durchsetzung durch bauliche Maßnahmen in der Praxis aussieht
Drei Architekturmuster zeichnen sich als praktikable Lösung ab.
Aufteilung der Funktionen. Entwickeln Sie keinen einzigen Agenten, der alles kann. Teilen Sie die Arbeit auf mehrere Agenten auf, von denen jeder nur eine oder zwei der drei Eigenschaften der „Trifecta“ besitzt. Der Agent, der nicht vertrauenswürdige eingehende E-Mails verarbeitet, wird in einer Sandbox isoliert, fernab von jeglichem Speicher für Anmeldedaten. Der Agent mit Datenbankzugriff hat keinen Zugang zu externer Kommunikation. Der Agent, der externe APIs aufruft, erhält von den anderen nur bereinigte, strukturierte Datenübergaben. Dies ist schwieriger zu entwerfen und zu implementieren als ein einziger allwissender Agent, aber es ist das einzige Design, das strukturell gegen Prompt-Injection gewappnet ist.
Verbreitung von Verunreinigungen und Policy-Gating. Behandeln Sie den Kontakt mit nicht vertrauenswürdigen Inhalten als Verunreinigungsereignis. Sobald das Kontextfenster eines Agenten von einem vom Angreifer kontrollierbaren Text berührt wurde, markieren Sie den Ausführungspfad als „tainted“. Jede nachfolgende Aktion auf einem „tainted“ Pfad, die private Daten berühren oder externe Kommunikation durchführen würde, erfordert eine ausdrückliche menschliche Genehmigung oder wird blockiert. Dies ist das Äquivalent der Taint-Analyse aus der Web-Sicherheit der frühen 2000er Jahre im LLM-Zeitalter und ist deterministischer als jeder Klassifikator.
Tool-Metadaten als Richtlinie. Jedes Tool, das der Orchestrator aufrufen kann, ist mit einer Kennzeichnung versehen, die angibt, was es tut: reads_private_data, sees_untrusted_content, can_exfiltrate. Die Orchestrierungs-Laufzeitumgebung lehnt es ab, einen Ausführungspfad zusammenzustellen, der alle drei Kennzeichnungen in einer kompromittierten Sitzung kombiniert. Dadurch wird diese tödliche Dreierkombination zu einer Einschränkung, die von der Laufzeitumgebung durchgesetzt wird – und nicht durch das „gute Verhalten“ des Modells.
Allen diesen Mustern ist gemeinsam, dass sie eine Orchestrierungsschicht erfordern, die den gesamten Ausführungsgraphen der Agenten überblicken und die Richtlinie durchgehend durchsetzen kann. Ein einzelner isolierter Agent kann die Zerlegung nicht erzwingen. Eine nachträglich hinzugefügte Überwachungsschicht kann architektonische Entscheidungen nicht rückgängig machen. Die Orchestrierungsschicht ist der einzige Ort, an dem diese Einschränkungen gelten können, da sie die einzige Schicht ist, die weiß, was jeder Agent gleichzeitig tut.
Wo neuland.ai steht
Strukturell gesehen ist der neuland.ai HUB genau dafür ausgelegt. Der HUB fungiert als Koordinations- und Verwaltungsebene: Er verwaltet Identitäten und RBAC, steuert die Governance von Tool-Aufrufen, führt das Audit-Protokoll, wendet Ausgaberichtlinien an und – was entscheidend ist – abstrahiert Funktionen so, dass kein einzelner Agent jemals alle drei Aufgaben gleichzeitig übernehmen muss. Handler für nicht vertrauenswürdige Eingaben (Mailbox-Erfassung, Dokumentenanalyse, Webabruf) sind architektonisch von Handlern mit Anmeldedaten (CRM-Zugriff, ERP-Abfragen, SharePoint) getrennt, und beide unterscheiden sich von den Komponenten, die extern kommunizieren können. Die Laufzeitumgebung stellt Ausführungspfade gemäß den Richtlinien zusammen, nicht nach dem Ermessen des Modells.
Wir sind zudem bewusst hyperscaler-unabhängig. Kunden betreiben den HUB auf der Infrastruktur, die ihre Compliance-Anforderungen erfordern – vor Ort, in einer in der EU angesiedelten Private Cloud oder in einer Hyperscaler-Region, sofern die Arbeitslast dies tatsächlich zulässt. Die darunterliegende Modellschicht ist von Grund auf Multi-LLM ausgelegt. Nichts davon ändert etwas am Trifecta-Argument; das Trifecta ist eine Eigenschaft der Agentenarchitektur, nicht der Modellwahl oder der Hosting-Gerichtsbarkeit. Die Unabhängigkeit von Hyperscalern bedeutet jedoch, dass die Orchestrierungsschicht, die die Trifecta-Abwehrmaßnahmen durchsetzt, selbst unter der Kontrolle des Kunden und nicht des Anbieters steht. [¹⁶]
Was ich ganz klarstellen möchte, ist, dass der HUB keine „KI-Sicherheit“ ist. Er ist die architektonische Ebene, auf der agentische Systeme durchgesetzt werden können. Die Tatsache, dass dies auch das tödliche Dreigespann löst, ist eine Folge der Architektur und kein nachträglich hinzugefügtes Feature.
Persönliche Einschätzung
Wir befinden uns in einem engen Zeitfenster. Die meisten agentenbasierten Plattformen, die heute auf dem Markt sind, werden standardmäßig mit der tödlichen Dreifachgefahr ausgeliefert, denn der einfachste Weg, eine nützliche Demo zu erstellen, besteht darin, einem Agenten Zugriff auf alles zu gewähren. Die Demo funktioniert. Der Pilotversuch funktioniert. Der Produktionsbetrieb funktioniert – bis zu dem Tag, an dem ein Angreifer, der Hannah Frys Bericht gelesen hat, beschließt, eine gut ausgearbeitete E-Mail an jemanden in der Organisation zu senden, und dann funktioniert wieder nichts mehr, und zwar auf eine Weise, die es auf die Titelseite schafft.
Simon Willison sagt seit über einem Jahr öffentlich voraus, dass der erste große, durch eine „Lethal Trifecta“ ausgelöste Vorfall in Unternehmen nur eine Frage der Zeit ist – nicht des Ob. Die Voraussetzungen dafür häufen sich: 175.000 exponierte Ollama-Instanzen, 40.000 exponierte OpenClaw-Instanzen, 8.000 offene MCP-Server, eine Agent-Lieferkette, in der jede achte Funktion bösartig ist. Wenn der Vorfall eintritt, wird jeder Vorstand in Europa dieselben Fragen stellen. Wussten wir davon? Haben wir unsere Bereitstellungen darauf überprüft? Ist unsere Agent-Architektur anfällig? Die Organisationen, deren Orchestrierungsschicht von Grund auf eine Aufteilung der Funktionen erzwingt, werden mit Ja, Ja und Nein antworten. Die Organisationen, deren KI-Sicherheitsstrategie auf einem Überwachungsvertrag basiert, werden anders antworten.
Ein kurzer Hinweis zum regulatorischen Umfeld, da ich bereits in den beiden vorangegangenen Beiträgen dieser Reihe darauf eingegangen bin. Am 7. Mai 2026 wurde im Rahmen des Trilogs zum EU-Digital-Omnibus-Paket zur KI eine vorläufige politische Einigung erzielt, wonach die Verpflichtungen aus Anhang III für Produkte mit hohem Risiko vom 2. August 2026 auf den 2. Dezember 2027 und die Verpflichtungen aus Anhang I auf den 2. August 2028 verschoben werden. [¹⁷] Der Zeitplan für die Durchsetzung der GPAI bleibt unverändert. Die Wasserzeichenpflicht gemäß Artikel 50 Absatz 2 wird auf den 2. Dezember 2026 verschoben. Die strategische Konsequenz für KI-Käufer besteht nicht darin, dass die Dringlichkeit nachgelassen hat. Vielmehr hat sich der bindende Zwang von der behördlichen Kontrolle auf die Kontrolle durch den Käufer verlagert – und die Organisationen, die die zusätzlichen sechzehn Monate nutzen, um eine geeignete Architektur aufzubauen, werden auch 2028 noch die Ausschreibungen von Unternehmen für sich entscheiden.
Das tödliche Dreigespann wird nicht auf die EU warten. Die Entscheidung über die Architektur muss jetzt getroffen werden.
¹ Artikelserie verfügbar unter neuland.ai/insights.
² „Bedienoberflächen, Ausführungsumgebungen und das Ende der Prompt-First-Automatisierung“, neuland.ai, 19. Februar 2026.
³ „Wenn KI-Systeme plötzlich schlechter werden: Was Unternehmen wirklich aus der Claude-Code-Debatte lernen sollten“, neuland.ai, 17. April 2026.
⁴ „Offene Gewichte belegten den ersten Platz. Meta zog sich zurück. Die eigentliche Frage ist, wo diese Modelle tatsächlich laufen“, neuland.ai, April 2026.
⁵ „Compliance ist eine Systemeigenschaft, kein Ankreuzfeld: Was drei Wochen Copilot-Nachrichten darüber verraten, wie Unternehmen KI kaufen sollten“, neuland.ai, Mai 2026.
⁶ Simon Willison, „Die tödliche Dreifachkombination für KI-Agenten“, simonwillison.net, Juni 2025. Willison prägte bereits im September 2022 den Begriff „Prompt Injection“ und formalisierte damit Arbeiten, die ursprünglich von Riley Goodside beobachtet worden waren. Seit Mai 2026 ist „tödliche Dreifachkombination“ der Konsensbegriff in der KI-Sicherheitsforschungsgemeinschaft für die strukturelle Bedingung, die indirekte Prompt-Injection-Angriffe ermöglicht.
⁷ Die branchenüblichen Referenzwerte für die Erkennungsgenauigkeit bei Prompt-Injection liegen bei bekannten Angriffsmustern bei etwa 97 %; bei neuen Mustern verschlechtert sich die Erkennungsrate erheblich. Siehe Promptfoo, „Testing AI’s Lethal Trifecta“, September 2025; Constellation Foundation, „How to Detect Unsafe AI Agent Configurations“, April 2026.
⁸ Öffentliche Stellungnahme von OpenAI zu Prompt-Injection als einer der größten Sicherheitsherausforderungen; siehe auch Berichterstattung in The Economist und anderen Medien, September 2025.
⁹ Aim Security, EchoLeak-Offenlegung (CVE-2025-32711, CVSS 9.3), Juni 2025. Zero-Click-Exfiltration durch Prompt-Injection in Microsoft 365 Copilot über unsichtbare Bild-URL; behoben.
¹⁰ Dasselbe Muster wurde anschließend bei Gemini Enterprise demonstriert; Exfiltration öffentlicher Issues auf dem GitHub MCP-Server; Exfiltration von URL-Parametern bei Writer.com; Exfiltration über das Browser-Tool von ChatGPT Operator; Exfiltration öffentlicher Projekte des GitLab Duo Chatbots; Umgehung der Sensitivitätskennzeichnung bei Microsoft (CW1226324, Februar 2026, offengelegt durch einen Bericht von VentureBeat).
¹¹ Zscaler ThreatLabz, bösartige DeepSeek-Claw-Skills auf dem OpenClaw ClawHub-Marktplatz, Mai 2026. Überprüfung bösartiger Skills auf ClawHub: ~12 % der veröffentlichten Skills (341 von 2.857) wurden als bösartig eingestuft.
¹² Bishop Fox, öffentliche Veröffentlichung von AIMap, 30. April 2026. Über 175.000 exponierte Ollama-Instanzen, über 8.000 offene MCP-Server identifiziert, mit weitverbreitetem unauthentifiziertem Zugriff auf Tools.
¹³ SecurityScorecard-Untersuchung, OpenClaw-Expositionsdaten: Über 40.000 öffentlich erreichbare Instanzen, mehr als ein Drittel als anfällig markiert. Standardkonfiguration speichert API-Schlüssel, OAuth-Token und Anmeldedaten in lokalen Dateien im Klartext.
¹⁴ Pressemitteilung von Cognizant, „Cognizant Launches Secure AI Services to Help Enterprises Safely Scale Agentic Systems“, 7. Mai 2026. Siehe auch die Einführung von EYs agentischer KI für Assurance im Unternehmensmaßstab und die Positionierung der agentischen Azure-Managed-Services von Kyndryl, Mai 2026.
¹⁵ Zusammenfassende Literatur zu architektonischen Abhilfemaßnahmen: Simon Willison, „The lethal trifecta for AI agents“; HiddenLayer, „How the Lethal Trifecta Exposes Agentic AI“; Promptfoo, „Testing AI’s Lethal Trifecta“; Oso, „Understanding the Lethal Trifecta of AI Agents“; Constellation Foundation, „How to Detect Unsafe AI Agent Configurations“. Siehe auch: Beurer-Kellner et al., „Design Patterns for Securing LLM Agents against Prompt Injections“, 2025 (gemeinsame Veröffentlichung von IBM, Invariant Labs, ETH Zürich, Google und Microsoft).
¹⁶ Genannte Funktionen des neuland.ai HUB: Identitätsmanagement / RBAC / Prüfpfad / Funktionsabstraktion / Steuerung von Tool-Aufrufen / Multi-LLM-Routing / hyperscalerunabhängige Bereitstellung (vor Ort, private EU-Cloud, Hyperscaler-Region je nach Bedarf). Die neuland.ai AG trägt die Verantwortung für die Qualität der Inhalte und die fehlerfreie Bereitstellung der Ergebnisse.
¹⁷ Vorläufige politische Einigung des Rates der EU und des Europäischen Parlaments zum Digital Omnibus über KI, 7. Mai 2026. Verpflichtungen gemäß Anhang III für Bereiche mit hohem Risiko auf den 2. Dezember 2027 verschoben (16 Monate); Verpflichtungen gemäß Anhang I auf den 2. August 2028 verschoben (12 Monate); Artikel 50 Absatz 2 (Wasserzeichen) auf den 2. Dezember 2026 verschoben; neues Verbot von KI-generierten nicht einvernehmlichen intimen Darstellungen und CSAM. Durchsetzung der GPAI und Verpflichtungen aus Kapitel V unverändert. Endgültige Verabschiedung voraussichtlich vor dem 2. August 2026.