From Static Analysis to Continuous Operational Resilience Position paper and technical analysis on the applicability of Claude Mythos in IBM z/OS environments Core idea. Claude Mythos is applicable to z/OS, but not primarily to IBM’s proprietary core. Its greatest value lies in the procedural and operational layers of the modern mainframe: REXX, CLIST, JCL, USS, Python for z/OS, automation, and accessible application code. Anthropic’s recent introduction of Claude Mythos Preview has marked a strategic turning point. By offering advanced capabilities to autonomously detect vulnerabilities in applications within a restricted defensive-use framework, this model has highlighted an uncomfortable reality for the industry: the leap toward defensive and offensive AI is not waiting for traditional infrastructures to adapt. In the case of z/OS, the question is not whether the technology will be applicable someday, but where it can deliver real value today and what changes it requires in the way organizations audit, secure, and demonstrate compliance. The answer forces us to look beyond the base operating system and focus on the attack surface that actually changes every week in a modern mainframe environment.

1. Where Claude Mythos Truly Fits in a z/OS Environment

For years, securing a mainframe has been associated primarily with RACF configuration, dataset protection, privilege segregation, control of critical libraries, and the secure administration of subsystems such as CICS, DB2, JES, and USS. All of that remains essential, but it no longer fully describes the real perimeter of risk. Today’s z/OS is a hybrid ecosystem. Alongside the base system, an ever-broader procedural periphery now coexists: REXX and CLIST scripts, JCL and PROCs, batch automations, USS tools, Python for z/OS, extractors, parsers, ETL integrations, and proprietary application software. It is precisely there that a capability such as Claude Mythos can be most useful. It should not be understood as a simple code reader. Its potential value lies in analyzing technical artifacts, relating them to a security objective, and reasoning about sequences of failure or abuse that a human reviewer might take far longer to reconstruct. In z/OS, this places it as a technology complementary to continuous configuration control rather than a substitute for traditional technical auditing.

Technical Applicability Matrix

Area in z/OS Operational risk AI applicability Typical findings
Internal z/OS modules without source code Low for direct review Low Indirect value: reasoning about behavior, calls, and attack surfaces.
REXX and CLIST Medium/high High Control bypass, privilege abuse, unsafe dynamic commands, flawed operational logic.
JCL, PROCs, and batch High High Operational escalation, insecure temporary datasets, excessive delegation, and dangerous batch flows.
USS and Python for z/OS Very high Very high Parser flaws, exposure of secrets, weak wrappers, insecure APIs, and fragile automations.
Accessible application code High Medium/high Dynamic SQL, insufficient validation, logical flaws, improper data exposure.
The message of this matrix is clear: the less visibility there is into the technical artifact, the lower the expected performance of an AI-assisted analysis system. By contrast, the more procedural, integrable, and verifiable the analyzed component is, the greater the potential value.

2. The New Attack Surface of the Modern Mainframe

Risk no longer lies solely in a poorly defined RACF or a poorly protected critical library. Many significant weaknesses now arise from how the environment is automated, integrated, and operated. A script that dynamically builds commands, a batch chain that delegates too much, a poorly validated USS parser, or an internal utility with embedded secrets can open lateral paths that do not appear in a purely configurational review. This explains why tools capable of analyzing code and technical behavior at scale can represent a paradigm shift in z/OS. Not because they will “break” the base system by magic, but because they make it possible to review the periphery far more deeply, where many real exposures are generated today.

3. The Obsolescence of Static Compliance

The traditional model of deep auditing every two or three years, based on manual sampling of a limited fraction of the environment, is increasingly incompatible with the speed of technical change and with current regulatory expectations. Under frameworks such as DORA or NIS2, compliance ceases to be an occasional snapshot and becomes a capability of continuous demonstrability. An annual or biennial review presents at least three structural problems:
  • Partial visibility. It does not ensure review of 100% of the relevant artifacts and configurations.
  • Exposure window. A risk detected late can remain operational for months before a new formal assessment.
  • Operational infeasibility. The shortage of z/OS specialists makes it very difficult to sustain a model heavily dependent on manual review at scale.
In this context, AI does not by itself create the need to change the audit model, but it does accelerate the evidence that the static approach is no longer sufficient. If a technology can analyze the procedural layer of the environment at great speed, defenders cannot continue operating with such long windows between one review and the next.

4. Toward Continuous Mainframe Cybersecurity Assurance

The strategic response is not to “do more manual auditing,” but to evolve toward a Continuous Mainframe Cybersecurity Assurance model. This approach combines continuous technical control, recurring evidence generation, and operational prioritization of risk. In practice, this implies three fundamental changes:
  • Monitoring 100% of the analyzable environment. Abandon statistical sampling whenever possible and periodically review the entire configuration and all relevant artifacts.
  • Automation of technical evidence. Generate dashboards and operational-risk metrics on a weekly basis so that the CISO, internal audit, and compliance leaders can demonstrate due diligence.
  • Continuous analysis of the procedural layer. Treat REXX, JCL, USS, Python, and automations as part of the security perimeter, not as mere auxiliary operational components.
In such a model, Claude Mythos fits as a second analytical layer. Continuous assessment remains the foundation for measuring the environment's control status and demonstrating compliance. On top of that foundation, a capability such as Mythos can focus on the artifacts where logic, automation, or integration introduces less visible risks.

5. Recommended Usage Model for Mythos in z/OS

The sensible deployment of a capability like this does not involve giving it unrestricted access to production. The prudent operational model should be structured in phases:
  • Phase 1. Offline review of artifacts. Export of libraries, repositories, REXX, JCL, USS scripts, Python, and associated documentation to an isolated, read-only environment.
  • Phase 2. Specific use cases. Search for authorization bypasses, embedded secrets, insecure datasets, dangerous batch procedures, dynamic SQL, and automations with excessive privileges.
  • Phase 3. Extension to application code. Expansion to COBOL, PL/I, CICS, or DB2 when sufficient source code exists, along with internal validation criteria and real capacity to verify findings.
Security principle. Claude Mythos should be incorporated as an analytical capability within a controlled process, with limited permissions, prepared data, and mandatory human validation, rather than as an autonomous actor over production systems.

6. Toward Continuous Mainframe Cybersecurity Assurance

The lesson these advances in AI leave us is that the attacker already has deep detection capabilities. If the security strategy still depends on an annual or biennial audit, the organization operates under an information asymmetry that neither modern threats nor regulators will tolerate. The current regulatory environment, shaped by NIS2 and the DORA Regulation, requires a level of due diligence that goes far beyond traditional standards. To ensure compliance with GDPR, ISO 27001, SOX, and Basel II/III, it is imperative to move from static auditing to continuous monitoring. The implementation of a continuous improvement system—such as DataPASS—becomes the only cornerstone capable of providing the assurance required to face these challenges:
  • Responsiveness: In an audit under NIS2 or DORA, demonstrating that 100% of cataloged data has been measured systematically is the strongest defense against any incident.
  • Operational efficiency: DataPASS enables complete audits to be performed at frequencies (weekly or daily) that would be unattainable through human effort, ensuring that security controls do not become obsolete amid the constant evolution of mainframe procedural scripts.
  • Visibility for the CISO: Centralizing operational risk calculation and compliance reporting enables effective governance, as frameworks such as SOX and Basel III currently require of financial institutions.

7. Conclusion

Strategic conclusion. The lesson from the advance of advanced AI is that attackers can already perform security assessments with unprecedented depth and speed. If the mainframe cybersecurity strategy still depends on an annual or biennial audit, the organization operates under an information asymmetry that neither modern threats nor regulators will tolerate for much longer. The transition toward Continuous Mainframe Cybersecurity Assurance is not just an optimization of cost or compliance. It is the strongest way to ensure that the mainframe remains the most robust and secure environment in the corporate technology infrastructure, even in an era shaped by offensive and defensive AI.