TL;DR: Security leaders should absolutely reassess their cybersecurity programs in light of Mythos, Daybreak, and other frontier AI models. AI will make some workflows easier to automate, some internal tools easier to build, and some vendor spend harder to justify. But the risk-reward calculus changes when a capability requires privileged access, specialized telemetry, validated evidence, or deep domain expertise. In those areas, buying an enterprise-grade tool will often remain the more effective and secure choice because the hard part is not generating code or producing a dashboard. The hard part is operating the capability safely, continuously, and with evidence the organization can trust.
Frontier security models are creating strategic uncertainty for cybersecurity buyers.
Programs like Anthropic’s Mythos and OpenAI’s Daybreak are changing how organizations think about security architecture, internal engineering, staffing, and vendor commitments. OpenAI describes Daybreak as a defender-focused program for finding, validating, and fixing vulnerabilities before attackers can exploit them. Mozilla reported that Claude Mythos Preview helped identify 271 vulnerabilities fixed in Firefox 150.
That is driving security leaders to reexamine which tools still provide durable operational value, which capabilities can be automated or built in-house with AI, and which parts of the environment must be verified before AI can safely influence decisions.
For every function a security team considers replacing or automating with AI, the question should be: Can we operate this capability safely, continuously, and with evidence we can defend?
AI Changes Build vs. Buy Considerations
Security teams have always built internal capabilities. They write scripts, create detections, build dashboards, automate ticketing, and customize workflows around their environment.
Frontier AI expands that capacity. A skilled team can now generate code, test ideas, build integrations, analyze large data sets, and create internal copilots with less engineering time. Some organizations will delay purchases while they evaluate whether a capability can be built internally. Others will reduce spend on tools that mostly provide reporting, summarization, or generic correlation. It remains to be seen which functions can be brought in house effectively through AI.
That applies to people as well as tools. Some companies that aggressively replaced human capacity with AI have had to rebalance after quality or customer experience suffered. Klarna is the clearest example: after promoting an AI assistant as doing the work of hundreds of support representatives, the company later returned to hiring human support staff. Customer Experience Dive covered Klarna’s reversal.
Cybersecurity raises the stakes. A vulnerability finding needs validation. A detection needs context. A remediation recommendation needs change control. An incident response action needs confidence that it will reduce risk without creating a larger outage. All of that requires the AI to have organizational context that can be challenging to provide to it.
Deep Access Raises the Stakes
The build-vs-buy question gets more serious when a security capability needs privileged access to critical systems. Cyber risk is notoriously difficult to quantify, and introducing uncertainty into how it is measured and managed can scale the risk nonlinearly.
The July 2024 CrowdStrike outage showed the risk. A faulty content update for a trusted security agent caused Windows systems to crash at scale, affecting an estimated 8.5 million devices. Microsoft estimated the incident affected 8.5 million Windows devices, and CrowdStrike’s post-incident review attributed the crash to a content update issue.
That was not an AI-driven incident. It was a conventional update failure from a tool with deep access to production systems.
AI raises the stakes further. A system that can inspect, isolate, patch, or reconfigure critical infrastructure has a potentially huge blast radius. If that system behaves unpredictably or acts on incomplete evidence, diagnosis and recovery become harder.
Recent cybersecurity survey data points in the same direction. Cobalt’s 2026 AI and Pentesting Pulse Report found that reliance on fully automated AI testing dropped sharply, while 78% of security teams reported false negatives from automated tools. Cobalt’s report argues for structured, hybrid approaches to AI-enabled testing. Automation helps, but expert review and validated context are still vital.
This has particular relevance to Eclypsium because of our focus on hardware and firmware level threat detection and integrity monitoring. Hardware, firmware, boot processes, BMCs, and network appliances require specialized collection methods, known-good baselines, and careful validation. Vendors of these products do not broadly grant access to the low-level visibility that enterprises need in order to assure the security of their infrastructure. The data required to train or enable an AI tool in this realm is challenging to gather, and often explicitly locked up behind vendor-specific tools and contracts. The underlying information about critical IT infrastructure is not easily available to train or enable an AI, and the ability to collect that information is actively gatekept by the vendors.
Building this yourself would be hard. And the stakes of screwing up would be high.
Durable Value Comes From Evidence, Control, and Validation
The answer to the question of which security functions can be automated, accelerated, or replaced with AI is probably unique to each organization. It depends on the people and expertise they already have, and the abilities of those people to leverage the AI tools available to them. The costs and capabilities of AI change so rapidly that it is difficult to predict what will make operational and financial sense.
With that said, there are some recurring themes that apply across most enterprises. The products most exposed to AI replacement are those that mainly summarize alerts, draft reports, generate tickets, or reformat information the customer already has.
AI can help develop collectors, parsers, detections, and workflows. But a production capability still needs safe collection methods, platform coverage, continuous updates, tested logic, integrations, and evidence that can stand up to audit, incident response, and executive scrutiny.
Feeding all of your data into AI is one thing. Trusting the decisions made inside the nondeterministic black box of the model weights is another. When those decisions affect core business processes and production data or infrastructure assets, the bar for validating the evidence and outcomes goes way up. AI has not solved this problem yet.
A Practical Build, Buy, Verify Model That Accounts for Cyber Risk
Security buyers should divide their stack into three categories.
First, capabilities AI can automate or accelerate: reporting, summarization, ticket generation, query writing, detection drafting, advisory review, investigation support, and executive communication.
Second, capabilities AI can help teams build internally: custom integrations, enrichment pipelines, internal copilots, lightweight scanners, policy checks, environment-specific automation, and workflow orchestration.
Third, capabilities that require authoritative systems of record, specialized telemetry, or operational control points: identity authority, endpoint telemetry, cloud configuration, network observability, application runtime context, data security posture, asset inventory, exposure validation, remediation verification, device integrity, firmware visibility, and drift monitoring.
Some organizations will build pieces of the third category. The bar is higher because these capabilities require sustained coverage, validated telemetry, governance, operational reliability, and defensible evidence.
This is where infrastructure trust becomes critical. AI can reason over hardware, firmware, network appliance, and device integrity data only if that data exists and can be trusted.
The Path Forward
Security leaders do not need to pause their programs while the frontier AI market stabilizes. They need a sharper evaluation model.
Identify which parts of the stack primarily package information the organization already has. Then identify where the organization depends on unique telemetry, specialized collection, authoritative state, or control points. Map which security decisions require evidence, especially vulnerability prioritization, remediation, incident response, compliance, exception handling, and executive reporting.
Finally, define where AI is allowed to recommend, where it is allowed to act, and where human approval remains required. Those boundaries should reflect business impact, reversibility, confidence in the underlying evidence, and tolerance for error.
Mythos, Daybreak, and similar models will change budgets, staffing plans, procurement cycles, vendor evaluations, and internal engineering priorities.
The strongest teams will use AI to increase leverage while preserving the telemetry, expertise, process, and verification required to make security decisions defensible.
The post-Mythos security strategy is to build where AI creates leverage, buy where specialized capability is required, and verify the data, telemetry, and infrastructure that every decision depends on.
FAQ: AI, Infrastructure Assurance, and the Post-Mythos Security Stack
AI can replace or reduce the need for some cybersecurity tools, especially tools that mainly summarize alerts, generate reports, create tickets, write queries, or repackage data the organization already has. It is less likely to replace capabilities that require privileged access, specialized telemetry, continuous validation, authoritative evidence, or safe control over production systems. In those areas, the hard part is not generating code or creating a dashboard. The hard part is operating the capability reliably, securely, and with evidence the organization can defend.
Infrastructure assurance is difficult to automate with AI because it depends on validated evidence from hardware, firmware, boot processes, management controllers, network appliances, and other infrastructure layers that are not easily exposed to standard security tools. AI can reason over infrastructure data only if that data exists, is trustworthy, and reflects the real state of the device. Without reliable telemetry and known-good baselines, AI may produce confident recommendations based on incomplete or unverifiable evidence.
Security teams should still buy capabilities that require sustained platform coverage, specialized telemetry, tested collection methods, continuous updates, domain expertise, operational reliability, and defensible evidence. This is especially true for security controls that touch privileged systems, production infrastructure, compliance reporting, incident response, firmware integrity, device posture, or remediation verification. In these areas, buying an enterprise-grade tool is often safer and more effective than assembling an internal AI-driven capability from scratch.
The build, buy, verify model separates cybersecurity capabilities into three categories. Build or automate workflows where AI can safely accelerate internal work, such as reporting, scripting, enrichment, and investigation support. Buy capabilities that require specialized telemetry, operational reliability, authoritative evidence, or control over critical systems. Verify the data, device state, and infrastructure integrity that AI systems and human teams rely on before allowing recommendations to influence high-impact security decisions.
Eclypsium supports AI-era infrastructure assurance by providing hardware-level visibility, firmware integrity monitoring, device posture validation, and drift detection across critical infrastructure. Eclypsium helps security teams collect and verify evidence from endpoints, servers, network appliances, and other infrastructure assets so decisions are based on device state rather than assumptions. This gives organizations a stronger foundation for using AI safely because the model can reason over verified infrastructure data instead of incomplete telemetry.
