Briefing · MRIS 2.0 · ISO/IEC 27001 and TISAX®
Mythos readiness for ISO 27001: what Claude Mythos means for your ISMS
Claude Mythos showed that AI finds vulnerabilities within hours and chains them into working exploits. This page summarizes which ISMS assumptions no longer hold, which controls stay robust and how to make an ISO/IEC 27001 ISMS Mythos-ready step by step.
What is Claude Mythos?
The name is not an invention. Claude Mythos Preview is a real AI model published by Anthropic on 7 April 2026 — in Anthropic's own description (Frontier Red Team, lead author Nicholas Carlini) a “general-purpose language model that is strikingly capable at computer security tasks”. Its existence had already become known in March 2026 through an accidentally published draft blog post; Anthropic subsequently confirmed to Fortune that the model represented a “step change in capabilities” with considerable cybersecurity risk. Anthropic itself calls Mythos “in a different league” compared with the predecessor model Opus 4.6: in a Firefox 147 exploit benchmark, Opus 4.6 managed two successful attempts in several hundred runs, while Mythos achieved 181 working exploits plus register control in 29 further cases; in an internal OSS-Fuzz benchmark, Opus 4.6 and Sonnet 4.6 reached at best a tier 3 crash, while Mythos achieved 595 tier 1 and 2 crashes and complete control flow takeover (tier 5) on 10 fully patched target systems — among them a 27-year-old, now patched OpenBSD bug, a 16-year-old FFmpeg flaw and a FreeBSD NFS remote code execution developed autonomously without human help (CVE-2026-4747). The New York Times described the disclosure as a “cybersecurity reckoning”.
Anthropic expressly did not release the model publicly — “we do not plan to make Claude Mythos Preview generally available” — but granted access exclusively through “Project Glasswing” to selected industry partners and open source developers (including Microsoft, Apple, AWS, Cisco and Nvidia; more than 40 companies), “to enable defenders to begin securing the most important systems before models with similar capabilities become broadly available”. Its own risk assessment was blunt: “In the short term, this could be attackers, if frontier labs aren't careful about how they release these models.” In the following weeks, independent findings confirmed the significance beyond the original Anthropic publication: roughly two weeks after release, Mozilla reported 271 security vulnerabilities in Firefox found and fixed with Mythos; on 14 May 2026, staff at Calif.io reported a memory corruption exploit for the Apple M5 created with Mythos.
Within a few days, the disclosure and reported cases of unauthorized access triggered crisis responses worldwide: the US Treasury and the Fed warned banks directly, central banks in Canada, the United Kingdom, India, Japan and Australia convened emergency meetings, a US congressional letter demanded a revision of federal cybersecurity policy, and China was denied access. In June 2026 the situation escalated further: following a reported jailbreak that potentially turned Mythos 5 into an “unrestricted cyber tool”, the US Department of Commerce under Howard Lutnick ordered a worldwide suspension of access for all foreign nationals — an intervention unprecedented in this form, which was partially lifted again at the end of June after negotiations with Anthropic.
It is precisely this scale that justifies the choice of name: a single model disclosure that within days simultaneously mobilized central banks, governments and a 40-member industry consortium, followed by worldwide export controls after a real jailbreak incident — that is the moment at which the previously abstract risk of AI-accelerated attacks first materialized concretely, with public evidence, and on a scale nobody had expected. “Mythos” therefore stands not for a metaphor but for a dated, documented event.
Important for the methodology: The name anchors this analysis at a fixed point in history — it is not a commitment to the proposition that the four shifts in the threat landscape (see Methodology) depend on the capabilities of the Mythos model itself. The actual evidentiary basis of the methodology consists of four independently documented incidents (the Cogent CVE evaluation, the GTG-1002 campaign, the JadePuffer ransomware — see Methodology), not Mythos-specific benchmark results. “Mythos attacker” is, throughout the remainder of this document, a linguistic shorthand for “an attacker with the four evidenced, generation-independent capabilities”, not a reference to a particular product. Should Mythos be technically superseded or withdrawn from the market in a few years, the methodology remains valid so long as the underlying capabilities — automated exploit development, autonomous multi-stage attack execution, fragmented attack patterns, decoupled attacker capability — persist or develop further in any available system. The name is a historical marker for the state of knowledge in July 2026, not a methodological dependency on a single vendor or model.
Mythos as a class term. In this handbook a class term: agentic frontier models with autonomous vulnerability discovery and exploit chaining, irrespective of vendor (including Claude Mythos/Fable 5, OpenAI Daybreak with GPT-5.5-Cyber, Microsoft MDASH). Originally the designation of the reference model Claude Mythos Preview (Chapter 2.5).
The central finding
Central finding
The established methods of information security have not become wrong — but one assumption underlying them no longer holds: that an attack is slow, laborious and expensive for the attacker. That braking effect disappears as soon as attackers deploy artificial intelligence. A substantial part of today's protection level therefore rests on a foundation that no longer carries.
The threat landscape has shifted
Four changes matter at leadership level:
- Speed: The time between a vulnerability becoming known and its exploitation is shrinking from weeks to hours. Response windows that used to be sufficient have become too short.
- Automation: Attackers have software perform the bulk of the work autonomously — faster than a team can react.
- Concealment: Attacks are broken down into many small steps, each unremarkable on its own, that individually trigger no alarm.
- Availability: Attack capabilities once available only to state actors are now broadly accessible. The circle of attackers to be taken seriously is growing.
This calls for an adjustment of security management
The answer is not a new security strategy but a targeted recalibration of the existing information security management system (ISMS). Where protection has so far relied on attacks being too laborious for the adversary, it must be moved onto more resilient foundations. This document sets out, in a structured and prioritized way, which existing measures still hold, which need to be sharpened, and where targeted additions are needed. The effort builds on what already exists and is manageable — but it requires the deliberate decision to take it on now.
Collapse of the patch gap window
Classic vulnerability management programs assume a time window between the publication of a patch and the availability of a working exploit. In practice this window was usually measured in days to weeks. It permitted staggered patch cycles, manual approval processes and selective prioritization by criticality.
Anthropic describes patch reversing to a working exploit as precisely the kind of mechanical analysis in which current models excel. The published defensive recommendation consistently calls for internet-exposed systems to be patched within 24 hours (as a guide value) of an exploit becoming available. For every control that relies on an orderly patch cycle with manual approval, the effectiveness assumption is broken.
Compression of the time axis
ISO 27005, like many incident response playbooks, presupposes that a humanly manageable amount of time lies between detection, triage and decision. That time no longer exists.
In the documented GTG-1002 case, Claude Code executed 80 to 90 percent of the tactical attack steps autonomously, at request rates unattainable for human operators. Controls with a human in the loop in the immediate response chain do not become ineffective because of poor quality, but because their response time is no longer of the same order of magnitude as the speed of the attack.
Fragmentation of the threat event
The risk model of ISO 27005 presupposes a discrete, identifiable threat event against which controls take effect. That precondition no longer holds under agentic attack patterns. For GTG-1002, Anthropic explicitly describes how the attacker decomposed the overall attack into sub-tasks — vulnerability scanning, credential validation, lateral movement, data extraction — each of which appeared as a legitimate technical request.
The risk materializes only in the aggregate. Controls based on evaluating discrete events — signature-based detection without behavioural context, rate limits with naive thresholds, policy-based alerting on individual actions — lose effectiveness even though they function technically. They see what they are meant to see. They do not see that the sum amounts to an attack.
Decoupling of capability and actor
Classic likelihood assessment rests substantially on an estimate of attacker capability: a nation-state actor was considered unlikely against a mid-sized German software vendor, not because the interest was absent but because the technical capacity for an individualized campaign was scarce. Mythos-class AI has largely dissolved this coupling between actor type and available capacity.
The threat intelligence reports show that actors with little technical competence of their own are now able to carry out operations that would previously have been attributed only to professional APT groups. The likelihood axis in every risk matrix shifts upward — not because of new threat actors, but because the capacity barrier facing existing actors has fallen.
Developments since first publication: from a single-vendor event to a multi-vendor market
Between May and July 2026, an Anthropic-centric observation became a market. Four developments are relevant to the assessments in this handbook:
OpenAI Daybreak (11 May 2026). OpenAI combines the GPT-5.5 model family with "Codex Security" as an agentic harness into a system for threat modelling, vulnerability discovery, exploit validation in isolated environments and patch generation; access is tiered (including "GPT-5.5-Cyber" for authorized red teaming).
Microsoft MDASH (12 May 2026). The "Multi-Model Agentic Scanning Harness" orchestrates more than 100 specialized agents across an ensemble of frontier and distilled models. First volume evidence: 16 previously unknown vulnerabilities in the Windows networking and authentication stack, among them four critical RCEs (including CVE-2026-33824, CVSS 9.8), patched in the May patch day; 88.45% on the public CyberGym benchmark against 83.1% for Mythos Preview.
General availability of the Mythos class (9 June / 1 July 2026). With Claude Fable 5, a Mythos-class model is generally available — with cyber safeguard classifiers; the variant without those safeguards (Claude Mythos 5) remains reserved for Glasswing partners. What matters for the assessment: the capability class is diffusing broadly, and the defensive lead conferred by an exclusive preview is progressively disappearing. This sharpens the exploit economics derived in 2.1 and 2.2.
Disclosure waves (from July 2026). Project Glasswing reported more than 10,000 high/critical findings for the first program phase; by 22 May 2026, 1,596 findings had been disclosed to maintainers of 281 open source projects, 97 of them patched. The announced public 90-day report (July 2026) and expiring embargo periods are producing CVE waves in H2 2026. In parallel, the NVD reports structural overload (submissions up 263% against 2020; since April 2026 enrichment has been prioritized to the highest risks), and HackerOne paused its Internet Bug Bounty program in March 2026. The volume shift forecast in MHC-02 (SBOM query capability) and MHC-09 (AI-supported testing) has thus materialized.
Consequence for this handbook. None of the 93 individual assessments and none of the thirteen MHC rationales is rendered wrong by these developments — they are confirmed and sharpened. From this version onward, "Mythos" is explicitly treated as a class term (see glossary): agentic frontier models with autonomous vulnerability discovery and exploit chaining, irrespective of vendor. Sources: list of references (accessed 19 July 2026).
Consequence for ISO/IEC 27005
The methodology of ISO 27005 — risk identification, analysis, evaluation, treatment — remains intact as a process. Its inputs, however, are affected: the likelihood axis shifts upward as the capacity barrier disappears. The time parameters between patch and exploit collapse. The aggregation logic of individually assessed events no longer holds. And the effectiveness assumption behind many existing controls — particularly those resting on attacker friction rather than on hard impossibility — has been empirically refuted.
Note: In Clause 7.2.1, ISO/IEC 27005:2022 distinguishes two approaches to risk identification — the event-based and the asset-based approach. The event-based approach is particularly affected under Mythos conditions, because it constructs scenarios from individual threat sources that, in a micro-step attack, become visible only in the aggregate.
Mythos readiness: what to do now
The recommendations from MRIS 2.0, chapter 10, starting with the immediate reassessment of existing controls.
Immediate reassessment of existing controls
It follows from the analysis in Part II that the four controls from Chapter 6 (friction-only) and the 37 controls from Chapter 5 (partially degraded) must be reassessed in the risk assessment of a Mythos-exposed ISMS. The reassessment is carried out using the four assessment criteria from Chapter 3.2 and has concrete consequences for the Statement of Applicability:
- For the four controls A.5.25, A.5.36, A.8.8 and A.8.23, it is examined whether they are recorded in the SoA in their existing form as the sole mitigation for Mythos-relevant risks. Where that is the case, the entry is supplemented or corrected with the respective replacement recommendation from Chapter 6.
- For the 37 partially degraded controls, it is examined which of the five supplementation patterns from Chapter 5.3 has already been implemented in each case and where gaps remain. The result is a gap list per control as input to the structural hardening.
- For the 29 robust controls from Chapter 4, consistent implementation is examined. A robust control formally recorded in the SoA but not implemented throughout offers no protection under Mythos conditions. Example: an asset inventory without automated updating quickly becomes out of date, which is why Mythos-specific anomaly detection then has blind spots.
The reassessment does not produce a new ISMS document but an update of the existing SoA with two additions: first, notes on Mythos resilience per control; second, mappings to the thirteen MHC from Chapter 9. The update is a subject of the next management review.
Structural hardening: adopting the MHC into the SoA
The thirteen MHC concretize Mythos-relevant technical and organizational hardening patterns that ISO/IEC 27002:2022 does not prescribe at this technical depth or with this degree of obligation. Several MHC are expressly hardened forms of existing ISO controls — for example MHC-08 for A.8.13, MHC-03 for A.5.17 and A.8.5, or MHC-10 for A.5.35, A.5.36 and A.8.9; others address requirements that ISO covers only implicitly through the risk perspective. Adoption into the SoA follows a simple pattern:
- Each MHC is added as an additional SoA entry, with a reference to the flanking ISO controls from the compact MHC table (Chapter 9.4).
- The implementation status is documented honestly: already implemented, partially implemented, planned, or not addressed. The category "planned" should carry an explicit justification of why immediate implementation is not possible.
- For each MHC it is examined whether it is applicable at all in the organizational context. MHC-07 (multi-tenancy isolation), for example, is not relevant for organizations without a multi-tenant architecture. Such non-applicability is likewise recorded explicitly.
Adoption creates no compliance obligation, because the MHC have no normative basis in the ISO 27001 sense. It documents the deliberate engagement with the Mythos threat landscape and gives internal and external auditors a traceable basis. For organizations subject to regulation that already requires an MHC content, adoption coincides with an existing obligation. That applies only within the respective scope, however: MHC-12 corresponds to the TLPT requirements for those DORA-regulated financial entities identified for TLPT under Art. 26(8) — not for all DORA addressees. MHC-11 operationalizes the NIS2 and Implementing Regulation requirements on detection, response and recovery; a SOAR system or automated tier 1 containment is not prescribed there across the board.
Maturing the ISMS process
Several observations from the Mythos threat landscape have direct implications for how the ISMS is operated:
- The risk assessment under ISO 27005 remains the basis but must be updated in shorter cycles. What was classified as a low threat a year ago may be acute today. An annual formal risk assessment with supplementary in-year review of specific risks is appropriate.
- The management review under ISO 27001 Clause 9.3 should take up the Mythos threat landscape as a recurring agenda item. The version notes of this handbook and relevant threat intelligence reports can serve as the basis.
- The internal audit function should be supplemented by continuous audit elements (substantively identical with MHC-10). The results of automated monitoring feed into the reduced but still annual formal audits; they do not replace them.
- The ISMS KPI landscape is supplemented by Mythos-relevant indicators (see Chapter 10.6).
- Establish innovation acceleration governance: a cross-functional body drawn from security, legal, engineering, data protection and, where relevant, procurement, with the explicit mandate to evaluate and put into production defensive AI tools and new security controls on an accelerated basis. Without this body, every Mythos hardening measure runs into the usual approval friction (procurement cycles, legal review, data protection clearance) which, under Mythos conditions, becomes a structural weakness — the NIS2 IR implicitly recognizes this in No. 1.1 as a governance obligation. Recommended cadence: fortnightly, with a defined time-to-decision target of no more than 30 days for tools holding a valid ISO 27001, SOC 2 or C5 attestation.
- Build a permanent VulnOps function analogous to DevOps, instead of running vulnerability management as a part-time task within the SOC. Responsibility: continuous discovery of zero-days across the entire software estate (own code, third-party software, cloud configuration), automated remediation pipelines, and EPSS- and KEV-based prioritization. Minimum capacity from roughly 1,000 employees onwards, or from the point at which the patch load reaches 100 or more critical findings per month. This function addresses the risk of continuous vulnerability management maturity classified as CRITICAL in Mythos-Ready (CSA, SANS, OWASP).
Board communication and risk dialogue
The challenge is to present the threat without alarmism, but also without downplaying it. The following points have proved useful:
- The four findings from Chapter 2 lend themselves as a structure for a board presentation: collapse of the patch gap window, time axis compression, fragmentation, capability decoupling. All four are empirically documented.
- The distinction between robust, partially degraded and friction-based controls conveys that security is not failing across the board but that targeted adjustment is required.
- The MHC from Chapter 9 are suitable as a basis for discussing investment decisions. They supply concrete reference points supported by framework references.
- The regulatory embedding should be made transparent. Mythos hardening is, to a considerable extent, a legal obligation rather than merely best practice — depending, however, on sector and addressee group. For CRA-obligated software manufacturers, DORA-regulated financial institutions and NIS2 IR addressees (certain digital providers, see Chapter 3.3), it applies directly; for other NIS2 entities, the respective national transposition governs.
- Address the possible evolution of the standard of care — as a strategic assessment by the author, not as a legal obligation in force. The EU AI Act creates no duty to deploy AI-supported threat hunting, code scanning or vulnerability discovery tools. With the broad availability of defensive AI tools, however, it is to be expected that the yardstick of what counts as an appropriate security measure will shift. Governing bodies may increasingly need to demonstrate to supervisors, insurers and courts which AI tools they deploy for defensive purposes (code audit, threat hunting, vulnerability discovery) — and to justify not using tools that are available. Recommended as a recurring board briefing element: "Which defensive AI tools have we introduced in the reporting period? Which are we evaluating? Which are we deliberately not using — and on what grounds?" This addresses the risk of regulatory and liability exposure classified explicitly as HIGH in Mythos-Ready (CSA, SANS, OWASP).
Mythos-relevant metrics
The following metrics are a selection, not an exhaustive KPI set. They are oriented to the thirteen MHC and the four assessment criteria from Chapter 3.2.
| Metric | Description | Reference |
|---|---|---|
| Mean time to containment (MTTC) | Average time from detection to automated or manual containment of an incident. Target for high-confidence alerts below 10 minutes. | MHC-11, MHC-05 |
| Phishing-resistant account coverage | Share of all privileged and externally reachable in-scope accounts with phishing-resistant MFA (account coverage, not logins). Target for privileged accounts: 100% or a documented, time-limited and risk-approved exception; externally reachable typically at least 95%. | MHC-03 |
| SBOM coverage | Share of the organization's own software artefacts with an automatically generated SBOM, and share of critical suppliers with a contractually assured SBOM obligation. | MHC-02 |
| Remediation latency for KEV listings | Time between the availability of a robust remediation or effective compensating option and its verified implementation. Patch, workaround, compensating control, isolation or replacement of the affected asset count as effective measures. Target below 24 hours (mean). Definition in Annex G.4. | MHC-09 |
| Pipeline gate coverage and escape rate | Share of production pipelines with security checking and a pre-merge block; supplementary, the share of vulnerabilities that reach production despite pipeline checking, and the share of suitable applications with an AI-supported test method in production. | MHC-09 |
| Restore test success rate | Share of successful quarterly restore tests from immutable backups. Target 100%. | MHC-08 |
| Continuous monitoring coverage | Share of the SoA requirements classified as automatable whose implementation is checked by automated continuous monitoring in addition to periodic audits. The reference base is automation eligibility, not the total number of controls (definition in Annex G.6a/G.6b). | MHC-10 |
| Cryptographic inventory coverage | Share of the cryptographic methods in use that are recorded in the central inventory and carry a priority classification for PQC migration. | MHC-01 |
| TLPT findings closure rate | Share of findings from threat-led penetration tests closed within the defined remediation period — contractual, internal or regulatory. | MHC-12 |
| Container policy conformity | Share of production container workloads that pass signature verification and admission control policies at deployment. Target: 100% in critical or fully in-scope production namespaces, and at least 95% technical coverage organization-wide; remaining exceptions are documented, risk-assessed and approved. | MHC-06 |
| Agent inventory coverage | Share of production AI agents and agentic workflows within the organization's area of responsibility — including SaaS, low-code and no-code agents — that are fully inventoried. Target 100%. Corresponds to the Initial maturity level. | MHC-13 |
| Agent governance coverage | Share of the inventoried production AI agents and agentic workflows for which at least a named owner, a capability-scoped identity, documented permission boundaries and a tamper-resistant execution log are implemented and documented. Target 100%. Corresponds to the Defined maturity level. | MHC-13 |
The ten primary metrics do not cover all thirteen MHC (supplementary, the automation eligibility reference metric is collected for MHC-10 and governance coverage for MHC-13). For the structural controls MHC-04 (workload identity) and MHC-07 (multi-tenancy isolation), this is a deliberate design decision: implementation evidence is provided through implementation stage gates in project controlling rather than through continuous metrics.
Gate criteria (guide values, per maturity level): MHC-04 — Initial: SPIFFE/SPIRE identities for 80% or more of privileged service workloads; Defined: mTLS mandatory for east-west traffic — 100% of in-scope connections or documented, time-limited and risk-approved exceptions; 95% or above counts expressly only as a transition threshold and not as full fulfilment of Defined; Managed: attestation-supported access policies in production. MHC-07 — one passed, documented tenant separation test per level (Initial: annually, internally; Defined: per major release; Managed: additionally by independent third parties). Gate fulfilment is recorded in project controlling as a yes/no attestation.
The 16 hardening measures
Every Mythos Hardening Control (MHC) has its own page with control statement, maturity path and audit evidence. The order of implementation is described in the P0 to P2 roadmap.
- MHC-01 Post-Quantum Strategy and Cryptographic Inventory
- MHC-02 SBOM and Build Provenance
- MHC-03 Phishing-Resistant MFA
- MHC-04 Workload Identity and Zero Trust
- MHC-05 Behavior-Based Detection
- MHC-06 Containers and Confidential Computing
- MHC-07 Multi-Tenancy Isolation
- MHC-08 Immutable Backups
- MHC-09 AI-Assisted Security Testing
- MHC-10 Continuous Control Monitoring
- MHC-11 SOAR and Tier-1 Automation
- MHC-12 Threat-Led Penetration Testing
- MHC-13 AI Agent Governance
- MHC-14 Independent Verification of Supplier Evidence
- MHC-15 AI-Resistant Identity Verification for Staff/Access
- MHC-16 Multi-Agent Integrity
Sources on the model
- Claude Mythos Preview — Anthropic (primary source)
- Frontier Red Team: Claude Mythos Preview — Anthropic (primary report with benchmark details on exploit and crash figures)
- The zero-days are numbered — The Mozilla Blog (primary source on the 271 vulnerabilities found and fixed in Firefox)
- First public kernel memory corruption exploit found by an AI agent — Calif.io (primary source on the Apple M5 exploit)
- Anthropic Claims Its New A.I. Model, Mythos, Is a Cybersecurity 'Reckoning' — The New York Times
- Anthropic Teams Up With Its Rivals to Keep AI From Hacking Everything — Wired
- Anthropic acknowledges testing new AI model representing 'step change' in capabilities — Fortune
- Anthropic Model Scare Sparks Urgent Bessent, Powell Warning to Bank CEOs — Bloomberg
- Anthropic Disabled Fable 5 And Mythos 5 After A U.S. Export-Control Order — Forbes
- White House drops export controls on Anthropic's Mythos and Fable AI models — The Washington Post
Source: MRIS for ISO/IEC 27001, edition 2.0 (PDF), CC BY-SA 4.0. Section “What is Claude Mythos?” and sources on the model: MRIS for TISAX® 2027, Part I, edition 2.0 (PDF), CC BY-NC 4.0. Chapter references in the text refer to the respective PDF edition.