THE SIGNAL IN ONE SENTENCE
Palo Alto Networks has launched a subscription service that continuously attacks a customer's own systems, with permission, to find weaknesses before somebody less polite does. Unit 42 Continuous Frontier AI Defense combines Anthropic's Claude Mythos 5, OpenAI's GPT-5.6-Cyber, open-weight models, Palo Alto threat intelligence and human offensive-security experts. A proprietary harness is supposed to route different jobs to the model best suited for them. The service begins by agreeing on scope, maps exposures across web applications, APIs, cloud infrastructure, source repositories and network assets, tries to prove which paths are actually exploitable, sends recommended fixes into ticketing systems and automatically tests again as the environment changes. That is a meaningful shift from the annual penetration test that arrives as a handsome PDF shortly before the software changes again. It is also a machine-speed way to create machine-speed mistakes. A continuous red team can hammer the wrong production endpoint, touch regulated data, trigger fraud controls, expose a secret inside a model context or generate exploit code that outlives the authorized test. Palo Alto says Unit 42 experts verify findings and attack paths. It does not publish the service's false-positive rate, missed-vulnerability rate, rate of safe exploit validation, time to remediation, customer incident reduction or comparison with a conventional expert team. The company reports six months of development, more than 100 customer engagements and $17 million invested in research and methodology. It says an internal deployment found what it calls a year's worth of exposures in three weeks, and that its earlier Frontier AI Exposure Analysis found exposures in every assessed customer, with 37 percent rated high or critical. Those are company-defined results from company engagements, not an independent effectiveness study. Finding something everywhere can show broad coverage. It can also show a generous definition of exposure. The plain signal is that multi-model red teaming is becoming a managed production system. Buyers should evaluate it like one. Ask what is in scope, which model performed each step, what evidence made an exploit real, who approved dangerous actions, how findings were deduplicated, whether the fix held and whether the service reduced incidents instead of merely producing more tickets.
01
WHAT ACTUALLY CHANGED
Palo Alto Networks announced Unit 42 Continuous Frontier AI Defense on September 22 as a worldwide annual subscription service for continuous offensive security testing.
The service uses a proprietary multi-model harness built around Anthropic Claude Mythos 5, OpenAI GPT-5.6-Cyber and open-weight models. Subscription options vary with the models selected.
Palo Alto says the harness routes security tasks to models according to their strengths, intended coverage and cost. It does not publish the routing policy, model-level task share, fallback behavior or model-by-model contribution to findings.
The stated coverage includes first- and third-party web applications, APIs, cloud infrastructure, source-code repositories and network assets.
The workflow is scope, discover, validate, remediate and improve. Unit 42 says experts verify AI findings and chain them into end-to-end attack paths before recommendations reach customer ticketing systems.
The company describes a full-estate baseline followed by ongoing testing as applications and infrastructure change. The public materials do not define how quickly a change is detected or retested.
Recommendations can include prioritized fixes, code-level guidance and virtual patches. A suggested fix or compensating control is not the same as a deployed and verified repair.
Palo Alto says it developed and validated the approach over six months, invested $17 million in research and methodology and used more than 100 Unit 42 customer engagements. These are company disclosures.
During an internal deployment, Palo Alto says the approach found a year's worth of exposures in three weeks. The company does not define the historical baseline, severity mix, asset count, duplicate handling or proportion confirmed as exploitable.
Palo Alto says its Frontier AI Exposure Analysis found exposures in 100 percent of assessed customers and that 37 percent were high or critical. The release does not identify the number of customers behind that percentage, the severity standard or independent validation.
The company says most findings originated in first-party applications and more than two in three third-party application exposures had no known CVE. A missing CVE can indicate a previously uncatalogued weakness, a configuration problem or a finding not represented by the CVE system.
Reuters separately reported the launch, named the Anthropic, OpenAI and open-weight model mix and confirmed that global annual pricing varies with the selected models.
The launch material does not publish precision, recall, false-positive, exploit-safety, remediation, recurrence, breach-reduction or return-on-investment measurements.
02
WHY THIS MATTERS
A yearly penetration test is a snapshot of a moving target. Code, cloud permissions, dependencies, APIs and business processes can change the next morning. Continuous testing tries to shrink the time between a new exposure and a verified finding.
Different models can genuinely cover different blind spots. One may read code well, another may reason across identity and cloud configuration, and a smaller local model may handle cheap repetitive checks. A harness can use that diversity instead of betting the estate on one model.
Multi-model does not automatically mean better. Correlated training data can produce correlated mistakes, routing can send the wrong task to the wrong model and the same flawed context can contaminate every model in the chain.
Discovery and validation should stay separate. A model can generate many plausible weaknesses. Proving that one is reachable, exploitable and consequential requires bounded evidence, careful execution and often a human who understands the customer's business process.
The scope contract is the first safety control. A hostname list is not enough when applications call shared services, production and test accounts overlap, and cloud identities can cross projects. The service needs explicit assets, identities, methods, hours, data classes and stop conditions.
Continuous offensive work can become its own source of operational risk. An aggressive test can corrupt data, create costs, lock accounts, trigger incident response, degrade availability or leave an artifact that a real attacker later finds.
Gated cyber models introduce another control boundary. Customers need to know which provider receives their code or telemetry, what is retained, whether prompts train models, where processing occurs and what happens when a provider changes access rules.
Open-weight models may allow more controlled deployment, but the public materials do not identify which models, licenses, hosting arrangements or security hardening are used. Downloadable weights do not answer the data-governance question by themselves.
Human verification is valuable only if its role is measurable. A service should state which findings humans reviewed, what they rejected, which exploit steps required approval and how disagreements between experts and models were resolved.
Finding an exposure in every customer sounds impressive until the denominator arrives. Large enterprises almost always contain outdated software, excessive permissions or configuration drift. Buyers need severity, exploitability, novelty and business impact, not a perfect batting average against a very broad category.
The vendor incentive deserves daylight. Palo Alto can discover a weakness, recommend a virtual patch and sell products that implement the defense. That integrated path can be convenient, but customers need independent validation and alternatives so the test does not become a sales funnel wearing safety goggles.
The right success measure is not findings per week. It is the share of important attack paths safely confirmed, fixed within target time, independently retested and prevented from recurring, followed by a measurable reduction in incidents or exposed time.
A continuous red team changes security work. It can move experts away from repetitive enumeration and toward scoping, adversary reasoning, evidence review and remediation. It can also bury teams under tickets if prioritization and deduplication are weak.
03
WHERE IT COULD HELP
- Write a rules-of-engagement document that names every permitted asset, identity, test technique, data class, production constraint, time window and emergency stop contact.
- Issue short-lived test credentials with the least access required, isolate them from normal administrator accounts and revoke them automatically at the end of each exercise.
- Require approval before exploit steps that can change data, send messages, create accounts, move laterally, increase cloud cost, affect availability or touch regulated information.
- Tag every finding with the discovering model, model version, prompt and tool route, evidence, human reviewer, affected asset, confidence and final disposition.
- Measure confirmed true positives, false positives, false negatives from seeded tests, duplicates, safe validation rate, review time and remediation time by model and asset class.
- Use canary environments and deliberately seeded vulnerabilities to test whether the service finds known problems without damaging production or wandering beyond scope.
- Separate discovery from procurement. Let an independent reviewer confirm high-cost remediation and allow competing controls when Palo Alto products are recommended.
- Keep exploit artifacts in a controlled vault with retention limits, access logs and automatic cleanup from customer systems after validation.
- Connect findings to the software owner and deployment pipeline, then retest the exact path after a fix instead of closing a ticket when code is merely proposed.
- Track recurrence. If the same permission, vulnerable pattern or dependency returns, fix the template, policy or build process that keeps recreating it.
- Publish a customer dashboard that distinguishes discovered, human-validated, safely exploited, remediated, retested and accepted-risk findings.
- Test the red-team service itself for prompt injection, poisoned repositories, deceptive issue text, malicious dependencies and attempts to make the agent attack an out-of-scope target.
- Review model-provider data terms, regional processing, retention, training use, incident notice and deletion before sending code or production telemetry through a gated model.
- Judge renewal on reduced exposure time and verified risk reduction, not on the largest pile of findings or the scariest demonstration.
KEEP A HAND ON THE WHEEL
This is a vendor announcement for a newly available service, not an independent trial. Palo Alto Networks reports six months of development, more than 100 Unit 42 engagements, $17 million invested, a year's worth of internal exposures found in three weeks, exposures in every assessed customer and 37 percent rated high or critical. The company does not publish the engagement denominator behind every percentage, asset counts, customer selection, severity rubric, comparison group, seeded-test results, false positives, missed findings, exploit-safety incidents, time to remediation, recurrence or breach reduction. The phrase a year's worth of exposures is not a standard measurement without the prior discovery rate and definition of exposure. Continuous does not necessarily mean every asset is attacked at every moment, and near real time is not accompanied by a service-level target. Recommendations and virtual patches are not proof that fixes were deployed or durable. The public pages do not disclose the model-routing policy, exact open-weight models, customer-data path, human-review rate, permission gates or rules for production exploitation. Watch for a technical methodology, independent customer results, safe-testing controls, model and human contribution data, pricing details, conflicts policy, remediation verification, incident reports and evidence that continuous testing shortens exploitable exposure without creating a second attacker inside the network.
04
TERMS WORTH KEEPING
SOURCES AND VERIFICATION STATUS
This article was written from the materials below. Product claims and dates were checked against those sources on September 23, 2026.
PUBLICATION RECEIPT: Revision 1. Published September 23, 2026.
THE PUBLICATION ENGINE
WANT A SIGNAL OF YOUR OWN?
We build source-grounded publications, private briefings, and editorial systems for organizations with something useful to say.
WORK WITH US