Anthropic’s «Claude Mythos»: Was CISOs jetzt im Threat Model anpassen

Am 7. April 2026 kündigte Anthropic mit «Claude Mythos Preview» ein neues KI-Modell an. Parallel dazu entstand mit Project Glasswing ein exklusives Konsortium ausgewählter Technologie- und Infrastrukturanbieter mit Zugang für defensive Sicherheitsarbeit. Während US-Finanzminister und Fed-Chef intern gebrieft wurden, äusserte der IWF öffentlich Zweifel an der Verteidigungsfähigkeit des globalen Finanzsystems. Auch deutsche Banken suchten umgehend den Schulterschluss mit ihren Aufsichtsbehörden.

Die Reaktionen in der Security-Community reichen seither von «AGI ist da» bis «reines PR-Theater». Für CISOs taugt beides nicht: Wer in Panik verfällt, trifft teure Fehlentscheidungen. Wer abwinkt, verpasst einen realen Shift im Threat Model.

Was «Claude Mythos» ist – und was es nicht

Die Ankündigung liest sich zunächst wie ein Paradigmenwechsel: «Claude Mythos» soll eigenständig tausende Zero-Day-Schwachstellen in grossen Betriebssystemen und Browsern identifiziert haben – darunter ein 27 Jahre alter Bug in OpenBSD, einem der sichersten Systeme der Branche. 99 % dieser Schwachstellen waren zum Zeitpunkt der Veröffentlichung ungepatcht. Das UK AI Security Institute (AISI) bestätigte zudem eine Erfolgsrate von 73 % bei Expert-Level-Hacking-Aufgaben. Gleichzeitig ist Mythos das erste Modell, dessen Veröffentlichung primär aus Cybersecurity-Gründen zurückgehalten wird.

Das ist jedoch erst eine Hälfte der Geschichte. So geht die Geschichte weiter:

AISI weist selbst darauf hin, dass Mythos in den Testszenarien gegen nahezu nicht vorhandene Verteidigungsebenen antrat. Der Vergleich eines AISI-Gutachters ist entsprechend pointiert: ein Stürmer gegen den schlechtesten Torhüter der Welt. Im produktiven Enterprise-Kontext sieht das Setup anders aus. Auch die auf KI-gestützte Schwachstellenforschung spezialisierte Organisation AISLE relativiert die öffentliche Erzählung: Sie hat die von Anthropic veröffentlichten Mythos-Findings gegen kleine, günstige Open-Weight-Modelle gegengeprüft. Acht von acht getesteten Modellen entdeckten den FreeBSD-Flagship-Exploit, den Anthropic als Beleg für die Überlegenheit von Mythos präsentierte. Eines dieser Modelle verfügt über 3,6 Mrd. aktive Parameter und kostet rund 0,11 USD pro Million Tokens.

Auch aus der Forschung kommt Einordnung. Peter Swire, Professor an der Georgia Tech und früherer Berater der Clinton- und Obama-Administrationen, beschreibt den Release nach Gesprächen mit akademischen Kolleg:innen nicht als Zäsur, sondern als Fortsetzung eines erwartbaren Trends. Zugleich weist er darauf hin, dass auch CISOs und Security-Vendors einen rationalen Anreiz haben, die Tragweite neuer Capabilities zu überzeichnen – nicht zuletzt zur Rechtfertigung eigener Budgets.

Die nüchterne Zusammenfassung lautet deshalb: Mythos ist leistungsfähig und eine ernstzunehmende Capability. Für ein verändertes Threat Model ist aber nicht die reine Fähigkeit entscheidend – die gab es in Teilen bereits. Relevant ist die Kombination aus Zugänglichkeit, Geschwindigkeit, Skalierung und der parallel laufenden Demokratisierung vergleichbarer Fähigkeiten in Open-Weight-Modellen.

Das ist der Shift, über den wir reden müssen. Nicht: «KI kann jetzt hacken.» Sondern: KI-gestützte Offensiv-Capability nimmt Commodity-Trajectory an. 

Was sich am Threat Model real verändert: Diese Grundannahmen sind zu prüfen

Vier Dimensionen, in denen der CISO seine Grundannahmen prüfen sollte.

1. Time-to-Exploit kollabiert
   Die klassische Annahme, dass zwischen Disclosure und weaponisiertem Exploit-Code Wochen bis Monate liegen, ist nicht mehr tragfähig. PwC formuliert es im jüngsten Threat-Report so: KI-gestützte Angreifer verkürzen Attack-Timelines und skalieren Operationen gleichzeitig. Für die Risk-Quantifizierung heisst das: Exposure-Fenster sind tendenziell kürzer als die Patch-Fenster der Hersteller.
2. Low-Skill-Enablement
   Der gravierendste Effekt ist nicht, dass APT-Gruppen besser werden – die sind es ohnehin. Entscheidend ist vielmehr, dass mittelmässige Angreifer deutlich gefährlicher werden. Ein Ransomware-Affiliate ohne tiefe OS-Kenntnisse kann künftig strukturiert nach Exploit-Chains suchen, statt ausschliesslich auf gekaufte Exploits angewiesen zu sein. Das verschiebt die Verteilung der realen Bedrohung messbar nach oben – und zwar genau im Segment, das für mittelständische Unternehmen am häufigsten relevant ist.
3. Skalierung und Breite
   Mythos hat im Test laut Anthropic tausende Findings parallel produziert. Selbst wenn nur ein Bruchteil davon in reale Exploits überführbar ist, verändert das die Annahmen über «gleichzeitig aktive Vulns». Klassisches Vulnerability-Management geht davon aus, dass man priorisieren kann, weil man weiss, welche Schwachstellen aktiv ausgenutzt werden. Signale wie CISA KEV und EPSS werden verrauschter (unzuverlässiger), je mehr parallel entdeckte Zero-Days in den Umlauf kommen.
4. Asymmetrie in Glasswing
   Das Programm ist nicht neutral. Ausgewählte Unternehmen, darunter JPMorgan Chase, Goldman Sachs und einige Cloud-/OS-Vendor, bekommen Mythos-Zugang für defensive Zwecke. Der Rest der Wirtschaft bekommt ihn nicht. Gleichzeitig ist keineswegs garantiert, dass Angreifer kein vergleichbares Tooling beschaffen können; die AISLE-Findings zu Open-Weight-Modellen zeigen, dass Teile der Capability bereits ausserhalb kontrollierter Kanäle existieren. Für mittelständische und kleinere Unternehmen – den typischen Kunden eines europäischen IR-Teams – verschiebt sich die Asymmetrie zu Ungunsten der Verteidigung.

Mythos ist weder Revolution noch PR-Theater, sondern ein klares Signal: KI-gestützte Offensiv-Capabilities werden zur Commodity – und das bestehende Threat Model gehört jetzt geschärft. Entscheidend ist nicht ein neues Tool, sondern die ehrliche Überprüfung der eigenen Annahmen – im Betrieb, in der Priorisierung und im Austausch mit dem Vorstand.

Threat Modeling

Risk Quantification: Must-have-Anpassung im Threat-Modell

Wer mit FAIR, Cyber-Risk-Quantifizierung oder Heatmap-Ansätzen arbeitet, muss drei Parameter überarbeiten.

Probability of Successful Compromise pro Asset-Klasse. Die Prios auf ältere, wenig gepflegte Systeme (ICS/OT, Legacy-Web-Anwendungen, interne Java-Backends, Delphi-Tools aus den späten Neunzigern, vergessene VB6-Anwendungen) steigen überproportional. Ein 27-Jahre-Bug in OpenBSD ist kein Einzelfall, sondern ein Proof-of-Concept für das, was in jedem Enterprise-COBOL-Stack und jeder halb-vergessenen internen Anwendung latent schlummert. Legacy-Risiko, das drei Jahrzehnte unterhalb der Realisierungsschwelle lag, rückt in Reichweite plausibler Angreifer.

Time-to-Detect versus Time-to-Exploit. Viele Organisationen operieren mit MTTD-Werten von Tagen bis Wochen. Wenn Time-to-Exploit auf Stunden kollabiert, ist das Delta das eigentliche Risiko. Die Kennzahl, die ab sofort getrackt wird, ist nicht MTTD per se, sondern MTTD minus geschätzte TTE – negative Werte sind rote Flaggen und gehören ins Board-Reporting.

Patch-SLA-Modelle. Klassische 30/60/90-Tage-Fenster wurden in einer Welt entworfen, in der Disclosure-zu-Exploit im Median mehrere Wochen brauchte. Dieses Modell braucht entweder deutlich schärfere Tiers für «critical exposed assets» oder eine Erweiterung um eine Compensating-Controls-Dimension: Virtual Patching, WAF-Rules, Netzsegmentierung als zeitkritische Zwischenmassnahme, nicht als Option.

Konkret für die Quantifizierung:

• CVSS-Base allein reicht nicht mehr; EPSS-Score plus Exposure-Kontext wird zur Standardschicht.
• Für Risk-Akzeptanz-Entscheidungen zu nicht gepatchten Systemen ist eine explizite Angabe der kompensierenden Controls notwendig. Eine Management-Unterschrift reicht nicht mehr aus.
• Threat-Modeling-Sessions führen «AI-enabled attacker» als Standard-Threat-Actor, nicht als Sonderfall.

SOC und IR-Operations: Was sich im Alltag ändert

Hier wird es konkret – und für IR-Teams am relevantesten.

1. Signatur-basierte Erkennung verliert weiter an Gewicht
   Das ist kein neuer Trend, aber er beschleunigt sich. Wenn ein Angreifer mit minimalem Aufwand funktional äquivalente, aber IOC-freie Varianten bekannter Malware-Familien generieren kann, ist Signatur-Detection primär noch für Noise-Reduction tauglich. Investitionen sollten sich auf Verhaltensdetektion (EDR-Behavioral, UEBA), Abuse-of-Legitimate-Tools-Pattern (Living-off-the-Land) und Anomaly-Detection im Netzwerk- und Identity-Layer verschieben.
2. Alert-Triage muss maschinell assistiert werden
   Wenn die Angreiferseite KI-gestützt skaliert, kann die Verteidigerseite das nicht manuell ausgleichen. Konkret: LLM-gestützte First-Line-Triage, die Alert-Cluster bildet, Kontext anreichert (Asset, Owner, letzte Änderungen, historische False Positives) und Priorisierungs-Vorschläge macht. Das ist keine Ablösung von Analyst:innen, sondern eine Verlagerung ihrer Arbeit – weg von «was ist das?» hin zu «stimmt die Hypothese, und was ist das Playbook?».

   Zwei architektonische Entscheidungen gehören direkt mit auf den Tisch.

   ▪️Deployment-Modell. Der LLM-Layer im SOC braucht ein sauberes Deployment. On-Prem oder dedicated-tenant, mit klaren Data-Boundaries. Alert-Daten sind privilegiert; sie gehören nicht in einen generischen Cloud-LLM-Endpunkt.

   ▪️Model Drift als operatives Risiko. Wer LLM-gestützte Detection oder Triage einsetzt, erbt ein Problem, das in klassischen Detection-Engineering-Lehrbüchern nicht vorkommt: Frontier-Modelle hinter APIs verändern ihr Verhalten auf identischen Inputs lautlos und ohne Changelog. Thresholds, die gegen eine bestimmte Confidence-Verteilung kalibriert wurden, wandern unter dem eigenen Dashboard weg – stille Erhöhung der False-Negative-Rate, ohne dass irgendwo eine Version gebumpt wäre.

   Selbst self-hosted Stacks sind nicht immun: ein vLLM-Update, eine neue Quantisierung oder ein subtiler Tokenizer-Change verschiebt Outputs messbar, ohne dass jemand eine Änderung geflaggt hat. Für detection-kritische Workloads ist deshalb ein gepinntes lokales Modell häufig die operativ bessere Wahl als das stärkste Frontier-Modell: reproduzierbar, auditierbar, immun gegen silent Updates.

   Für die eigentliche Analyst:innen-Arbeit (Zusammenfassungen, Hypothesenbildung, Client-Kommunikation) bleibt das Frontier-Modell sinnvoll. Diesen Split zwischen maschinenseitiger Entscheidung (lokal, gepinnt) und menschenzugewandter Generierung (frontier, drift-tolerant) samt Monitoring-Werkzeugkasten – Golden Corpus, PSI/JS-Divergence, Refusal-Rate-Tracking – habe ich an anderer Stelle ausführlicher beschrieben: Your AI Detections Are Rotting: Model Drift as a Hidden Risk in Security Operations.
   Die regulatorische Pointe dort ist hier noch wichtiger: Unter NIS2 und DORA ist ein LLM, dessen Verhalten man nicht festhalten kann, eine Compliance-Schuld, keine Capability.

   Das ist der Punkt, an dem der Mythos-Reflex «wir brauchen jetzt mehr KI im SOC» in die Irre führen kann. Mehr KI ohne Drift-Monitoring erzeugt das nächste Blind-Spot-Problem – nur jetzt mit hübscherem UI.

3. IR-Playbooks: Zero-Day-Assumption als Default
   Die klassische Trennung zwischen «bekannte Schwachstelle, Standardplaybook» und «Zero-Day, eskaliere an Senior-Responder» erodiert. Wenn Angreifer häufiger Zero-Days im Portfolio haben – weil das Finden billiger geworden ist – muss das Standardplaybook mit dieser Möglichkeit rechnen.
   Konkret:
   ▪️  Erst-Hypothese im Major-Incident: «unbekannter Initial Access Vector» bekommt mehr Gewicht, bevor sie abgeräumt wird.
   ▪️  Forensik-Preservation wird früher getriggert, auch wenn die Incident-Klassifikation noch unsicher ist.
   ▪️  Tabletop-Exercises führen «AI-enabled adversary» als Standard-Szenario, nicht als Spezialübung. In unseren Hybrid Crisis Simulations sehen wir, dass dieser Szenario-Typ bisher häufig als Sonderfall behandelt wird. Das Timing, ihn zu normalisieren, ist jetzt.
4. Threat Hunting proaktiv auf Legacy-Assets
   Wenn Mythos-Klassen-Tooling in Angreiferhand ist, verschiebt sich die Hunting-Priorität auf Assets, bei denen bislang «zu alt, zu langweilig für einen Attacker» angenommen wurde. Die proprietäre Inhouse-Anwendung aus 2007, die seit zwei CISO-Generationen «eigentlich abzulösen» ist, wird zum plausiblen Initial-Access-Vektor. Hunting-Hypothesen sind entsprechend zu priorisieren.

Proaktives Threat Hunting

Patch- und Vulnerability-Management: Der eigentliche Schmerzpunkt

Dieser Bereich ändert sich am stärksten, weil er am stärksten auf den alten Annahmen gebaut war.

1. Exposure Management ersetzt Vulnerability Management
   Die Branche redet seit Jahren davon, der Mythos-Moment beschleunigt es. Vulnerability-Management fragt: welche CVEs betreffen mich? Exposure-Management fragt: welche Angriffspfade sind realistisch nutzbar, und wo ist meine Verteidigung am schwächsten? Für die zweite Frage braucht es Attack-Path-Analyse, reachability-aware SCA und kontinuierliche External-Attack-Surface-Management-Capabilities (EASM).
2. Virtual Patching wird Default, nicht Option
   Wenn Patch-Zyklen des Herstellers länger brauchen als die Exploit-Entwicklung, muss die Lücke überbrückbar sein. WAFs, IPS, Deception-Tech, Netzsegmentierung und Micro-Perimeter-Policies sind nicht länger «nice to have». Für kritische Assets muss eine Compensating-Control im Werkzeugkasten sein, die schneller aktivierbar ist, als der Vendor patchen kann. Das ist ein architektonischer Punkt, kein Tooling-Punkt – und er muss vor dem nächsten grossen Zero-Day geklärt sein, nicht während.
3. SBOM plus VEX: Von Compliance zu Operations
   SBOMs waren in vielen Organisationen bislang ein Compliance-Artefakt – für EU Cyber Resilience Act, Executive Order 14028 oder Sektorregulierungen. Nach Mythos ist die operative Frage: wie schnell kann ich eine neu disclosed Library-Vulnerability in meinem gesamten Software-Portfolio lokalisieren? Ohne SBOM: Tage bis Wochen. Mit SBOM plus VEX (Vulnerability Exploitability eXchange): Minuten. Diese Geschwindigkeitsdifferenz entscheidet künftig über Incident-Kosten.
4. Priorisierung umbauen
   Die typische Frage «welche Critical-CVEs muss ich diese Woche patchen?» wird ersetzt durch «welche Kombinationen aus Exposure, Exploitability und Business-Impact haben aktuell das schlechteste Risk-Profil?». CISA KEV, EPSS und exposure-aware Scoring werden zur Standardschicht. Monatsbasierte Patch-Boards reichen nicht mehr; Patch- und Mitigation-Entscheidungen werden zu einem kontinuierlichen Prozess mit wenigen klar priorisierten Eskalationspfaden.

Vendor- und Supply-Chain-Strategie

Hier liegt einer der unangenehmsten Effekte. Glasswing schafft eine Zwei-Klassen-Wirtschaft.

1. Vendor Due Diligence: Neue Fragen
   Lieferanten-Fragebögen brauchen neue Punkte:
   ▪️Nutzt der Vendor KI-gestützte Security-Analyse in der eigenen Entwicklung? Seit wann? Welche Coverage (Code, Dependencies, Build-Pipeline)? 
   ▪️Gibt es SBOMs für alle bezogenen Produkte und Versionen? In welchem Format (SPDX, CycloneDX)? 
   ▪️Existieren VEX-Statements für bekannte CVEs? 
   ▪️Time-to-Patch-SLA für Critical-Findings, die durch automatisierte Analyse entdeckt werden? 
   ▪️Für kritische Vendors: Teilnahme an Programmen vom Glasswing-Typ oder vergleichbare AI-assisted-defense-Capability? Wenn nein – warum nicht, und welche Alternative bietet sich an? 
2. Konzentrationsrisiko wird sichtbar
   Glasswing-Partner sind bei Anthropic namentlich gelistet. Für europäische Unternehmen ist die operative Frage: wie viel des eigenen Risiko-Stacks hängt an Vendors mit dieser Capability, versus an Vendors ohne? Das ist kein moralisches Argument, sondern ein Risiko-Argument: Defensive-AI-Capability wird Teil der Vendor-Risikobewertung.
3. Regulatorische Hebel nutzen
   Für den DACH-Raum relevant: NIS2 (EU-weit), DORA (Finanzsektor), CRA (Produkt-Security) und in Österreich das NISG 2024 bieten bereits heute Hebel, um von kritischen Lieferanten strukturierte Antworten zu diesen Fragen einzufordern. Die Werkzeuge existieren; sie müssen nur auf die neue Bedrohungslage geschärft werden. Wer CRA-Anforderungen bislang als Compliance-Kosten gesehen hat, sollte sie nun als Risk-Mitigation-Hebel reframen.
4. Open-Source-Abhängigkeiten
   Die andere Seite der Glasswing-Medaille: Anthropic hat 100 Mio. USD an Usage Credits und 4 Mio. USD direkt an Open-Source-Security-Organisationen zugesagt. Wenn die eigene Organisation Open-Source-Upstream-Beiträge liefert oder auf kritische OSS-Infrastruktur angewiesen ist, ist aktive Beteiligung an diesen defensive efforts – OpenSSF-Initiativen, direkter Kontakt zu Upstream-Maintainern, Contributor-Backing für kritische Libraries – ein direkter Risk-Mitigator für die eigene Supply Chain.

Ein pragmatisches 90-/180-/365-Tage-Playbook

Genug Analyse. Was sollte jetzt konkret getan werden?

Playbook: Die ersten 90 Tage

1. Assumption Update. Threat-Model-Review-Session, in der «AI-enabled adversary» als Standard-Threat-Actor-Profil eingeführt wird. Betroffen: alle kritischen Assets, alle Tier-1-Prozesse.
2. Tabletop. Mindestens eine TTX-Übung mit Szenario «mittelmässig kompetenter Angreifer, AI-assisted, unbekannte Initial-Access-Methode gegen Legacy-Asset». Playbook-Gaps dokumentieren.
3. Legacy-Inventar. Liste aller Assets älter als zehn Jahre, insbesondere intern entwickelte Software. Klassifizierung nach Exposure und Business-Criticality. Wahrscheinlichste erste Angriffsfläche.
4. Detection-Engineering-Backlog prüfen. Anteil signaturbasierter vs. verhaltensbasierter Detections messen. Zielwert für Verschiebung setzen.
5. Vendor-Liste der Top-20-Kritischen. Fragebogen um die Punkte aus Abschnitt 6.1 ergänzen. Versenden.

Playbook: Monate 3 bis 6

1. Virtual-Patching-Capability etablieren. Wenn nicht vorhanden: WAF-Rule-Pipeline, schnelle IPS-Signature-Deployment-Prozesse, Netzsegmentierungs-Playbook für kritische Assets.
2. Exposure Management. Pilot mit einem EASM- oder Attack-Path-Analysis-Tool. Ziel: Umstieg von «welche CVEs?» zu «welche Pfade?».
3. SBOM-Programm. Für intern entwickelte Produkte automatisiertes SBOM-Generation im Build. Für extern bezogene Software: systematische SBOM-Anforderung, gestaffelt nach Kritikalität.
4. LLM-assistierte SOC-Triage – mit Drift-Monitoring ab Tag eins. Pilot mit dedizierter, datenschutzkonformer LLM-Integration in SIEM/SOAR. Data-Boundaries vor dem Pilot definieren, nicht danach. Zwingend begleitend: Golden Corpus mit 200-2.000 Referenzinputs, Output-Distribution-Monitoring (PSI, JS-Divergence), Refusal-Rate-Tracking und eine klare Trennung zwischen maschineller Entscheidung (gepinntes lokales Modell) und analyst-facing Generierung (Frontier-Modell). Ohne diese Schicht ist jede Aussage zu Detection-Qualität nach drei Monaten Produktion unbelegt.
5. IR-Playbook-Review. Zero-Day-Assumption als Default in Major-Incident-Procedures. Preservation-Trigger früher.

Playbook: Monate 6 bis 12

1. Risk-Quantification-Modell anpassen. Time-to-Exploit-Schätzungen revidieren, SLA-Tiers entsprechend neu strukturieren.
2. Vendor-Rescoring. Auf Basis der Antworten aus Phase 1 Top-Vendors neu bewerten. Kritisch sind insbesondere unklare Aussagen zu KI-gestützter Security-Analyse, fehlende SBOM-/VEX-Nachweise oder unrealistische Patch-SLAs. Bei solchen Lücken gezielte Eskalationsgespräche führen und Konzentrationsrisiken im Board-Reporting sichtbar machen.
3. Threat Hunting auf Legacy. Dedizierte Hunting-Kampagnen auf den identifizierten Legacy-Assets. Hypothesen: unbekannter Initial Access via alter Library-Vulnerability, Lateral Movement über deprekatiertes Admin-Protokoll.
4. Participation. Teilnahme an branchenspezifischen Information-Sharing-Initiativen prüfen (ISACs, CERT.at, sektorale CSIRTs), die AI-enabled-threat-Intelligenz austauschen. Isoliertes Arbeiten wird teurer.
5. Board-Reporting neu aufsetzen. Metriken, die vor zwei Jahren aussagekräftig waren (Anzahl gepatchter CVEs, Anzahl gehandhabter Alerts), sind es weniger denn je. Ersetzen durch Exposure-Metriken, MTTD-minus-TTE-Proxies, Vendor-Risk-Heatmaps.

Fehlreaktionen nach Anthropic’s Claude Mythos, die teuer werden

Drei häufige Reaktionsmuster, die in den nächsten Monaten teuer werden:

1. Panik-Prozess-Neubau. Wer jetzt das komplette Vulnerability-Management-Programm «wegen Mythos» neu ausschreibt, verschenkt sechs Monate auf einen Prozess, der zwei Iterationen zu weit von der aktuellen Realität entfernt ist. Inkrementelle Anpassungen sind fast immer überlegen.
2. AI-Security-Snake-Oil kaufen. Die nächsten Marketingwellen werden «Mythos-proof»-Labels tragen. Das Wort hat keine technische Bedeutung. Die Gegenfragen, die man einem Vendor stellt: wie behandelt das Produkt AI-generierte Malware-Varianten? Was ist die False-Positive-Rate bei LLM-assistierten Detections? Welche Trainingsdaten, welche Adversarial-Robustness-Tests?
3. Alles ignorieren. «Haben wir immer schon so gemacht, wird schon nicht so schlimm.» Mag stimmen, doch die Grundannahmen, auf welchen «immer so gemacht» basiert, haben sich verschoben. Ein Review der Annahmen ist günstig; ein Incident auf Basis veralteter Annahmen teuer.
4. LLM-gestützte Detection als Fire-and-Forget behandeln. Ein LLM-Klassifikator sieht aus wie eine Korrelationsregel, verhält sich aber nicht so. Hosted-Modell-Verhalten driftet ohne Ankündigung; self-hosted Stacks driften bei vLLM-Updates, Quantisierungswechseln oder Tokenizer-Changes. Ohne Golden-Corpus-Regression und Drift-Monitoring ist jede produktive AI Detection nach wenigen Monaten schlecht kalibriert – und die Operating-Point-Verschiebung bemerkt man typischerweise erst nach dem Incident, der sie sichtbar gemacht hat.

Takeaways und CISOs Antworten auf Anthropic’s Claude Mythos

Mythos ist keine Revolution und keine PR-Nummer. Es ist ein deutliches Signal, dass KI-gestützte Offensiv-Capability eine Commodity-Trajektorie genommen hat und die defensive Seite entsprechend anpassen muss – nicht über Nacht, nicht in Panik, aber auch nicht später als 2026.

Der pragmatische CISO operiert in drei Modi gleichzeitig:

• Tagesgeschäft weiterführen
• an den Stellen inkrementell anpassen, an denen sich die Grundannahmen messbar verschoben haben 
• mit dem Vorstand ehrlich über die verbleibende Unsicherheit sprechen.

Alle drei sind wichtiger als die perfekte Antwort auf die Frage, ob Mythos «wirklich» AGI ist.

Die eigentliche Arbeit beginnt nicht mit einem neuen Tool. Sie beginnt mit einer harten Review der eigenen Annahmen.

Threat Modeling

Bleiben Sie am Puls der digitalen Sicherheit: Entdecken Sie spannende Entwicklungen, fundierte Analysen und die wichtigsten News aus der Welt der Cybersicherheit. Abonnieren Sie unsere Blog-Updates und lassen Sie sich die neuesten Insights direkt in Ihr Postfach liefern – kompakt, relevant und immer einen Schritt voraus.

Blog Updates abonnieren

Quellenangabe:
•    Anthropic: Ankündigung Claude Mythos Preview und Project Glasswing, 7. April 2026. https://red.anthropic.com/…
•    UK AI Security Institute (AISI): Unabhängige Mythos-Evaluierung. https://www.aisi.gov.uk/…
•    AISLE: AI Cybersecurity After Mythos: The Jagged Frontier — https://aisle.com/…
•    Scientific American: What is Mythos and why are experts worried about Anthropic’s AI model — https://www.scientificamerican.com/…
•    Council on Foreign Relations: Six Reasons Claude Mythos Is an Inflection Point for AI and Global Security — https://www.cfr.org/…
•    Bloomberg: How Anthropic Discovered Mythos AI Was Too Dangerous For Release — https://www.bloomberg.com/…
•    The Hill: Anthropic’s Mythos model sparks cybersecurity concerns — https://thehill.com/…
•    CBS News: Anthropic’s Mythos AI can spot weaknesses in almost every computer on Earth — https://www.cbsnews.com/…
•    PwC: Global Digital Trust Insights 2026 (AI-enabled threat dynamics).
•    Mat Fuchs: Your AI Detections Are Rotting: Model Drift as a Hidden Risk in Security Operations — https://medium.com/@mathias.fuchs/your-ai-detections-are-rotting-model-drift-as-a-hidden-risk-in-security-operations-cac014477248