Microsoft and NVIDIA Publish a Joint Playbook for Open-Weight AI Risk

Key points

• Microsoft and NVIDIA have published a joint paper, Risk Management for Open-Weight Models in Enterprise, built around a five-category risk taxonomy covering Cybersecurity, Data Protection, Content, Human-AI Interaction and Bias.
• The guidance maps to the NIST AI Risk Management Framework and ISO standards, and is pitched as the first in a planned series.
• Microsoft Foundry's agent guardrails, which inspect user input, tool calls, tool responses and final output, remain in preview and are not recommended by Microsoft for production workloads.
• Foundry's built-in evaluators cover coherence, fluency, textual similarity and safety, and can be paired with custom evaluators and automated red teaming.
• Microsoft and NVIDIA say responsibility for safeguards shifts to the customer when enterprises run their own open-weight deployments rather than a managed service.

Microsoft and NVIDIA have put out a joint paper telling enterprises to stop arguing about whether an AI model is open or closed, and start arguing about what it is actually being used for.

The paper is called Risk Management for Open-Weight Models in Enterprise. Open-weight models are AI systems where the company that built them publishes the internal numbers, called weights, that make the model work. A customer can download such a model, inspect it, modify it, and run it on their own servers rather than calling someone else's cloud. That freedom is the whole point. It is also the whole problem.

What does the joint paper actually say?

Weight openness alone does not make a model risky. Risk depends on the model, the job it is doing, where it runs, and what safeguards sit around it. A chatbot that helps staff draft internal memos is not the same risk as the same model wired into a customer-facing booking system.

To give teams a common vocabulary, the authors group risks into five categories: Cybersecurity, Data Protection, Content, Human-AI Interaction and Bias. The paper is explicit that this is a starting taxonomy rather than a deployment checklist, and it leans on the NIST AI Risk Management Framework and ISO standards rather than inventing a new rulebook. We first covered the NIST AI RMF on 13 July 2026, when Microsoft published its own rules for AI use in security work.

Lead authors are Andrew Berkley and April Chen at Microsoft, alongside Michael Boone, Eileen Long and Arun Rao at NVIDIA. The announcement went out through the Microsoft Security Response Center blog.

How does Microsoft Foundry fit in?

Foundry is Microsoft's platform for building and deploying AI models and agents, and it is where most of this guidance is meant to be applied in practice. It ships with built-in evaluators that score a model's answers for coherence, fluency, textual similarity and safety. Teams can also write their own.

On top of evaluation, Foundry offers guardrails that watch for harmful content at four points: the user's prompt, the action an agent proposes to take with a tool, the data that tool sends back, and the final answer handed to the user. Hosted agents can also be fenced in with network egress controls, which limit the outside servers an agent is allowed to contact.

One detail worth flagging: Microsoft's own documentation states plainly that the agent guardrails, tool-call and tool-response controls, and network egress controls are all in preview, and that preview features are not recommended for production workloads. Any team reaching for these controls should check that status for their region and model before relying on them for anything a regulator cares about.

Who is on the hook when something goes wrong?

The customer, more than before. When an enterprise uses a model through a managed service, the provider handles most of the safety plumbing. When that same enterprise downloads an open-weight model and runs it on its own infrastructure, the content filtering, monitoring, human review, and input and output checks all become its problem.

The paper's blunt point is that model-layer evaluation is not enough. A safe model inside an agent with broad tool permissions and loose data access is not a safe system. Future papers from the two companies are promised on the runtime and application layers.

For now, the useful thing here is less the taxonomy and more the admission from two of the largest AI vendors that running an open-weight model in production is a security engineering job, not a procurement one. Teams that learned that lesson the hard way can read what happened to Nvidia's GPU monitors last week for a concrete illustration of what loose infrastructure controls actually cost.