Devlery
Blog/AI

No AI model license, but a 30-day security testing window

Trump’s new AI cybersecurity order avoids mandatory model licensing while creating a 30-day clearinghouse and a voluntary frontier model cyber evaluation path.

No AI model license, but a 30-day security testing window
AI 요약
  • What happened: The White House published the Promoting Advanced Artificial Intelligence Innovation and Security executive order on June 2, 2026.
    • The order gives agencies 30 days to create an AI cybersecurity clearinghouse and 60 days to design a classified cyber benchmark process for covered frontier model decisions.
  • Boundary line: The order says it does not authorize mandatory AI model licensing, preclearance, or permitting.
  • Builder impact: Frontier model release checklists may need cyber benchmark evidence, government early-access controls, and coordinated vulnerability disclosure paths.
    • The framework is voluntary, but critical infrastructure customers may still ask vendors for the same evidence during procurement and security review.
  • Watch: The practical rules depend on follow-on work from Treasury, NSA, CISA, NIST, OMB, and OPM due within the next 30 to 60 days.

The White House published the executive order Promoting Advanced Artificial Intelligence Innovation and Security on June 2, 2026. It is the revised version of the AI and cybersecurity order that was delayed before signature on May 21. The disputed question in May was whether the U.S. government would review frontier models before release. The public order narrows that idea. It says the administration is not creating mandatory licensing or preclearance for AI models, while still creating two operational paths: an AI cybersecurity clearinghouse and a voluntary cyber evaluation framework for covered frontier models.

That distinction matters more than the politics around the order. The document does not immediately force model developers to ask permission before launch. It does, however, put 30-day and 60-day deadlines on the federal machinery that could sit next to frontier model launches, vulnerability discovery programs, and critical infrastructure security reviews. For AI labs and security teams, the practical question becomes narrower: who gets pre-release access, under what confidentiality terms, against which cyber benchmarks, and how quickly can findings be validated and patched?

The 30-day clearinghouse is about patch speed

The first track is an AI cybersecurity clearinghouse. Section 2(d) directs the Treasury Secretary, in consultation with the National Cyber Director, the NSA Director inside the Department of War, and the CISA Director at DHS, to establish the clearinghouse within 30 days. Its job is not just to discuss AI security. The order names software vulnerability scanning, discovery, validation, remediation prioritization, and patch distribution coordination.

The White House fact sheet frames the same work around real infrastructure operators: rural hospitals, community banks, local utilities, and other critical infrastructure organizations that may need access to AI-enabled cybersecurity tools and services. If a vulnerability discovery model scans old hospital software or utility systems, the hard part is not only finding a bug. The hard part is disclosure timing, exploit reproduction, vendor notification, patch windows, downtime risk, and deciding whether a vulnerable system can safely remain online while a fix is prepared.

Flow from the White House executive order's 30-day clearinghouse deadline to the 60-day frontier model framework.

The word "clearinghouse" sounds softer than regulator, but the listed functions are operational. AI can create more vulnerability candidates than maintainers, vendors, and infrastructure operators can triage. Without deconfliction, several scanners can report overlapping findings against the same codebase, or an open-source maintainer can receive duplicate low-quality reports from different AI pipelines. The order tries to connect AI-driven discovery with human patch distribution capacity.

For product teams building AppSec tools, code scanning agents, exploitability triage systems, or patch prioritization assistants, that means evidence quality becomes a market requirement. A report that says an AI model found "many high-severity issues" is not enough for a clearinghouse or a critical infrastructure buyer. Useful reports need affected versions, reproduction steps, severity rationale, duplicate handling, exploitability proof, remediation suggestions, and regression tests.

Covered frontier models move into classified cyber benchmarks

The second track is the covered frontier model process. Section 3 gives agencies 60 days to create a classified benchmarking process for advanced cyber capabilities of AI models. The process will help decide which models meet the threshold for covered frontier model status under the executive order. The designation decision is assigned to the NSA Director, in consultation with the National Cyber Director, APST, CISA, and Department of War representatives. NIST participates through Commerce coordination.

This moves part of model evaluation outside the public leaderboard ecosystem. Developers are used to seeing model releases described through MMLU, SWE-bench, GPQA, Terminal-Bench, or internal coding benchmarks. Advanced cyber capability is harder to publish safely. Evaluations can involve exploit generation, vulnerability discovery, malware assistance, privilege escalation planning, or tool-using agent behavior. A public scorecard can become a capability map for attackers.

The order does not yet say where the threshold sits. It does not clarify whether the same process applies to general-purpose frontier models, cyber-specialized fine-tunes, agent wrappers around existing models, hosted APIs, or open-weight releases. It also does not say how much of a classified benchmark result can be shared back with developers. Those unanswered questions are now due inside the 60-day framework.

For AI labs, the release checklist is likely to become more specific even before a formal rule exists. Teams will need a defensible view of whether a release candidate could be considered covered. They will need cyber capability evaluation artifacts that can be summarized externally without exposing the full red-team corpus. They will need to separate ordinary code generation scores from tool-assisted cyber tasks, because a model that looks similar on a public coding benchmark may behave differently when given browser, shell, repository, or MCP tool access.

Voluntary early access is not the same as no pressure

Section 3(b) asks the government to design a voluntary framework with AI developers. Under that framework, a developer can work with the government to determine whether a model under development qualifies as a covered frontier model. For covered models, the developer may provide government access for up to 30 days before the model is made available to trusted partners. The order lists confidentiality, cybersecurity, insider-risk, intellectual-property protection, use, and nondisclosure requirements as conditions for that access.

Section 3(c) then draws the legal boundary. The order says this clause must not be interpreted as authorizing mandatory governmental licensing, preclearance, or permitting requirements for developing, publishing, releasing, or distributing new AI models. In other words, the public text does not create a rule that every frontier model must receive government approval before launch.

The market effect can still be real. A voluntary process can become a practical checkpoint if federal buyers, critical infrastructure customers, cloud marketplaces, insurers, or enterprise risk committees ask whether a model has gone through the framework. A lab may not need legal permission to launch, but it may need evidence to sell into regulated environments. That evidence can include cyber benchmark summaries, early-access participation, mitigation records, disclosure coordination, and customer-facing security notes.

The 30-day access window also creates engineering work. A model developer has to decide whether evaluators see an API endpoint, an internal deployment, a frozen model snapshot, or a constrained sandbox. It has to protect weights, prompts, logs, tool calls, red-team outputs, and evaluation transcripts. It has to decide how to classify findings from the review: release blocker, mitigation note, customer notice, product safety change, or accepted residual risk.

Federal cyber defense gets pulled forward

The order does not stop at model releases. Sections 2(a) and 2(b) prioritize cyber defense for National Security Systems and Department of War information systems within 30 days. Section 2(c) directs DHS, through CISA, to issue Binding Operational Directives and guidance for civilian federal government information systems. The guidance is expected to strengthen AI-enabled defensive tools and expand access for agencies, state and local authorities, and critical infrastructure operators.

That language is a demand signal for the security market. Vulnerability discovery models, code scanning agents, patch prioritization systems, exploitability triage tools, log correlation agents, and incident response assistants can all fit under "AI-enabled defensive tools." But government and infrastructure environments add procurement conditions that are stricter than a normal SaaS demo. FedRAMP posture, data residency, audit logs, model output retention, prompt injection handling, secret exposure controls, and human approval paths can become part of the buying checklist.

The workforce clauses point in the same direction. OMB has 30 days to identify federal grant funding that can support developers of advanced AI vulnerability detection technologies. OPM has 60 days to expand United States Tech Force Information Cybersecurity Specialist hiring and placement pathways. The document recognizes that a model does not close a vulnerability by itself. Someone still has to triage scanner output, contact vendors, sequence patches, verify fixes, and keep critical services running.

AI agent misuse becomes an enforcement priority

Section 4 adds explicit law enforcement language for AI-enabled computer misuse. The Attorney General is directed to prioritize enforcement against people who use AI to gain unauthorized access to computer systems, damage systems, steal data, or use AI agents to access information for further criminal activity. The listed statutes include 18 U.S.C. 1028, 1030, 1343, and related federal laws.

This does not create a new criminal statute. It tells the Department of Justice to prioritize existing authorities when AI is used in unauthorized access or related fraud. The explicit mention of AI agents still matters for developers. Products that automate browsers, code hosts, SaaS admin panels, databases, internal tools, or shell commands need clearer abuse monitoring, customer terms, and incident evidence. "The agent did it" is unlikely to reduce risk when the user directed or enabled the unauthorized action.

Logs become more important in this setting. Tool invocation history, user identity, target systems, permission grants, external request metadata, and output hashes can help distinguish legitimate automation from abuse. Privacy and customer confidentiality limit what can be collected, but a product with no useful audit trail will struggle to investigate both real incidents and false claims.

The May delay did not disappear

This order is best read against the May 21 delay. The earlier question was whether the government would get a 90-day look at frontier models before release. The June 2 public text answers part of that debate: no mandatory license, no mandatory preclearance, no permitting requirement. At the same time, it leaves a government evaluation channel in place through classified benchmarks, covered frontier model designations, and up to 30 days of voluntary early access.

TechRadar summarized the June 3 response as a request for AI companies to voluntarily allow advanced cyber capability testing. That framing is accurate but incomplete for engineering teams. The order also creates a vulnerability coordination function, links AI defense tools to critical infrastructure operators, directs hiring and grant activity, and gives DOJ explicit language around AI agents in unauthorized computer access.

For AI labs, the near-term preparation is concrete. Cyber capability evaluations should not remain only as internal red-team memos. Teams need external summaries, evidence maps, and a way to explain what was tested without leaking the benchmark. Release candidate access should be designed around the 30-day window: access control, logging, retention, nondisclosure workflow, insider-risk controls, and review escalation. If the model can use code execution, browser control, shell tools, or MCP servers, the eval scope should describe which tool capabilities were enabled.

For platform and security vendors, the follow-on guidance will matter more than the order's headline. CISA directives, Treasury clearinghouse details, NSA benchmark thresholds, and NIST coordination will determine which artifacts customers request. A vendor that can already produce reproducible vulnerability evidence, patch priority reasoning, and audit-friendly model behavior records will be better prepared than one that only markets AI scanning speed.

The order's real interface is between model speed and patch speed. The administration says it is not turning frontier AI into a licensing regime. It is instead building points of contact among AI labs, national security agencies, CISA, critical infrastructure operators, and vulnerability responders. If AI finds vulnerabilities faster than people can validate and patch them, defensive AI can also create a faster-growing list of unresolved weaknesses. The clearinghouse and the 30-day early-access path are attempts to narrow that gap before the next generation of cyber-capable models is broadly available.