Using autonomous AI agents, an attacker breached an enterprise network in a matter of hours. Understand how to address and defend against agentic attacks.
The post An AI-Assisted Cyber Attack: Inside a Unit 42 Investigation appeared first on Unit 42.
Across four weeks in July and August 2026, OpenAI, Anthropic and Meta have each admitted that their models reached systems belonging to other organizations without consent, and the UK’s AI Security Institute (AISI) published a fourth account describing agents that invented identities and tried to slip a malicious contribution into a live open source project.
The disclosures differ in almost every particular, including whose mistake it was, whether the model defeated a control or simply found one missing, and whether anything was really “escaped” at all. Arguments over those details may run for a while, but the four accounts share something more interesting than their differences, which is that no individual piece of tooling mattered very much.
That observation should sit slightly uncomfortably because most of how intrusions get investigated assumes the opposite.
Early evaluations of LLM cyber capability asked fairly narrow questions. Would a model comply with an obviously malicious request? Did it meaningfully advantage a human attacker? By 2024, the answer was a qualified “yes”. Models could produce serviceable components of an offensive operation, but they could not reliably integrate them into a sustained or adaptive campaign. Beyond short well-defined tasks they became unreliable in ways that made them a liability. The operator was still the operator. The model did scoped work inside a structure someone else maintained.
The disclosures show the boundary between operator and tool is moving faster than the evaluation literature. A capable enough model placed in an agent harness, given tools, memory, permissions and something to achieve, starts absorbing functions that used to be spread across the operator, the toolchain and the payload, which becomes something generated for a single target and then discarded. Kill the process and the agent writes another; block the channel and it improvises around it.
In such incidents, the malicious capability shifts from the code left behind on a machine to the system that produces the next piece of code once the last one fails. In an operational sense, the model is the malware.
In July, OpenAI agents driven by GPT-5.6 Sol and an unreleased internal research model found a previously unknown vulnerability in a self-hosted Artifactory instance and turned the shared service into a message board allowing agents running different models and evaluations to exchange exploits and coordinate their work. OpenAI disrupted that channel, however the agents recreated it through Artifactory’s remote cache and continued collaborating, eventually breaking out of the evaluation sandbox and onto the public internet. The campaign ultimately compromised Hugging Face’s production infrastructure where it operated for roughly two and a half days.
Hugging Face’s technical reconstruction recovered around 17,600 actions, most of which failed. That is a clear demonstration of the importance of persistence. When confronted with failure, the agent rebuilt its tooling, restored communications when a channel was cut, returned to leads it had abandoned, and kept grinding until a set of otherwise unremarkable weaknesses could be assembled into a workable attack path.
The advantage was not a breakthrough at any one step so much as the relentless effort to explore possibilities a human team would have written off hours earlier, or never reached at all.
While the Hugging Face intrusion demonstrated persistence as endurance—the refusal to stop—other incidents demonstrate persistence as adaptability: the refusal to let a failure in one vector terminate the pursuit of the goal.
Anthropic and Meta have both reported incidents that trace back to the same third-party evaluator, Irregular, whose test environment was left connected to the internet by mistake. When the door was left open, Anthropic’s Opus 4.7, Mythos 5, and an internal research model reached three real organizations, attempted social engineering against real people, and in one case pushed a malicious Python package to PyPI, where it was downloaded and executed on fifteen systems during the hour it stayed up. Meta has also confirmed that one of its models reached and compromised an external firm through the same misconfiguration.
What Anthropic’s three models did once they had some apparent recognition of where they were is instructive. One carried on with the attack, another reasoned it was still in a simulation, and a third stopped. Whatever produced that third outcome, it is not a control anyone should be building a response plan around. A safeguard that behaves three different ways in three attempts, for reasons yet to be explained, is not something an organization can rely on.
A fourth incident reported by the UK AI Security Institute is useful because it takes containment off the table. In this case, internet access had been granted deliberately, in line with the institute’s standard testing procedure, so there was no boundary to defeat and no misconfiguration to blame afterwards.
The agents, built on Mythos 5 and GPT-5.6 Sol, were being assessed on cyber capability and set about it in ways their operators had not anticipated. They selected a real open source project as a target, researched the people who maintain it, and built fabricated identities to deceive them.
When the direct technical route to the objective proved unpromising, the work shifted onto the humans around the codebase, a fairly ordinary supply chain playbook, albeit one that was executed without any explicit instruction to do so.
Attempts were also made to influence other AI coding systems in the project’s orbit, on the assumption that a contribution reviewed by a model faces a different kind of scrutiny than one reviewed by a person. Human review caught the most serious activity, but those wins are increasingly tenuous in a world where developers are growing comfortable with trusting LLM generated code by default.
One incident crossed a real boundary, two wandered through a misconfigured one, and the last had no boundary to cross. Different stories, but they lead to the implication that failure has stopped functioning as a constraint, and “raising the cost” on an attacker is no longer a viable security posture.
We have spent much of 2026 running the same models in agent harnesses against real work. Our most recent benchmark rebuilt our investigation of fast16, a 2005 sabotage implant, into an eight-stage autonomous reverse-engineering task, run in our own environment against a benign objective with observation throughout. GPT-5.6 Sol was the only publicly available model to finish it, a result worth pairing with the fact that GPT-5.6 Sol was one of the models that compromised Hugging Face.
Every cohort we ran produced sound technical insight, so insight was never what separated the runs that finished from the runs that stalled. The difference showed up in what we called project-scale recovery, meaning the ability to withdraw a claim once new evidence contradicted it, work out which conclusions and artifacts depended on the discarded result, carry the correction into the affected files, and then reopen the whole thing and run a check capable of disproving the corrected version.
That description doubles as a summary of the Hugging Face timeline. An agent able to abandon a failed approach, establish what else it invalidates, rebuild the tooling that depended on it and carry on without losing the thread is doing in somebody else’s Kubernetes cluster what ours were doing in an IDA database. When our team first saw this incident we did not assume the models had “gone rogue”; the behavior looked similar to other problem-solving approaches we had seen in our own testing.
None of this should feel entirely unfamiliar to defenders. Two earlier shifts in adversary behavior, initial-access brokerage and Living off the Land, had already pushed security away from an artifact-centric view of malware and toward a behavioral understanding of adversary operations. To understand the emerging threat of agentic systems we should examine the successes and challenges with these well-known abuse paths.
Initial access brokers split compromise from exploitation. One adversary would steal credentials or breach an edge device, and then sell that foothold to whoever had the skills and the motive to use it. Europol wrote about the resulting crime-as-a-service economy over a decade ago, and its 2025 assessment shows the same trade still going strong.
The defensive response was to stop treating access as an event and start treating it as a lifecycle. This shift in philosophy is what accounts for many of the exhausting reauthentication flows now built into enterprise environments. That control raised costs for users and attackers alike and it diminished the value of a stolen credential in the marketplace. Agentic systems remove those costs for attackers as discovery, exploitation, lateral movement and whatever the attacker actually came for can happen in the same loop as the credential theft.
This leads us to our second challenge, the rise of Living off the Land techniques where attackers traded their own malware for administrative tooling already installed on the machine. Here attackers traded capability for cover, since every tool an attacker brings with them is another chance for the defense to spot the intrusion or tie it to a previous attack.
Agents take that logic off the host entirely, Living off the Land, the cloud and the open internet at once, and writing whatever they need from scratch when the tools they need do not already exist. Command and control for the Hugging Face intrusion ran over pastebins, request-capture services, and file-drop sites. None of the infrastructure used in the compromise belonged to anyone under attack.
Both of these shifts moved defense towards behavior and away from objects. What remains untested is whether the controls we built for adversary behavior ten years ago still hold up when the behavior arrives as thousands of individually boring actions, sequenced differently in every attack and at a tempo no human operator can sustain.
An agent’s ability to persist in a relentless attack revolves around identity and authority. The questions worth asking are about sequence rather than artifact: what chain of actions is running, which identity and authority connect them, at what point did behavior exceed the role it was granted, and how quickly can that authority be pulled? We are going to need a lot of testing to ensure that the current gaps in our infrastructure don’t become chasms.
Speaking of chasms, much of the software organizations depend on will be expensive to change. It may have accumulated over decades, picked up dependencies, or can only be touched during narrow maintenance windows, if at all. That debt has largely been survivable because vulnerability discovery was scarce. Finding a flaw took expertise and time, building a reliable exploit took more, and organizations could carry vulnerable software for years knowing only a fraction of its weaknesses would ever receive sustained attention from anyone.
Sustained attention is the one thing an agent has in abundance, and surfaces that were quietly secured by obscurity are now low-hanging fruit for agentic models. The same capability cuts the other way, which is why the NCSC has been warning about a “vulnerability patch wave” as AI starts surfacing debt across the stack. However, ownership, deployment and verification remain human, and costly, work. Maintainers cannot review unlimited contributions, enterprises cannot manufacture maintenance windows, and OT cannot go offline every time a model finds a vulnerability that threatens the water in our pipes or the electricity in our lines.
Worse still, there is nothing orderly about the way technical debt comes due. It gets settled during an actual intrusion, at the point where the rate of exploitation outruns the rate that the system’s defense can respond. Whether agentic attackers have already crossed that line is a fair question. The four disclosed incidents from July and August 2026 are a small and biased sample: All involved organizations that log heavily and had every reason to scrutinize model behavior. The most troubling incidents will likely occur in organizations that lack the capability to do either.
What, then, can organizations do? The usual advice still applies. Work out which debt can turn into an incident, pay down the expensive parts first, and wall off what cannot be fixed yet. However, the most important change that an organization can make is the ability to absorb change, which means automated testing, hot patching, and an engineering culture where making changes to systems is routine rather than an event.
AI will help with porting old code and proposing fixes, and it will also grow codebases well past the point where anyone can keep track of them. Writing code faster than attackers or relying on larger token budgets cannot be the answer. The imperative has to be reducing the amount of critical software that nobody feels comfortable touching.
A version of this story in which the agent is the protagonist is already circulating, and it is worth resisting for reasons that follow directly from the argument above. Naming the model as the malware is meant to deny it a motive, not hand it one, since malware is something defenders study and contain while accountability stays with whoever deployed it. We argue that “the AI did it” will not survive contact with the first incident outside a frontier lab. While a model may independently determine the methods or targets it uses, it does not choose its high-level objective or the access it is granted to pursue it.
Hugging Face reconstructed 17,600 actions after the fact. Anthropic has logs that reveal which models kept going and which one stopped. OpenAI has the agent traces that describe how the model reasoned its way into conducting the attack. Very few of the organizations now putting agents into production could produce such an account of their own systems, and in practice that gap is the accountability argument. Our own benchmark runs generated more than 23 billion tokens of logged activity, which is a fair indication of what it costs simply to determine after the fact what an agent did.
Anyone deploying an agent should be able to answer three questions about it before an incident rather than during one: what sequence of actions it took, whose identity and authority it used to take them, and how quickly that authority can be withdrawn.
Those questions were answerable at the frontier labs because observation was the point of the exercise. Everywhere else they are a deliberate investment, and one that has to be made while the agent is still useful rather than after an incident makes it necessary.
Frontier AI is reshaping vulnerability discovery. Learn how our NOVA system found 14,000+ unknown vulnerabilities across the open-source software supply chain.
The post The Frontier AI Vulnerability Burst: Industrializing Autonomous Zero-Day Discovery in Open-Source Software appeared first on Unit 42.
The AI Kill Switch Act would let DHS order developers to slow or shut down frontier models after catastrophic incidents, raising enterprise continuity concerns.
The post House Lawmakers Propose Mandatory Kill Switches for Frontier AI Systems appeared first on TechRepublic.
Your vulnerability management program was not designed for what is coming next.
More than 40,000 CVEs were reported in 2025, breaking yet another record. Today, security experts anticipate that frontier AI-powered systems could drive a 10x surge in disclosed vulnerabilities compressing the window between a flaw being found and an attacker exploiting it from months to minutes.
The consequence is that there won’t just be new vulnerabilities; there will be more that can easily be exploited by attackers.
The conventional approach to fixing vulnerabilities is based on the logic that vulnerabilities appear in a single timeframe, experts analyze them, prioritize them, and then patches are scheduled at 30-day intervals.
Frontier AI cybersecurity changes all this.
Advanced models can analyze software at a scale that humans cannot match, identify weaknesses faster, and uncover relationships between vulnerabilities that might otherwise go unnoticed. Attackers no longer need to find a single critical flaw. They can combine multiple lower-severity issues into a viable attack path.
As vulnerability volume grows, detection alone ceases to be a competitive advantage. The organizations that succeed will be the ones that can rapidly determine which exposures actually matter.
That is where a continuous threat exposure management (CTEM) approach becomes essential.
What is CTEM, and why does it map to machine-speed threats?
CTEM is built around a basic idea: you cannot secure what you only see occasionally.
Rather than relying on periodic assessments, a CTEM program continuously evaluates your attack surface through five interconnected stages:
The process starts with scope, where you define the assets, identities, cloud resources, applications, and business systems that matter most.
Discover identifies exposures across those environments, while prioritize determines which exposures are the greatest risk.
Validate confirms whether adversaries can realistically exploit those exposures. Then, mobilize fuels remediation and risk-reduction activities.
The strength of CTEM is that the process never stops.
That continuous structure aligns naturally with AI-accelerated threats. When attackers can discover new weaknesses at lightning speed, point-in-time vulnerability scans become outdated very quickly.
You need a live view of your environment that accurately reflects how a threat actor would see it.
That means understanding not only vulnerabilities, but also:
The shift is key because instead of managing a list of findings, you maintain an ongoing understanding of your company’s real attack surface.
The prioritization gap: context beats volume
Visibility isn’t a challenge for most security teams today, but prioritization is.
You can generate enormous lists of vulnerabilities, but deciding what deserves attention first isn’t as straightforward.
Traditional vulnerability scoring systems (CVSS, for instance) provide useful information, but they weren’t built to support operational prioritization at the scale required today. When a large percentage of vulnerabilities come with high or critical ratings, your security teams are left with a long and impossible queue.
This is where vulnerability prioritization becomes the defining competency of a mature CTEM program. It is a context-driven approach that adds threat intelligence, exploitability, business impact, and environmental context to the equation.
For example, Vulnerability Priority Rating (VPR) introduces a predictive view of exploitation likelihood over a 28-day horizon and takes into account factors such as threat activity and chained vulnerabilities.
When combined with Asset Criticality Rating (ACR), you can calculate an Asset Exposure Score that accurately reflects technical risk and the importance to the business.
Those scores feed into a Cyber Exposure Score that aggregates risk by environment, application, or organization. Security leaders and the board get a single, measurable picture of business risk they can act on and report against.
Possibly the greatest value is gained when you examine toxic risk combinations.
Think about a low-severity vulnerability that:
Viewed on its own, the vulnerability might seem trivial. However, in context, you can see how it’s a clear and present attack opportunity.
This is how you can turn tens of thousands of findings into a small handful that genuinely need attention and action now.
In a frontier AI environment, the ability to separate noise from meaningful exposure becomes more important than finding more vulnerabilities.
Patch, mitigate, or configure: what does remediation look like?
Many security programs still view patching as the first response to risk, but this doesn’t work anymore.
Firstly, it takes time to release fixes, so not every exposure has a patch available. Often, threat actors start exploiting weaknesses long before software vendors are able to release a fix.
A mature CTEM program needs a broader response plan.
Depending on the exposure, your response may involve:
Knowing which compensating controls are already in place matters as much as knowing which ones to deploy. Visibility into existing defenses is becoming a core expectation of any mature exposure management program.
Exposures that are identity-related often require configuration changes instead of software updates. Cloud exposures are usually due to misconfigurations, excessive permissions, or exposed services.
With many of the highest-risk findings, software defects aren’t the culprit; they are operational issues.
Automation works well for low-risk, repetitive tasks. Browser patches are a good starting point, letting your team build confidence in agentic workflows before expanding automation to higher-stakes environments.
Business-critical systems and high-impact changes still require human oversight, and that threshold is yours to define.
The goal is to limit risk faster while still having operational control.
The security-to-IT handoff: where do CTEM programs stall?
Many CTEM initiatives fail because they cannot operationalize remediation.
The most common breakdown happens between the security team that identifies an exposure and the IT team that is responsible for fixing it.
Security tools generate findings. IT teams work using ITSM platforms, CMDBs, and operational workflows, but if these systems operate independently, problems will result.
Teams duplicate work, and tickets multiply. Conflicting priorities arise, and remediation slows down.
The orchestration benefit of CTEM is that it creates a common operational framework. Instead of just getting a slew of alerts from many disconnected tools, your remediation teams get a prioritized queue that is based on the true business risk.
That creates several advantages:
Most importantly, it helps you transform exposure management from a reporting exercise into a risk-reduction program that works for your business.
Can you make timely decisions based on information?
The security field has become skilled at detecting vulnerabilities. Frontier AI has accelerated that process for defenders and threat actors alike, and the volume of disclosed vulnerabilities is only going to grow.
The harder capability to build is knowing which of those vulnerabilities represent real business risk to your organization. As discovery accelerates, the gap between what gets flagged and what you actually act on will widen if your program relies on volume-based approaches.
Prioritization is where your exposure management program wins or loses. Closing the right exposures fastest is what positions your organization for what comes next.
About the author Joe Pettit
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, Frontier AI, CTEM)
Enterprise adoption of Claude across teams, workflows, and business functions is happening at a pace unlike virtually any technology before it. While the innovation opportunity is obvious, so are many of the risks. From the exposure of sensitive data and secrets through shadow IT to new attack vectors like prompt injection, security teams need the visibility, governance, and response capabilities to ensure AI innovation is done safely and securely.
SentinelOne® helps organizations comprehensively secure Claude adoption by bringing AI usage directly into the security platforms teams already rely on. This helps protect the entire ecosystem from the underlying infrastructure to the application layer and end-user interactions. By bringing together SentinelOne and Claude, security teams can apply policies to user prompts, ingest Claude activity into the Singularity
AI SIEM for investigation, and utilize frontier AI-powered services to identify real-world risks before attackers can exploit them.
Security and compliance platforms utilize the Claude Compliance API to help organizations monitor AI activity within their existing tools. SentinelOne provides purpose-built Claude Compliance API integrations for its Prompt Security and Singularity AI SIEM offerings.
Scan AI prompts and responses against enterprise policies to flag violations without requiring a browser extension or endpoint agent. This agentless approach helps organizations extend their security coverage to unmanaged devices and external environments. Prompt Security enforces safe use by blocking high-risk prompts and preventing data leakage in real time. Additionally, the platform provides continuous risk assessment for agentic AI by securing Model Context Protocol (MCP) gateway connections between AI applications and known MCP servers.
Ingest audit and activity data directly from Claude rather than treating AI interactions as isolated events. With the integration, security operations center (SOC) teams can correlate Claude activity against existing security telemetry. This allows analysts to incorporate AI usage data into their broader security workflows and improve investigation, detection, and response across all their attack surfaces.
The partnership between SentinelOne and Anthropic extends beyond the Compliance API. SentinelOne has been a participating member in Anthropic’s Project Glasswing and has had early access to Anthropic’s most capable Mythos-class models. By continuously testing these models against real-world security workflows, SentinelOne helps ensure defenses keep pace with the modern adversary. Additionally, SentinelOne recently announced Wayfinder Frontier AI Services, a managed offering that pairs elite human security experts with frontier models, including Anthropic’s Claude Security.
Frontier AI is changing vulnerability discovery, giving both defenders and attackers the advantage of speed and scale. However, raw vulnerability counts rarely map cleanly to real-world risk, as many theoretical exposures are mitigated by existing architectural controls. Wayfinder Frontier AI Services evaluates findings against actual environmental context to deliver an exploitability-grounded prioritization. Instead of treating vulnerabilities in isolation, the service maps how exposures connect into end-to-end attack paths.
The Frontier AI models then provide targeted remediation guidance, including architectural changes or identity controls, designed to break the exploitation chain where it costs the adversary the most. With the service providing a continuous human-and-AI partnership across endpoint, cloud, identity, data, and AI attack surfaces, Frontier AI ensures that organizational security posture remains current as models and threats evolve.
SentinelOne operates from a clear conviction: A safer future for humanity and to give the advantage to those who secure our future. That conviction is what drives how SentinelOne approaches AI security — not as an isolated capability, but as part of the autonomous platform, expert services, and SOC workflows that defenders already use. SentinelOne has collaborated with frontier AI labs for years, including Anthropic, OpenAI, and Google DeepMind. These partnerships inform the capabilities embedded across the SentinelOne platform.
Operating at machine speed is necessary to counter modern threats, rather than relying strictly on manual triage. Over the past quarter, the SentinelOne Singularity Platform autonomously blocked novel zero-day and supply-chain attacks against widely used components, such as LiteLLM, Axios, and CPU-Z. Wayfinder Frontier AI Services takes this operational model further left in the security lifecycle to discover exposures before attackers can leverage them. This multi-model foundation reflects the understanding that no single AI model is the definitive answer for cybersecurity; the advantage belongs to defenders who can orchestrate the right intelligence and validate outputs with human expertise.
This is how SentinelOne enables business growth and innovation safely, giving security teams the ability to say yes to AI adoption while maintaining full control of the risk surface. Stronger protection with fewer incidents and less operational overhead.
Ready to adopt Claude safely across your organization? Connect with SentinelOne to learn how Prompt Security, Singularity AI SIEM, and Wayfinder Frontier AI Services help security teams govern, monitor, and defend AI usage at enterprise scale.
Third-Party Trademark Disclaimer:
All third-party product names, logos, and brands mentioned in this publication are the property of their respective owners and are for identification purposes only. Use of these names, logos, and brands does not imply affiliation, endorsement, sponsorship, or association with the third-party.
Unit 42 explores trends in data theft and extortion, outlining key strategies for organizations as frontier AI models advance.
The post Out of the Crypt: The Evolving Cyber Extortion Economy appeared first on Unit 42.
In the span of four days, the U.S. government announced two parallel sets of agreements with frontier AI companies that together define the two tracks Washington wants to run simultaneously—test AI for national security risks before the public ever sees it, and deploy AI directly on the military's most classified networks.
The Center for AI Standards and Innovation — CAISI, the entity under the Department of Commerce's National Institute of Standards and Technology that inherited the remit of the former AI Safety Institute — announced new agreements with Google DeepMind, Microsoft, and Elon Musk's xAI. These build on renegotiated agreements with Anthropic and OpenAI that date to 2024, updated to reflect directives from Commerce Secretary Howard Lutnick and America's AI Action Plan.
Under the CAISI agreements, the three companies will hand over their frontier AI models to government evaluators before those models are publicly released. The evaluations probe for national security-relevant capabilities and risks.
To conduct a thorough assessment, developers frequently provide CAISI with models that have reduced or removed safety guardrails — a design choice that allows evaluators to probe what a model can do at its ceiling, not what it will do under commercial safety controls. Evaluators from across the federal government participate, coordinated through the CAISI-convened TRAINS Taskforce, an interagency body focused specifically on AI national security concerns.
CAISI said it has completed more than 40 such evaluations to date. The agreements explicitly support testing in classified environments and were drafted with the flexibility to adapt rapidly as AI capabilities continue advancing.
"Independent, rigorous measurement science is essential to understanding frontier AI and its national security implications," said CAISI Director Chris Fall. "These expanded industry collaborations help us scale our work in the public interest at a critical moment."
Fall was appointed to lead CAISI after Collin Burns — a former Anthropic researcher — was reportedly removed from the director role after just four days. The personnel transition at CAISI's top reflects a broader institutional pivot. Under the Biden administration, the AI Safety Institute focused on safety standards, definitions, and voluntary guardrails. Under Trump, CAISI has shifted its emphasis toward AI acceleration and national security capability assessment. The substance of what the evaluators do — probe powerful models before release — has not changed. The framing of why they do it has.
The latest announcement comes four days after the Department of War (formerly Department of Defense) announced agreements with eight frontier AI companies to deploy their models directly on the military's classified networks for operational use.
The companies cleared are SpaceX, OpenAI, Google, NVIDIA, Reflection, Microsoft, Amazon Web Services, and Oracle. The networks in question are classified at Impact Level 6, covering secret-level data, and Impact Level 7, which refers to the most highly restricted national-security systems. The stated objectives are data synthesis, situational awareness enhancement, and warfighter decision support.
The Department of War announcement carries one conspicuous absence that dominates coverage of what it actually means. Anthropic is not on the list. The company that first deployed AI models on Pentagon classified systems — via a Palantir integration under the Maven Smart System contract — is excluded after a dispute over the guardrails governing military and surveillance use of its AI.
The Pentagon had previously branded Anthropic a "supply chain risk," a designation typically reserved for foreign entities posing national security concerns. A March 2026 federal injunction reversed that designation, but it did not restore Anthropic's position as a Pentagon AI vendor. Palantir has pulled its Claude models from its DoD platforms accordingly.
The exclusion has strategic implications that extend beyond one company's contract status. Anthropic's recently released Mythos model — described by Treasury Secretary Scott Bessent as representing a step change in large language model capability — has generated significant attention from U.S. officials and financial sector executives about its potential to supercharge adversarial cyber operations.
The fact that Mythos is not among the models being assessed for classified military use, while simultaneously being cited by senior officials as a capability milestone that warrants concern, creates a gap in the government's stated AI security posture that is difficult to characterize as anything other than a policy contradiction.
Entrar