Microsoft says Azure AI Foundry scans high-visibility AI models for malware, backdoors, and tampering

Microsoft has outlined how it secures generative AI models hosted on Azure AI Foundry, saying high-visibility models go through security scanning before release and run inside Microsoft-controlled Azure boundaries. The company’s description focuses on a familiar idea for security teams: treat AI models like third-party software, not magic artifacts that need an entirely separate trust model.

The core message from Microsoft is simple. Models on Azure AI Foundry run as software in Azure Virtual Machines and inherit Azure’s existing protections, while Microsoft applies extra checks to selected models before they reach customers. Those checks include malware analysis, vulnerability assessment, backdoor detection, and model integrity review.

That is important because the risk Microsoft describes does not come from a model “escaping” on its own. It comes from the possibility that a model or its surrounding package could contain malicious code, hidden functionality, or tampered components, much like any other software supply chain risk. Microsoft says Azure’s zero-trust approach already assumes workloads running inside Azure are not safe by default.

There is one important nuance here. The official Microsoft blog that lays out these safeguards was published on March 4, 2025, not this week. So the better framing is not that Microsoft has unveiled an entirely new framework today, but that its published Azure AI Foundry security model continues to draw attention as enterprises weigh the risks of third-party and open models.

Microsoft also says customer data stays inside Microsoft’s trust boundary. In its own wording, Azure AI Foundry and Azure OpenAI Service are hosted on Microsoft servers, with no runtime connections to model providers, and customer data is not used to train shared models. Microsoft also says customer fine-tuned models stay in the customer’s tenant.

That hosting design matters for companies that worry about where prompts, logs, and outputs go once an external model enters the workflow. Microsoft’s claim is that the runtime environment stays under Microsoft control rather than calling back to the original provider during inference.

The company has pointed to DeepSeek R1 as an example of how it handles higher-scrutiny models. Microsoft said when it added DeepSeek R1 to Azure AI Foundry, the model had undergone red teaming, safety evaluations, automated behavioral assessments, and security reviews. A separate Microsoft Security post made a similar point, saying DeepSeek R1 received rigorous red teaming and safety evaluation like other models hosted in the service.

Microsoft does not claim these checks eliminate all risk. In fact, its own security blog says no scans can detect every malicious action, and it explicitly tells customers to make their own trust decisions about model providers just as they would for any other third-party software library. That caveat matters, because it places the final burden on enterprise governance, testing, and deployment controls rather than on Microsoft scanning alone.

This is where Azure AI Foundry’s broader security tooling comes in. Beyond the platform-side model checks, Microsoft offers AI red teaming capabilities that customers can use during design, development, pre-deployment, and post-deployment stages to probe generative AI systems for safety and security risks. Microsoft says the AI Red Teaming Agent can automate adversarial probing and help teams measure attack success rates at scale.

So the broader takeaway is not just that Microsoft scans some models before release. It is that Microsoft wants enterprises to view model security as a layered process: platform isolation, pre-release scanning for selected models, built-in content safety, and customer-side red teaming and governance before anything reaches production.

What Microsoft says it does for model security

The specific checks Microsoft listed

• Malware analysis for embedded malicious code.
• Vulnerability assessment for known CVEs and zero-day risks targeting AI models.
• Backdoor detection for evidence of supply chain tampering, arbitrary code execution, or unexpected network calls.
• Model integrity analysis to detect tampering or corruption in layers, components, and tensors.
• Red teaming and safety evaluation for select models such as DeepSeek R1.

What enterprises should take from this

• Treat third-party AI models like third-party software packages.
• Do not rely on vendor scanning alone, because Microsoft itself says scans cannot catch everything.
• Check the model card and deployment details before production rollout. Microsoft says model catalog information should help customers assess trust.
• Use security testing before and after deployment, not only at launch. Microsoft’s AI Red Teaming Agent documentation specifically recommends design, development, pre-deployment, and post-deployment testing.
• Extend zero-trust thinking to model APIs, permissions, and surrounding workflows, not just to the model file itself. This last point is an inference from Microsoft’s zero-trust description and deployment guidance.

FAQ