Microsoft and NVIDIA Publish Open-Weight Model Risk Guidance and State That Evaluating a Model Does Not Establish the Safety of an Agent, October 2026

Microsoft and NVIDIA say a model evaluation does not establish the safety of an agent built on it. Approval records that stop at the model leave permissions and runtime without an owner.

A compliance professional and technology risk analyst review policy and audit documents. — Compliance

On October 16, 2026, Microsoft and NVIDIA published Risk Management for Open-Weight Models in Enterprise, the first in a planned series of joint resources. The paper introduces a shared taxonomy of five risk categories: Cybersecurity, Data Protection, Content, Human-AI Interaction, and Bias. Microsoft says enterprises should connect relevant risks to evaluations, mitigations, and accountable owners, and the paper draws on ISO standards and the NIST AI Risk Management Framework. Microsoft states that weight openness alone does not determine risk, that responsibility for safeguards depends on the service and deployment configuration, and that evaluating a model alone does not establish the safety of an agent or application. The first paper focuses on the model layer.

GOVERNANCE IMPLICATION

Microsoft's post ties each identified risk to a control and an accountable owner, and states that where a safeguard sits depends on the deployment. An organization that runs its own open-weight deployment may take on controls that a managed service would otherwise provide. The post says evaluating a model alone does not establish the safety of an agent or application, and lists permissions, data access, tools, runtime, and operational controls as what teams must also assess. The first paper focuses on the model layer, so the layers where agents act are deferred to later work in the series.

SCENARIO

Hypothetical: A hospital network approves an open-weight model after a clean evaluation, then deploys it inside an agent with write access to a scheduling system. The approval record names the model and its evaluation results. It does not name who accepted the risk of the agent's permissions.

THE GOVERNANCE QUESTION

If the model-layer evaluation passes, who owns the evidence that the agent built on that model, with its permissions, tools, and runtime, is safe to operate?

CONTROL GAP

Approval records anchored to a model evaluation do not capture the agent's permissions, tools, and runtime, which the post says teams must assess separately.

REGULATORY RELEVANCE

NIST Ai RMF

ISO 42001

PRIMARY SOURCE

Managing open-weight model risk in enterprise deployments

Michael Scovetta, Microsoft

October 16, 2026

Read the primary source ->

Read the next intelligence note.

Back to Compliance

JUNE 2, 2026

Agents

Microsoft Agent Control Specification Brings Deterministic Runtime Enforcement, Leaving the Authorization Decision Upstream, June 2026

On June 2, 2026, Microsoft announced the Agent Control Specification (ACS) and ASSERT at Build 2026, authored by Sarah Bird on the Microsoft Foundry Blog. ACS is an open industry specification, part of the Agent Governance Toolkit, that places deterministic safety and security controls at five validation checkpoints in an agent's lifecycle: input, LLM, state, tool execution, and output. Controls are expressed as portable, versionable, auditable policy and are designed to work across any agent framework. ASSERT, a separate open-source project, converts written policies into executable evaluation scenarios. ACS launched with customer and partner endorsement including KPMG, Zscaler, IBM, and Arize AI.

Read note ->

<- Back to all intelligence notes