Nach Mythos: Ein praktischer Leitfaden zur KI Agent Sicherheit für KMU

Vor zwei Tagen hat Anthropic öffentlich gemacht, wozu ein neues, nicht öffentlich verfügbares Frontier-Modell in der Lage ist: Es hat in jedem grossen Betriebssystem und Web-Browser Tausende Zero-Day-Schwachstellen gefunden. Darunter eine 27 Jahre alte Sicherheitslücke in OpenBSD, die Jahrzehnte menschlicher Code-Reviews überdauert hatte, und ein 16 Jahre alter Bug in FFmpeg, den rund fünf Millionen automatisierte Testläufe nie gefunden haben.

Das Modell heisst Claude Mythos Preview. Anthropic hat es am 7. April 2026 im Rahmen von Project Glasswing vorgestellt. Ab diesem Moment ist KI Agent Sicherheit kein theoretisches Problem mehr, das nur Critical-Infrastructure-Teams kümmern muss. Es ist ein praktisches Problem für jeden, der im Unternehmen einen AI Agent laufen lässt.

Wenn Du eine Firma mit 10 bis 40 Mitarbeitenden führst und bereits einen AI Agent einsetzt – oder gerade einen einsetzen willst –, musst Du diese Woche eine Entscheidung treffen. Die Frage ist nicht "Muss ich jetzt Angst haben?" Die führt nirgendwohin. Die richtige Frage lautet: Steckt mein AI Agent in einem Vault, oder läuft er auf reiner Vertrauensbasis?

Dieser Artikel liefert Dir drei Dinge. Erstens eine verständliche Einordnung, was mit Mythos und Glasswing gerade passiert ist. Zweitens den 24-monatigen Vorlauf, der zeigt, dass das Ganze keine Überraschung ist. Und drittens das "Vault statt Vertrauen"-Playbook, mit dem wir bei TecMinds jeden AI Agent ausliefern, inklusive einer Fünf-Punkte-Checkliste, die Du am Montagmorgen direkt ins Team-Meeting mitnehmen kannst.

Wenn Du lieber Dein konkretes Setup durchsprechen willst, ist der kostenlose 30-minütige KI-Potenzial-Check der schnellste Weg.

Was gerade passiert ist: Claude Mythos und Project Glasswing, in einfachen Worten

Was ist Project Glasswing?

Project Glasswing ist eine Industrie-Initiative, die Anthropic am 7. April 2026 angekündigt hat, um kritische Infrastruktur gegen KI-gefundene Schwachstellen zu schützen. Sie gibt zwölf Launch-Partnern sowie über 40 weiteren Organisationen aus dem Critical-Infrastructure-Bereich Zugriff auf ein bislang unveröffentlichtes Frontier-Modell namens Claude Mythos Preview, gestützt auf 100 Mio. USD an Anthropic-Usage-Credits.

Die zwölf Launch-Partner sind AWS, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorganChase, die Linux Foundation, Microsoft, NVIDIA und Palo Alto Networks. Ergänzend spendet Anthropic 4 Mio. USD direkt an Open-Source-Sicherheitsorganisationen: 2,5 Mio. USD an Alpha-Omega und OpenSSF sowie 1,5 Mio. USD an die Apache Software Foundation.

Der Name spielt auf den Glasflügelfalter (Greta oto) an, dessen durchsichtige Flügel ihn vor Angreifern praktisch unsichtbar machen. Genau darum geht es: versteckte Schwachstellen, transparente Verteidigung.

Was ist Claude Mythos Preview?

Claude Mythos Preview ist ein unveröffentlichtes Frontier-KI-Modell, das Anthropic gezielt fürs Finden von Software-Schwachstellen gebaut hat. Anthropic hat es bewusst nicht allgemein verfügbar gemacht; der Zugang ist auf die Project-Glasswing-Partner beschränkt und läuft über die Claude API, Amazon Bedrock, Google Cloud Vertex AI oder Microsoft Foundry.

Auf den veröffentlichten Benchmarks liegt Mythos deutlich vor Claude Opus 4.6:

Was hat es konkret gefunden?

Laut der Claude Mythos Preview System Card hat das Modell bereits Tausende Zero-Day-Schwachstellen in jedem grossen Betriebssystem und Browser entdeckt. Anthropic nennt unter anderem:

• Eine 27 Jahre alte Remote-Crash-Lücke in OpenBSD
• Eine 16 Jahre alte Schwachstelle in FFmpeg, an der rund fünf Millionen automatisierte Testläufe vorbeigelaufen sind
• Privilege-Escalation-Ketten im Linux-Kernel
• Eine 17 Jahre alte Remote-Code-Execution-Lücke in FreeBSD (CVE-2026-4747), die Root-Zugriff über NFS erlaubt. Mythos hat sie autonom identifiziert und ausgenutzt, ohne menschliche Anleitung nach dem ersten Prompt.

Ein direktes Zitat aus der Anthropic-Ankündigung:

KI-Modelle haben inzwischen ein Coding-Niveau erreicht, auf dem sie praktisch alle Menschen ausser den bestqualifizierten beim Finden und Ausnutzen von Software-Schwachstellen übertreffen.

Bei diesem Satz solltest Du kurz innehalten.

Warum KI Agent Sicherheit kein reines Thema fürs Security-Team mehr ist

Wenn Du ein SOC betreibst, weisst Du längst, warum das wichtig ist. Interessant wird es bei einer 25-Personen-Firma, deren "Security-Team" aus einer Person besteht, die nebenbei auch IT und Onboarding macht.

Zwei Gründe, über die Du vermutlich noch nicht nachgedacht hast.

Der erste Grund ist Asymmetrie. Im Moment existieren Mythos-Fähigkeiten nur bei Anthropic und seinen über 40 freigeschalteten Partnern. Das Modell ist nicht öffentlich, die Gewichte sind nicht geleakt.

Aber Security-Researcher wie Simon Willison, dessen Einschätzung zu solchen Themen es wert ist, gelesen zu werden, rechnen mit rund sechs Monaten, bis Open-Weight-Modelle beim Bug-Finden aufgeholt haben. Sobald das passiert, können Angreifer mit derselben Fähigkeit neue Lücken in derselben Geschwindigkeit entdecken, mit der Verteidiger gerade 27 Jahre alte OpenBSD-Bugs patchen. Die Cloud Security Alliance nennt das die "Vulnpocalypse". Etwas dramatisch, aber nicht grundlos.

Der zweite Grund ist Dein eigener AI Agent. Und das ist der Teil, über den fast niemand schreibt.

Jeder AI Agent, den Du einsetzt, hat zwei Eigenschaften, die hier entscheidend sind:

1. Er hat Tools. Er ruft Deine APIs auf, liest Dateien, verschickt E-Mails, arbeitet im CRM, bewegt Geld.
2. Er hat eine Prompt-Oberfläche. Er verarbeitet Anweisungen von Menschen, manchmal von Menschen, denen Du nicht vertraust: einem Kunden, einer eingehenden Mail, einer gescrapten Webseite.

Zusammen ergibt das genau das System, das ein Angreifer mit Mythos-Fähigkeiten liebend gern erreichen würde. Nicht um das Modell anzugreifen, sondern um durch das Modell anzugreifen. Das Modell ist der Weg, Deine Tools sind das Ziel.

Stell Dir eine Recruiting-Firma mit 22 Mitarbeitenden vor, die einen "KI-Kandidatenassistenten" laufen hat: ein LLM-Agent, der eingehende Lebensläufe liest, sie mit den offenen Stellen abgleicht, Absage-Mails entwirft und das ATS aktualisiert. Genau so ein Setup haben wir dieses Jahr bei drei Firmen gesehen.

Der Agent hat Lesezugriff auf die Kandidatendatenbank, Schreibzugriff aufs ATS, Sende-Zugriff auf den Mailserver und einen Posteingang, über den Bewerber selbst Rückfragen und Ergänzungen zu ihrer Bewerbung einreichen können. Jedes dieser Elemente ist ein Tool, das das Modell aufrufen kann. Jedes dieser Elemente ist auch ein Tool, das ein Angreifer erreicht, sobald er Text in den Bewerber-Posteingang bringt.

Das Modell selbst ist nicht das Problem. Das Problem ist der Blast Radius.

Die Frage ist nicht "Kann ich Claude vertrauen?" Die Frage ist: Was ist der maximale Schaden, wenn mein AI Agent sich irrt, manipuliert wird oder kompromittiert ist? Wenn die Antwort "unklar" oder "viel" lautet, hast Du Arbeit vor Dir.

Das war keine Überraschung: Die 24-monatige Anlaufzeit

Mythos fühlt sich wie ein Schock an. Das sollte es nicht. Die Entwicklung, die KI Agent Sicherheit an diesen Punkt gebracht hat, ist seit zwei Jahren gut sichtbar.

Oktober 2024: Googles Big Sleep findet einen echten Bug in SQLite. Google Project Zero und DeepMind haben gemeinsam Project Naptime entwickelt, das später in Big Sleep umbenannt wurde. Ihr LLM-Agent fand einen Stack-Buffer-Underflow in SQLite, den sowohl OSS-Fuzz als auch die interne Test-Infrastruktur von SQLite übersehen hatten. Die Maintainer haben den Bug am selben Tag gefixt.

Gemeldet wurde er, bevor er in ein offizielles Release gelangt ist, also war kein SQLite-Nutzer betroffen. Aber es war das erste öffentliche Beispiel eines AI Agents, der einen bis dahin unbekannten, ausnutzbaren Memory-Safety-Bug in breit eingesetzter Open-Source-Software gefunden hat.

August 2025: Das Finale der DARPA AI Cyber Challenge. An der DEF CON traten sieben Teams gegeneinander an, um vollautomatische Systeme zu bauen, die Schwachstellen in Open-Source-Software finden und patchen können. Laut DARPA fanden die Teams 86 % der synthetisch eingebauten Schwachstellen und patchten davon 68 %.

Dabei entdeckten sie auch 18 bisher unbekannte reale Bugs. Die durchschnittliche Zeit von "gefunden" bis "gepatcht" lag bei 45 Minuten. Team Atlanta gewann 4 Mio. USD, Trail of Bits mit "Buttercup" 3 Mio. USD.

Anthropic, Google und OpenAI spendierten den Teilnehmern jeweils 350'000 USD an LLM-Credits, was bedeutet, dass die Modellanbieter direkt von den Gewinnermustern profitiert und mitgelernt haben.

April 2026: Mythos. Tausende Zero-Days in jahrzehntealtem Code, autonom entdeckt und in einigen Fällen autonom ausgenutzt. Das Muster wiederholt sich alle zwölf Monate: Was früher ein ganzes Research-Team gebraucht hat, passt heute in einen einzigen Prompt. Die nächsten zwölf Monate werden nicht langsamer sein. Sie werden schneller.

Das "Vault statt Vertrauen"-Playbook für KI Agent Sicherheit

So arbeiten wir bei TecMinds bei jedem AI Agent, den wir ausliefern. Dieses Framework ist nicht als Reaktion auf Mythos entstanden. Wir bauen so, seit bevor Project Glasswing überhaupt existierte, weil es die richtige Architektur für jedes System ist, dessen Verhalten nicht von deterministischem Code, sondern von einem Sprachmodell geformt wird. Nach Mythos ist es schlicht der einzige vertretbare Default.

Warum "Vertrauen und später prüfen" bei AI Agents scheitert

Klassische Software ist eingegrenzt. Eine Funktion nimmt bekannte Inputs, liefert bekannte Outputs, hat einen bekannten Fehlermodus. Du kannst ihr vertrauen und später prüfen, weil die Menge dessen, was sie überhaupt tun kann, endlich ist, und weil Du sie selbst geschrieben hast.

Ein AI Agent funktioniert anders. Seine möglichen Aktionen sind alles, was Du ihm an Tools in die Hand gibst, interpretiert durch ein Modell, dessen nächsten Output Du nicht vorhersagen kannst. Ein mächtiges Modell plus ein breites Toolset plus ein mehrdeutiger Prompt ergeben einen undefinierten Blast Radius. Und gegen "undefiniert" hilft kein Audit.

Deshalb kehren wir den Default um. Wir fragen nicht "Kann ich diesem Modell vertrauen?" Wir fragen: Was ist der maximale Schaden, wenn das Modell sich irrt, und wie halten wir diesen Schaden klein? Die Antwort ist ein Vault.

Die fünf AI Agent Guardrails, die jedes Deployment braucht

Diese fünf Kontrollen sind die Mindestanforderung an KI Agent Sicherheit im produktiven Betrieb. Lässt Du eine davon weg, werden alle anderen schwächer.

1. Least-Privilege-Tool-Zugriff. Starte mit null Tools und füge sie einzeln hinzu. Für jedes Tool schreibst Du die Antwort auf die Frage auf: "Was ist das Schlimmste, das passieren kann, wenn es falsch aufgerufen wird?" Kannst Du diesen Satz nicht zu Ende bringen, ist das Tool noch nicht bereit.

2. Scoped Secrets. API-Keys sind auf eine einzige Integration beschränkt, rotieren nach Zeitplan und landen nie im Kontextfenster des Modells. Das Tool hält das Secret, das Modell ruft nur das Tool auf. Dein Stripe-Key kommt nie in die Nähe eines Prompts.

3. Ein deterministischer Policy-Layer. Zwischen Modell und Tool sitzt eine Regel-Engine, mit der das Modell nicht verhandeln kann. Das Modell will CHF 10'000 überweisen, die Policy sagt "alles über CHF 1'000 braucht Freigabe", die Anfrage wird abgewiesen, bevor das Tool überhaupt anläuft. Das ist Code, kein weiteres LLM. Code halluziniert nicht, und Code lässt sich nicht aus seiner Rolle herausreden.

4. Human-in-the-Loop für destruktive Aktionen. Jede Aktion, die schreibt, verschickt, löscht oder Geld ausgibt, läuft über einen Menschen. Keine Toast-Benachrichtigung, sondern ein echtes Gate, das die Aktion blockiert, bis jemand ausdrücklich freigibt. Das ist kein Feature, das wir nachträglich einbauen, es ist, wie wir von Anfang an architektonisch arbeiten. Unser Ansatz für den AI-Agent-Bau nennt das "Human in the Loop, by Design." Und es ist auch die ehrliche Antwort auf die Frage "Was, wenn es halluziniert?" Wenn eine Halluzination im schlimmsten Fall nur etwas vorschlägt, das ein Mensch dann ablehnt, wird Halluzination zum Nicht-Thema.

5. Vollständiges Audit-Trail plus Kill-Switch. Jeder Prompt, jeder Tool-Call, jede Antwort, jede Entscheidung: geloggt, mit Zeitstempel, abspielbar. Dazu ein Knopf, der den gesamten Agent offline nimmt. Ohne Audit-Trail kannst Du die Frage "Was hat der Agent gestern eigentlich gemacht?" nicht beantworten. Ohne Kill-Switch kannst Du ihn nicht stoppen.

Wie ein Vault in der Praxis aussieht

Echte Abschirmung, nicht nur gute Absichten:

• Egress-Whitelist fürs Netzwerk. Der Agent erreicht nur die APIs, die Du explizit freigegeben hast. Kein allgemeiner Internetzugang, ausser Du hast eine bestimmte Domain ausdrücklich zugelassen.
• Memory-Isolation. Kein gemeinsamer Kontext zwischen Nutzern oder Mandanten. Die Mail von Kunde A landet nie in der Session von Kunde B.
• Rate-Limits pro Tool. Unbegrenzte Schleifen sind die zuverlässigste Methode, mit einem Agent Geld zu verbrennen und Systeme zu beschädigen. Jeder Tool-Call hat eine harte Obergrenze.
• Schema-validierte Tool-Outputs. Das Modell gibt strukturierte Daten zurück, die einem Schema entsprechen, nicht Freitext, der dann in der Hoffnung weiterverarbeitet wird, dass schon irgendetwas Sinnvolles dabei herauskommt.
• Sandboxed Code Execution. Jeder Code, den das Modell schreibt, läuft in einer isolierten Umgebung, die Produktion nicht erreicht.

Nichts davon ist exotisch. Es sind dieselben Prinzipien, die für jeden nicht vertrauenswürdigen Code gelten, der in Deiner Infrastruktur läuft. Der einzige Unterschied: Der "nicht vertrauenswürdige Code" ist jetzt ein LLM, das Anweisungen in natürlicher Sprache produziert, und zu den Leuten, die diese Anweisungen liefern, gehört jeder, der Deinem Customer-Support-Agent eine Mail schreibt.

Ein konkretes Beispiel

Stell Dir eine typische Rechnungsverarbeitungs-Pipeline für ein Schweizer KMU mit rund 25 Mitarbeitenden vor. Vorher: eine Person, drei Stunden pro Tag, rund 50 PDF-Rechnungen, etwa 5 % Fehlerquote. Nachher, mit einer sauber gebauten Vault-Architektur: unter zwei Sekunden pro Rechnung, Fehlerquote unter 0,1 %, eine Person übernimmt nur noch die Exception-Queue von rund sechs Rechnungen pro Woche.

Der Teil, der in solchen Diskussionen oft untergeht: Der Agent fasst das ERP nicht direkt an. Jede extrahierte Rechnung wird gegen ein Schema validiert, jede Zahlungsentscheidung über CHF 1'000 geht an einen menschlichen Freigeber, jeder Call wird geloggt, und das Ganze hat einen Kill-Switch, den die Finanzverantwortliche vom Handy aus auslösen kann.

So ein Setup baut man aus Gründen der Zuverlässigkeit, nicht wegen Mythos. Und genau deshalb müssten Vault-Architekturen nach Mythos auch nicht umgeschrieben werden – sie sind für diese Art von Bedrohung bereits gerüstet.

Die ehrlichen Grenzen

Guardrails stoppen Prompt Injection nicht. Sie begrenzen den Blast Radius, wenn eine Injection durchkommt.

Kein Vault verhindert, dass ein Modell falsch liegt. Er verhindert, dass ein falsch liegendes Modell destruktiv wird.

Human-in-the-Loop macht den Durchsatz langsamer. Das ist der Sinn der Sache, und es ist den Preis wert.

Diese Architektur schützt Dich nicht vor einem kompromittierten Modellanbieter. Das ist ein anderes Threat Model, und die Antwort darauf ist Anbieterauswahl und vertragliche Absicherung, nicht Agent-Design.

Wer diese Liste liest und denkt "das ist viel Arbeit": Ja. Es ist auch der Grund, warum unsere Deployments in Wochen statt in Quartalen live gehen. Die Guardrails sind der langweilige, verlässliche Teil. Der clevere Teil ist, den richtigen Workflow zum Automatisieren auszuwählen.

Was Du diese Woche tun kannst

Das ist der Teil, den Du Montagmorgen direkt ins Team-Meeting mitnehmen kannst.

Wenn Du schon einen AI Agent in Produktion hast

• Inventarisiere jedes Tool, das der Agent aufrufen kann. Mach wortwörtlich eine Liste.
• Schreibe für jedes Tool einen Satz auf: "Worst Case, wenn das Modell es missbraucht." Kannst Du den Satz nicht formulieren, gehört das Tool erstmal raus.
• Identifiziere jede destruktive Aktion und leite sie über einen menschlichen Freigabeschritt. Selbst eine Slack-Nachricht mit Approve/Reject-Buttons ist ein valider Anfang.
• Schalte vollständiges Prompt- und Tool-Call-Logging ein, falls noch nicht aktiv. Was Du nicht aufgezeichnet hast, kannst Du hinterher nicht untersuchen.
• Richte einen Kill-Switch ein. Eine einzige Konfig-Änderung, die den Agent stoppt. Und teste ihn.

Nimm ein Szenario, wie es in einem KMU heute realistisch entstehen kann: Eine Logistikfirma mit rund 30 Mitarbeitenden hat drei Monate zuvor einen "Customer-Support-AI" eingeführt. Der Agent hat Lesezugriff auf die komplette Kundendatenbank und Schreibrechte, um Bestellungen zu ändern. Mit ungefähr drei Wochen Vault-Arbeit – ohne Rebuild – liesse sich der Blast Radius auf "Read-Only-Lookup mit menschlicher Freigabe für jede Statusänderung" zurückführen.

Gleicher Workflow, gleiche User Experience, rund 98 % des Geschwindigkeitsgewinns, ungefähr 2 % des Risikos. Das ist das Vorher-Nachher-Muster, das bestehende Deployments realistisch erreichen können.

Wenn Du gerade einen AI-Anbieter evaluierst

Lass Dir die Vault-Architektur beschreiben, die konkreten Kontrollen, nicht den Werbesatz "unser Modell ist sicher". Frag, was passiert, wenn das Modell etwas ausserhalb der Policy versucht. Bitte um einen Export des Audit-Trails. Frag nach der Responsible-Disclosure-Policy für Bugs, die das Modell findet.

Lautet die Antwort auf eine dieser Fragen "das regelt das Modell" oder "das ist auf Modell-Ebene gelöst", beendest Du das Gespräch. Das ist die Antwort eines Anbieters, der das Problem entweder nicht verstanden hat oder die Engineering-Arbeit für eine saubere Lösung scheut. Beides disqualifiziert. Unser Beratungs- und Projektteam macht solche Vendor-Reviews regelmässig, und das ist mit Abstand das häufigste Fehlermuster.

Wenn Du noch nicht angefangen hast

Gut. Du kannst von Tag eins auf der richtigen Architektur aufbauen, statt später unter Druck refaktorieren zu müssen.

Der schnellste Weg zum passenden Startworkflow und dem richtigen Vault drumherum ist unser kostenloser 30-minütiger KI-Potenzial-Check. Du bringst einen Workflow mit, den Du automatisieren willst, und gehst mit einer einseitigen Architekturskizze heraus, plus einem klaren Ja oder Nein dazu, ob dieser Workflow von Tag eins hinter einen Vault gehört.

→ Buche Deinen KI-Potenzial-Check (30 Minuten, unverbindlich, kein Sales-Skript).

Nach Mythos sind Vaults der einzige Default

Claude Mythos Preview hat gerade Tausende Zero-Days in Code gefunden, der Jahrzehnte menschlicher Reviews überdauert hat. Open-Weight-Parität ist rund sechs Monate entfernt. In der Zwischenzeit verändert dieselbe Entwicklung das Threat Model jedes AI Agents, der in einem normalen Unternehmen läuft, nicht als Angreifer, sondern als Angriffsfläche.

Nichts davon verlangt Panik. Es verlangt eine Entscheidung über Defaults.

Der Default der letzten zwei Jahre war: Agent ausrollen, nötige Tools dranhängen, dem Modell vertrauen, später auditieren. Dieser Default hat immer auf geborgter Zeit gestanden. Jetzt ist die Zeit abgelaufen.

Der neue Default, den wir bei TecMinds schon vor Glasswing eingeführt haben, ist Vault zuerst und Capability danach. Least Privilege, deterministischer Policy-Layer, Human-in-the-Loop für alles Destruktive, vollständiges Audit-Trail, Kill-Switch von Tag eins an.

Die Arbeit ist nicht glamourös. Sie ist der Grund, warum unsere Deployments in Wochen live gehen und live bleiben. Und sie ist auch der Grund, warum wir unsere Architektur nach Mythos diese Woche nicht umbauen müssen. Das solltest Du auch nicht müssen.

Wenn Du durchsprechen willst, was KI Agent Sicherheit für Deinen konkreten Workflow bedeutet, ist der KI-Potenzial-Check 30 kostenlose Minuten, die mit einem einseitigen Plan enden. Bring Dein aktuelles Setup mit, Deine Vorstellung vom nächsten Schritt, und jede ehrliche Frage, die Du bisher nicht beantworten konntest. Den Vault liefern wir.

---

Zuletzt aktualisiert: 9. April 2026. KI-Fähigkeiten entwickeln sich schnell; dieser Artikel wird aktualisiert, sobald Anthropic weitere Details zu Project Glasswing veröffentlicht und sobald Open-Weight-Modelle beim Bug-Finden aufgeholt haben.