Q4-2026 release: Open-weight model controls and stronger third-party testing

Since the July 2026 release of AIUC-1, the world has seen the first autonomous intrusions carried out by agent swarms with the HuggingFace incident, open-weight models such as GLM-5.3 reaching Mythos-level cyber capabilities and numerous autonomous hacks of governments, critical infrastructure, and financial institutions. Securing these risk vectors has been the focus of the Consortium for this quarterly update.

Executive summary of standard updates

This quarter’s standard update led to 5 new requirements, 5 new controls and 3 retired requirements. In addition, new docs provide technical details on the AIUC-1 third-party testing process and guidance on agent developer vs. deployer responsibilities.

Three areas of focus:

1. Open-weight model deployments: new controls governing the verification, testing and evaluation of open-weight models before deployment.
2. Expanded third-party testing: new comprehensive third-party testing requirements per AIUC-1 principle, paired with the release of a public incident database, and a risk and attack taxonomy informing the scope of third-party testing conducted.
3. Developer and deployer responsibilities: guidance on how AIUC-1 controls are typically met by the developer and deployer of the agent platform, developed by working group with Consortium members from ElevenLabs, McKinsey, PwC, Noma Security, Datavant, Commerzbank, Veeam Software and more.

More than 100 AIUC-1 Consortium members contributed to the standard update this quarter. Contribution involved CISO roundtable discussions, technical working sessions with security and GRC practitioners, a working group charged with drafting Developer and Deployer Responsibility Guidance. As with previous updates, all standard changes go through a final peer-review.

Secure Deployment of Open Weight Models

With AI agents now in production at most organizations, attention is turning to cost, deployment flexibility, control over data, and transparency into model behavior, driving open-weight model pilots and deployments. The security of these models varies widely by provider, and whatever security does exist only lives in the weights, which can be quickly eroded through fine-tuning, quantization, or a change in inference engine.

This quarterly update introduces three supplemental controls covering the safe use and deployment of open-weight models:

• Pre-deployment testing of model changes: Safety evaluations and guardrail test suites are re-run after any major weights update or inference engine change, with results compared against the prior model's baseline (C002.4).
• Model source, integrity and licence verification: Weights are obtained from a vetted registry, integrity-checked, screened for known issues, and confirmed to be licensed for the intended use (E006.2).
• Cyber evaluations on modified open-weight models: Cyber misuse evaluations are re-run on the modified model, or output classifiers for exploit and malware generation are added (F001.2). Cyber evaluations are especially needed now that open-weight models are known to have reached Mythos-level cyber capabilities.

These supplemental controls will automatically apply to any organization deploying and certifying AI systems built on top of open-weight models.

Many thanks to Base Labs, Baseten's research lab building the frontier safety stack for open-source models, who collaborated with our consortium on the new controls. We expect continued focus on open-weight models and plan to expand this technical collaboration.

Expanded Third-party Testing Requirements

Gains in model capability and harness sophistication raise the cost of untested high-risk deployments, and the case for third-party validation. AIUC-1 is grounded in technical testing and requires every certified agent to be evaluated on a quarterly basis. As the ecosystem of AIUC-1 technical evaluators grows, we have released public documentation providing visibility into the taxonomies behind technical testing and updated the standard’s third-party testing requirements. The newly released public documentation involves AIUC-1’s:

1. Incident database: updated as real-world incidents occur, and analyzed for new risks and attacks.
2. Risk and attack taxonomies: documented risks and attacks inform the range of technical tests run on the AI system. For example, one evaluation may test for credential leakage (Data & Privacy risk) through a direct multi-turn conversation (Intended use attack). The exact distribution of risks and attacks is scoped to what could reasonably occur for each AI system, with typical evaluations covering 1,000-3,000 simulations.

Alongside the documentation, third-party testing is now consolidated into one requirement for each of the AIUC-1 principles:

1. Data & Privacy: A009: Third-party testing for data & privacy risk
2. Security: B001: Third-party testing for security risk
3. Safety: C010: Third-party testing for safety risk
4. Reliability: D004: Third-party testing for reliability risk
5. Accountability: E018: Third-party testing for accountability risk

The appointed independent evaluator is responsible for defining relevant risks to the evaluated AI system, and testing the system’s robustness to the risks as defined in the AIUC-1 risk taxonomy, and repeating this on a quarterly basis.

New Guidance for Agent Developers vs. Deployers

AI agents are rarely built and deployed by a single organization. In many cases the developer of the agent platform, and the deployer running it on their own data and workflows are different organizations, and responsibility for providing and enforcing the necessary agent controls is split between them.

New guidance clarifies how responsibility for meeting AIUC-1 controls are commonly held between the two parties. The responsibilities outlined in the guide are not legally binding, but helps:

• Developers of configurable agent platforms (e.g. Cursor, Sierra, ElevenLabs) show customers which safety and security controls are built-in, and which controls the customer must configure.
• Deployers building agents on those platforms know which controls they inherit, and which controls remain theirs to configure, implement and evidence.

The guide was developed by a Technical Working Group of Consortium members from organizations including ElevenLabs, McKinsey, PwC, Noma Security, Datavant, Commerzbank, Veeam Software and more.

Across the 78 core controls in the 2026 Q4 standard, where a developer-deployer relationship exists we typically find:

• 33 are met by the developer - e.g. core guardrails, technical controls, policies for training on customer data.
• 40 are met by the deployer - e.g. custom guardrails, data access, tool access, policies for human-in-the-loop.
• 5 are met by the independent evaluator - the technical testing of the agent’s core risks.

The exact split of controls depends on the exact platform agents are deployed from.

Download Guidance

More on the Standard Changes

Read more about the process behind the quarterly updates of AIUC-1 here.

Thank you to the 100+ CISOs, security leaders, GRC practitioners, auditors and academics who took part in this quarterly update process.

All updates to the standard are documented transparently, with the full changelog accessible here.