Defenders Need Models They Control

The Short Version

AI security has a control problem.

Not only a capability problem.

Not only a regulation problem.

A control problem.

On July 27, NVIDIA announced the Open Secure AI Alliance, a coalition with Microsoft, IBM, Hugging Face, the Linux Foundation, Cloudflare, CrowdStrike, Palantir, Cisco, Adobe, DoorDash, Salesforce, SpaceXAI, Thinking Machines Lab, and a long list of other founding members. The alliance says it will build and share open technologies, techniques, and tools to safeguard software and agents in the age of AI.

That sounds like standard industry-consortium language.

There is always a consortium.

But this one has a sharper reason to exist.

NVIDIA points directly to the recent Hugging Face security incident. Hugging Face says it responded to an intrusion driven end to end by an autonomous AI agent system. To reconstruct what happened, it ran LLM-driven analysis over more than 17,000 recorded actions. The awkward part: when Hugging Face first tried commercial frontier APIs, the requests were blocked because incident response required submitting exploit payloads, attack commands, and command-and-control artifacts.

So Hugging Face used an open-weight model, GLM 5.2, on its own infrastructure.

That is the story.

Not "open models good, closed models bad."

Not "safety filters are stupid."

The useful lesson is more operational:

If AI is going to help defend systems, defenders need some AI they can actually control during the incident.

Very inconvenient. The emergency tool cannot require the emergency to look polite.

Update: the same model now has three security profiles

On October 6, Anthropic turned that control problem into a product architecture.

Its expanded Cyber Verification Program gives verified users three different access profiles for Claude's cyber capabilities: Defense Access, Red Team Access, and Specialized Access. All three include Opus 5.5, Sonnet 5.5, Mythos 5.1, and future models. What changes is not the model menu.

What changes is what the model is allowed to do for you.

Defense Access is for vulnerability analysis, malware reverse engineering, incident response, and similar defensive work. Anthropic says companies, nonprofits, universities, governments, critical infrastructure operators, small security firms, open-source maintainers, and individual researchers can apply. It expects many applicants to qualify within days.

Red Team Access is for organizations doing authorized penetration testing and red teaming. The review takes weeks, the operational controls are stricter, and some categories involving physical harm or mass disruption remain blocked.

Specialized Access is for a much smaller group testing critical and safety-sensitive systems, with an in-depth review involving the US government.

This is the next version of the argument in this article.

A model name no longer tells you the model's useful capability.

You also need to know the user's identity, the approved purpose, the safeguard profile, the monitoring policy, and the environment in which the model is operating.

The safety profile is becoming an authorization profile.

Anthropic finally shows the middle layer

The public debate usually gives us two choices.

One: a hosted model with conservative safeguards that may refuse legitimate security work.

Two: an open or local model that the defender can run without asking a provider for permission.

Both choices are real. Neither is enough by itself.

Anthropic's program makes the middle layer explicit: hosted frontier capability with progressively stronger verification and progressively broader authorization.

That is not the same as control through ownership. Anthropic still owns the model, defines the policy, monitors access, and can narrow or withdraw a grant. But it can be a useful form of operational control if the rules are predictable enough for a security team to build around.

The program's internal benchmark makes the distinction unusually visible.

On Anthropic's CyScenarioBench, its public-access safeguards blocked all 50 trials at the first prompt. Under Defense Access, 46 of 50 trials were blocked at some point and four completed. Under Red Team Access, none were blocked; Opus 5.5 completed 34 of 50 trials, essentially matching Anthropic's no-safeguards baseline of 67.6%.

Treat those numbers carefully. This is a vendor-run evaluation with ten challenges attempted five times each, not broad independent validation.

But the product point is still sharp:

Same models. Different access policy. Radically different useful capability.

Trusted access is becoming infrastructure

The interesting part is not the application form.

It is the machinery behind the form.

Anthropic's security requirements turn trusted access into a stack of concrete controls: phishing-resistant MFA, named user or workload identities, short-lived credentials, managed devices, rapid credential revocation, incident reporting, and continuous compliance review.

For Red Team work, organizations also need outbound traffic allow-listing and logging for offensive or agentic workflows. Access is limited to approved users. Compromised credentials have to be revoked within 24 hours. Departing users have to be removed within three business days.

This is much closer to how privileged infrastructure already works.

We do not give production database access to anyone who knows the product name. We bind access to an identity, a role, a scope, a device, and an audit trail. Cyber-capable models are starting to inherit the same design.

Good.

The model is not just software that answers questions anymore. It is a privileged system whose permissions change the work it can perform.

The privacy bargain is unfinished

There is a cost.

Anthropic requires data retention for program monitoring. Existing zero-data-retention exemptions for Fable and Mythos can continue temporarily, and the company says a future Enterprise File Storage option will let customers keep data in customer-controlled cloud storage while preserving program safeguards.

Future is doing important work in that sentence.

Incident responders handle sensitive logs, exploit details, customer systems, credentials, malware samples, and evidence that may be subject to legal or regulatory constraints. A provider cannot credibly offer advanced defensive access while treating data governance as a footnote.

The trade is understandable: broader authorization creates more abuse risk, so the provider wants more visibility. But the teams with the most legitimate need may also have the strongest reasons not to send raw incident data into a retained service.

Trusted access has to earn both halves of its name.

129,000 vulnerabilities need context

Anthropic says partners using its models found at least 129,000 verified vulnerabilities between April and July 2026, with Anthropic's open-source scanning work adding another 5,500 through October. More than 33,000 were categorized as high or critical severity.

Those are company and partner claims based on partial reporting, not an independent census. A vulnerability count does not tell us how many findings were novel, exploitable, patched, duplicated, or useful without human work.

There is some helpful context from a specific deployment. In May, Axios reported that Palo Alto Networks used Mythos to find 75 vulnerabilities across more than 130 products. The company said the system produced working exploits more than 70% of the time in an internal test, but also generated roughly 30% false positives. It required extensive human expertise, customization, and a scanning harness.

That sounds less like magic and more like a powerful security tool.

Which is better.

The useful story is not that Claude autonomously fixed the internet. It is that models are becoming productive enough for serious security workflows, while still requiring expert operators, infrastructure, verification, and remediation.

Control now means knowing which Claude you have

Anthropic's three-tier program does not make open and local models less important.

It makes the stack clearer.

A serious security team may use a local model for sensitive forensics, a general hosted model for ordinary analysis, Defense Access for malware and vulnerability work, Red Team Access for authorized testing, and a specialized provider for the narrowest critical-system work.

That is not fragmentation for its own sake.

It is least privilege applied to AI capability.

The risk is that trusted access becomes a polished gate for large organizations while smaller defenders remain stuck with refusals. Anthropic explicitly includes individual researchers and open-source maintainers in Defense Access, which is promising. The test will be whether the program stays usable after the announcement: predictable reviews, clear appeals, transparent restrictions, and access that does not quietly depend on enterprise purchasing power.

The deeper shift is already here.

The model has not only learned more cyber.

It has acquired a permissions system.

Update: Daybreak is the closed-model version of this problem

Two weeks later, OpenAI has made the same control problem more concrete from the other side.

On August 10, OpenAI expanded Daybreak, its controlled-access program for cyber defenders, and introduced GPT-5.6-Cyber, a cybersecurity-specific model available through Daybreak Red. It also announced a broader Daybreak Cyber Partner Program with security companies and consultancies, including Accenture, IBM, Palo Alto Networks, CrowdStrike, Cisco, Sophos, EY, PwC, Cloudflare, Fortinet, Akamai, and others.

That is not just a product launch.

It is a governance shape.

OpenAI is saying the normal model-access path is wrong for the hardest cyber work. Standard safeguards block too much legitimate incident response, exploit validation, red teaming, and vulnerability research. But simply removing those safeguards for everyone would be reckless. So the answer becomes a permissioned security layer: approved defenders, identity verification, legal attestations, account security, monitoring, scoped authorization, human oversight, partner-operated workflows, and models that are powerful enough to do dangerous work in the right hands.

Keep the Astra distinction clear.

OpenAI says GPT-5.6-Cyber reached its High cybersecurity threshold, not the Critical threshold, under the Preparedness Framework. It also says GPT-5.6-Cyber was not involved in the Hugging Face incident and is separate from the upcoming model work that triggered the Astra pause.

Very tidy. The model now needs a security clearance and a chaperone.

The scary number is also the useful number

The headline number in OpenAI's post is blunt.

On an internal evaluation measuring advanced cybersecurity completion, GPT-5.6-Cyber completed 95.0% of high-risk cyber requests. GPT-5.6 Sol with normal safeguards completed 1.5%. GPT-5.6 Sol through Daybreak Blue completed 2.0%. GPT-5.5-Cyber completed 57.3%.

That is exactly why the product is delicate.

For defenders, refusals are not a minor annoyance. If a security team is validating whether a critical bug can be exploited, rebuilding an attack path, checking a privilege-escalation chain, or understanding how a vulnerability could be used, the model has to engage with material that looks dangerous.

For everyone else, the same reduced-refusal behavior is obviously sensitive.

That is the whole cyber-AI problem in one table.

The capability that makes the model useful to a defender is also the capability you do not want floating around as a casual chat setting.

This is why "defenders need models they control" cannot mean only "download open weights."

Sometimes it means local models.

Sometimes it means hosted frontier models with special access.

Sometimes it means a security partner operating the model inside a bounded service while the customer gets the result rather than raw model access.

The control question is not ideological.

It is architectural.

Trusted access is useful, and also a bottleneck

OpenAI's Daybreak design is sensible in many ways.

Daybreak Blue gives approved defenders access to frontier general-purpose models with cyber safeguards tuned for authorized work. Daybreak Red gives approved defenders access to specialized cyber models for vulnerability research, exploit validation, and security testing. OpenAI says access is controlled through identity verification, account security, monitoring, approved-use restrictions, and legal attestations. It is also pushing safer agent operation: hardware security keys for individual accounts, Codex auto-review mode, scoped permission profiles, sandboxing, monitoring, and clearer authorization boundaries.

Good.

That is the kind of boring operational machinery this article wanted.

But it creates a new market question:

Who gets to be trusted?

Big security vendors, global consultancies, and enterprise platforms will have a path. They have lawyers, customer controls, compliance teams, account managers, telemetry, and enough money to build governed integrations.

What about a hospital security team?

A small municipality?

A nonprofit responding to an intrusion?

An open-source maintainer whose package is being abused?

A regional managed service provider?

A researcher outside the usual partner network?

If the strongest cyber models move into trusted-access programs, the access policy becomes part of the security product. It decides who gets faster defense and who waits outside the gate.

That is not an argument against Daybreak.

It is the governance problem Daybreak now has to solve.

The partner layer changes the business too

The partner program is maybe the most important part.

OpenAI is not only selling a model to security teams. It is trying to insert frontier cyber reasoning into the tools and services defenders already use: managed detection and response, vulnerability triage, red teaming, incident response, patch validation, supply-chain remediation, exposure management, and cloud security workflows.

That is how this becomes real.

Most companies will not operate a specialized cyber model directly. They will experience it through CrowdStrike, Palo Alto Networks, Cloudflare, Sophos, IBM, Cisco, Fortinet, Akamai, EY, PwC, or whichever provider already owns part of their security workflow.

That lowers adoption friction.

It also concentrates power in the middle layer.

If the model is powerful enough that access has to be mediated, then the mediator matters. The partner's logs matter. The customer's visibility matters. The workflow boundaries matter. The human review process matters. The question is not only whether OpenAI trusts the partner.

It is whether the customer can audit what the partner's AI-enhanced workflow actually did.

Cyber defense cannot become:

"A trusted partner's trusted model trusted that the output was trustworthy."

That sentence contains too much trust and not enough evidence.

Open and closed are both control strategies

This is the useful synthesis.

The NVIDIA/Open Secure AI Alliance story showed why defenders need inspectable, adaptable, sometimes-local AI when a crisis contains payloads and logs that hosted models may refuse.

The OpenAI Daybreak story shows why closed frontier models still matter, and why they may need special access paths rather than ordinary product access.

Both can be true.

A serious cyber-AI stack probably needs:

• local models for private forensics and fallback
• open tools for inspectable agent harnesses, logs, model formats, and red-team workflows
• hosted frontier models for high-end reasoning and vulnerability research
• trusted-access programs for sensitive dual-use work
• partner integrations that bring capability into existing security operations
• clear audit trails so customers can reconstruct what happened
• policy that does not leave smaller defenders permanently behind

That is messier than "open good" or "closed safe."

It is also what defense actually looks like.

OpenAI's Daybreak expansion does not contradict the original argument.

It sharpens it.

Defenders need models they control.

Sometimes control means running the model yourself.

Sometimes it means knowing exactly who is allowed to run it for you, under what scope, with what logs, and with what human review before the agent touches anything real.

Guardrails can create asymmetry

Hosted frontier models need safety systems.

That is not optional.

If a general-purpose model can help with exploit chains, malware analysis, phishing infrastructure, credential abuse, lateral movement, and vulnerability discovery, the provider cannot simply let anyone submit anything and hope the user is a defender.

The problem is that incident response looks a lot like offense from the model's point of view.

A security team may need to paste attacker commands.

It may need to analyze exploit code.

It may need to reconstruct how credentials moved.

It may need to summarize malicious infrastructure.

It may need to ask, "What did this payload do, and what should we rotate?"

Those are exactly the kinds of requests safety filters are trained to treat carefully.

That creates a weird asymmetry:

The attacker does not care about provider policy.

The defender does.

Hugging Face described this clearly. Its forensic analysis required feeding real attack artifacts into models. Commercial tools could not reliably distinguish attacker from responder, so the defender's workflow was blocked while the attacker had no equivalent constraint.

That does not mean providers should remove guardrails.

It means serious security teams need a fallback: local models, audited tools, approved internal harnesses, and a playbook that works when the hosted model says no.

In a breach, "please rephrase your malicious payload" is not a workflow.

The alliance is really about the agent stack

The most interesting part of NVIDIA's post is not the founding-member list.

It is this line of argument:

An AI agent is not just a model.

It is models, harnesses, identity, permissions, isolation, guardrails, logs, evaluations, scanners, model formats, patch flows, and secure coding workflows.

That is the right frame.

The old open-versus-closed debate often gets stuck on weights. Can you download the model? Can you inspect it? Can you fine-tune it? Can you revoke it? Can someone strip out the safeguards?

Those questions matter.

But agent security is bigger than weights.

If a coding agent can read a repo, run commands, install packages, open network connections, call APIs, and write patches, then security lives in the whole harness around it. If a defensive agent can analyze telemetry, rotate keys, file tickets, patch code, and isolate workloads, then the model is only one part of the trust boundary.

That is why the alliance is talking about things like identity, safe model formats, multi-model scanning, red-teaming tools, and agent harness research.

NVIDIA says it is contributing open models, weights, data, and agent harness research. Hugging Face is pointing to Safetensors. HPE is contributing around SPIFFE/SPIRE identity. Microsoft is contributing its MDASH multi-model agentic scanning harness. IBM and Red Hat are contributing supply-chain security work.

This is not just "make a chatbot open source."

It is "make parts of the AI defense stack inspectable."

That is much more useful.

Closed models are still necessary

There is a dumb version of this story that says:

"Closed labs failed. Open models saved the day."

Please do not publish that deck.

Closed frontier models are still going to matter for security. They may be stronger at some forms of reasoning, code analysis, vulnerability chaining, summarization, and tool use. They may have better enterprise controls, logging, abuse monitoring, support, legal commitments, and model updates. Many companies will not want to run their own frontier models for every workflow, because most companies do not want to become model infrastructure operators in the middle of a crisis.

Hosted models can be extremely useful.

OpenAI's own incident post says it is bringing Hugging Face into its trusted-access program and supporting its teams in using OpenAI model capabilities to improve defenses. That is a real path too.

The point is not replacement.

The point is resilience.

You do not want one model provider, one policy layer, one API, one refusal behavior, one logging regime, and one external dependency to become your whole incident-response plan.

Security people already understand this. You do not build a serious response program around one vendor button.

AI should not be different.

Use closed frontier models where they help.

Use open and local models where control matters.

Build the playbook before the breach.

Open models are not magically safe

Now the other caveat.

Open models can absolutely make the world more dangerous.

They can be modified.

They can be fine-tuned.

They can be run without provider monitoring.

They can be used by attackers, not only defenders.

They can spread faster than institutions can react.

Anthropic's warning about increasingly capable open-weight models is not imaginary. Once weights are out, you cannot revoke them like an API key. A model that helps a defender analyze attack infrastructure may also help an attacker automate reconnaissance or debug an exploit chain.

That is real.

NVIDIA's argument is not that open models are harmless. Its post explicitly says open models can be misused and that the risks must be managed wherever advanced AI is deployed.

Good.

That is the only serious position.

The question is not whether open models are safe in the abstract.

The question is whether a security ecosystem that denies defenders inspectable, adaptable AI tools is safer than one that gives them controlled access to those tools.

For cybersecurity, the answer is probably no.

Attackers already collaborate.

Defenders need more than a help desk ticket to a frontier lab.

What this means for builders

If you are building software that uses agents, this should change your security checklist.

Do not only ask:

"Which model is best?"

Ask:

What happens during an incident?

Can the security team analyze malicious prompts, tool calls, logs, files, generated code, and attack payloads without being blocked by the model layer?

Can sensitive attacker data stay inside your environment?

Can you run a vetted local model if external APIs are unavailable, too slow, too expensive, or too restrictive?

Do your agent logs show which model did what, which tools it called, which permissions it used, and which external content influenced it?

Can an incident responder replay the agent's actions?

Can you isolate an agent identity the same way you isolate a compromised service account?

Can you rotate the secrets the agent touched?

Can you prove a model artifact did not execute arbitrary code when loaded?

Can your red-team harness test the whole workflow, not just the final answer?

These are boring questions.

Excellent.

Boring is what security looks like when it works.

The policy lesson is subtle

This also matters for regulators.

Yesterday I wrote that the AI race has entered its super PAC era, and open-weight AI is already one of the policy fights underneath that money.

The Open Secure AI Alliance gives the open-model side a sharper argument:

Do not regulate open models only as proliferation risk.

Regulate them also as defensive infrastructure.

That does not mean "no rules."

It means blanket restrictions can backfire. If a hospital, cloud provider, utility, AI platform, defense contractor, or state agency cannot run capable local AI during an incident, it may become more dependent on a few closed providers at the exact moment speed, privacy, and auditability matter most.

That is not obviously safer.

The better policy work is narrower:

• provenance rules for models and datasets
• safety evaluations for high-risk deployments
• legal consequences for malicious use
• support for defensive open datasets and red-team tools
• secure model formats and supply-chain checks
• incident-reporting norms for agent failures
• trusted-access paths that do not leave smaller defenders outside the gate

That is harder than "open good" or "open bad."

So naturally it will fit beautifully on social media.

The bottom line

The Open Secure AI Alliance may become important.

It may also become another logo wall with a few useful projects underneath it.

Both outcomes are possible.

But the reason it exists is real.

AI agents are becoming part of both attack and defense. That means the security stack has to change. Defenders need models they can inspect, adapt, run locally, govern, log, and trust when the system is already on fire.

Hosted frontier models will be part of that stack.

Open models will be part of that stack too.

The hard part is not choosing a tribe.

The hard part is building a defensive ecosystem where the agent can help without becoming the next thing nobody can audit.

Security does not get better because the model is closed.

It does not get better because the model is open.

It gets better when defenders can verify what happened, control what runs, and respond faster than the attacker.