Managing open-weight model risk in enterprise deployments

The growing AI landscape is giving enterprises more choice in how they build, customize, and deploy increasingly capable models. Open-weight models are an important part of that landscape. They give enterprises access to model weights and greater flexibility to inspect, evaluate, modify, and run models within their own environments.

While that flexibility can be valuable, it also affects how enterprises evaluate models, where they implement safeguards, and who is responsible for maintaining those safeguards over time.

As enterprises choose which models to deploy, the relevant question is broader than whether a model is open-weight or closed-weight. Enterprises need to understand what they are using the model for, what could go wrong in that context, and what evidence and controls they need to manage risks.

Today, Microsoft and NVIDIA are publishing Risk Management for Open-Weight Models in Enterprise, the first in a planned series of joint resources intended to help enterprises address those questions. The paper introduces a shared risk taxonomy and an approach to managing model risks grounded in established standards and frameworks, including International Organization for Standardization (ISO) standards and the National Institute of Standards and Technology (NIST) AI Risk Management Framework.

The paper reflects a core idea: weight openness alone does not determine an AI system’s risk. Risk depends on the model, use case, deployment, and safeguards.

Read the whitepaper: Risk Management for Open-Weight Models in EnterpriseUnderstanding risk in the deployment contextOpen- and closed-weight models can share many of the same underlying risks, but how those risks materialize depends on the deployment. A model used to help an employee draft a document presents different considerations than the same model used in a customer-facing workflow, just as a standalone inference endpoint differs from a system connected to external data or tools.

The architecture matters too. A risk may originate in the model, while the most effective control may sit in the inference environment, application, or surrounding operational processes. The joint guidance looks beyond the model label to factors including provenance, intended use, users, deployment conditions, and surrounding controls. This first paper focuses primarily on model-layer risks. Evaluating a model alone does not establish the safety of an agent or application: teams must also assess its permissions, data access, tools, runtime, and operational controls.

Establishing a common languageManaging these risks consistently also requires a common vocabulary across engineering, security, legal, safety, and business teams.

The initial Microsoft and NVIDIA taxonomy organizes risks into five broad categories: Cybersecurity, Data Protection, Content, Human-AI Interaction, and Bias. It is not a policy or deployment checklist, but instead it should be used by enterprises to adapt it to their own systems, use cases, and risk criteria, then connect relevant risks to evaluations, mitigations, and accountable owners.

Using evaluations as risk evidenceEvaluations help turn the taxonomy into something enterprises can use. The paper maps evaluations to a selection of risks across the five categories, giving teams a way to start with a risk that matters for their deployment and identify evaluations that can produce relevant evidence about it.

Microsoft Foundry helps enterprises assess quality, groundedness, and safety with built-in and custom evaluations and automated red teaming. Its configurable content-safety controls help detect and mitigate harmful inputs and outputs and prompt attacks. Teams should validate control availability for their model and deployment, including preview status, and combine these capabilities with application-specific testing, monitoring, and human oversight.

Evaluations still need to be interpreted in the context of a particular deployment and the goal is to make it easier for teams to connect the risks they identify with useful evidence, while building a broader set of evaluation resources that can evolve alongside models, deployment patterns, and emerging risks. Microsoft and NVIDIA plan to use the joint repository to share additional evaluations and point to existing resources that can help enterprises assess specific risks.

Accounting for changes in control and responsibilityOpen-weight access gives enterprises greater control over how a model is evaluated, modified, and deployed. Model access and deployment are separate choices: open-weight models can also be used through managed platforms. Responsibility for safeguards depends on the service and deployment configuration; enterprises that operate their own model deployments may take on controls otherwise provided by a managed service.

Those safeguards can operate at different layers, and (depending on the risk) enterprises might use model changes, access controls, input and output filtering, monitoring, or human review. The important step is connecting each identified risk to controls that can effectively address it within the deployed system. Those decisions need to be revisited as models and deployments change.

Building on this workRisk Management for Open-Weight Models in Enterprise focuses primarily on the model layer. Future work from Microsoft and NVIDIA is intended to extend this approach across the runtime, harness, and application layers, with additional technical guidance on evaluation and mitigation.

We also expect the resources supporting this work to evolve as new models, evaluations, and deployment patterns emerge. The joint repository will provide a place to share additional evaluation resources, including contributions from the broader community.

For enterprises deploying open-weight models today, the paper provides guidance they can begin applying to their own use cases. We encourage developers, security practitioners, researchers, and others working in this space to read the paper, explore the evaluations, and contribute evaluations that can help strengthen this shared body of work.

Read the joint Microsoft-NVIDIA paper, Risk Management for Open-Weight Models in Enterprise.

Explore the joint repository and technical resources.

Risk Management for Open-Weight Models in Enterprise was developed jointly by Microsoft and NVIDIA, with Andrew Berkley and April Chen of Microsoft and Michael Boone, Eileen Long, and Arun Rao of NVIDIA leading the development and editing of the paper.

Explore Microsoft Foundry evaluations and content-safety controls for implementation guidance.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.
The post Managing open-weight model risk in enterprise deployments appeared first on Microsoft Azure Blog.
Quelle: Azure

From Containers to Sandboxes: Developer Trust in the Agentic Era

What the 2026 Stack Overflow Developer Survey tells us about where trust goes next

If you’ve followed Docker lately, you know we’re all-in on sandboxes. We’ve spent a ton of time talking about the difference between sandboxes and containers, and helping our customers and the industry as a whole understand when to use which. In fact, Docker president Mark Cavage dedicated his opening keynote at WeAreDevelopers World Congress North America to this exact topic, using live demos to show why sandboxes (and not containers) provide the level of isolation required to contain autonomous agents. 

To be clear: none of that means we suddenly think less of containers or the vital role they will continue to play in the software development process and ecosystem. We are Docker, after all. And lest anyone forget, as the just-released 2026 Stack Overflow Developer Survey confirmed yet again, when it comes to containers, there’s Docker, and there’s everyone else. Docker is the most used (59%) and most desired (38%) tool in the survey’s cloud development category.

Now, we can all agree that the tech industry is inundated with surveys these days. Vendors, analysts, research firms, everyone’s got a groundbreaking new survey. So, if your reflex response to reading about new survey results is to roll your eyes and think here we go again, well, I get it. 

But the annual Stack Overflow Developer Survey isn’t just another survey. When it comes to the developer community, it’s arguably the survey, the one developers themselves pay attention to. Over the course of 16 years, it has become something of a de facto standard for those of us interested in truly understanding how developers think and act. Released earlier this month, the 2026 survey reached more than 30,000 respondents across 169 countries.

Of course, this year’s survey did more than just remind us of Docker’s continued container dominance. It painted a picture of an industry in transition as developers grapple with one of the biggest questions in technology right now: how to bridge the gap between what they want to do with agents and what they can securely and confidently run in production. 

Consider:

Only 7% of developers trust AI output for important work decisions. Nearly half (48%) trust it only when they can verify it themselves.

Security and privacy ranked as the second biggest factor in whether teams adopt or expand AI tools (behind only accuracy). 

Nearly one in four developers said AI-related security or privacy issues cost their team valuable time in the past year.

Put it all together, and the missing ingredient is clear: trust. Developers want to tap into everything agents make possible without crossing their fingers and hoping “everything” doesn’t include a catastrophic security failure.

I didn’t point out those earlier Docker numbers just to brag (though, hey, I’m a marketer, so it was at least part of it). I mentioned them because they’re a reflection of trust — trust earned across more than a decade helping developers make software portable, open, reproducible, and secure. 

Today, we’re building on that foundation and extending that trust into the agentic era. At WeAreDevelopers, you saw the first steps. We launched Docker Cloud Sandboxes, published the next-generation Sandbox Kit specification (which we’ve committed to submitting to the Cloud Native Computing Foundation), and built nearly everything we showed around one idea: helping developers manufacture trust for AI agents. 

If it all looked and felt like a slightly different Docker, that was intentional. We’re at the start of a transformative era for Docker, and you’ll see a lot more from us in the coming weeks and months.

But no matter how much the industry changes, and no matter how much we evolve along with it, one thing won’t change. Docker will continue to run on trust.

If you’d like to see what that looks like in practice, try Docker Sandboxes (and get a $250 credit if you sign up before Oct. 31). You can start an agent on your laptop, ship longer jobs off to the cloud, and bring the results back. We’d love to hear what you think.

Quelle: https://blog.docker.com/feed/

Second-generation AWS Outposts racks now supported in the AWS Mexico (Central) Region

Second-generation AWS Outposts racks are now supported in the AWS Mexico (Central) Region. Outposts racks extend AWS infrastructure, AWS services, APIs, and tools to virtually any on-premises data center or colocation space for a truly consistent hybrid experience. 

 

Organizations of every size, from startups to enterprises to public sector agencies, can now order Outposts racks connected to this newly supported Region to optimize for latency and data residency needs. This regional expansion provides additional flexibility in the number of AWS Regions that customers’ Outposts can connect to.
To learn more about second-generation Outposts racks, read the blog post and the user guide. For the latest list of countries and territories and the AWS Regions where second-generation Outposts racks are supported, see the Outposts rack FAQs page.
Quelle: aws.amazon.com

AWS Transform announces Azure-to-AWS cloud-native code conversion

Today, AWS announced the general availability of application code conversion from Azure SDK to AWS SDK in AWS Transform, giving you an accelerated path to migrate Microsoft Azure cloud-native .NET applications to AWS. The AWS Transform .NET modernization agent identifies Azure service code and converts it to equivalent AWS service code. For example, an Azure Functions serverless function that uses Azure Cosmos DB can be converted to an AWS Lambda function that uses Amazon DynamoDB.
AWS Transform discovers the Azure SDK in your submitted source code and presents the conversion options in the assessment report and modernization plan. You can accept the options provided or adjust them based on your preferences before running the modernization. AWS Transform then converts the identified Azure service code to the equivalent AWS SDK calls, and validates that the changes are incorporated into the transformed code. The feature supports conversion of Azure Functions to AWS Lambda functions, Azure Blob Storage to Amazon S3, and Azure Queue Storage to Amazon SQS, with Azure Cosmos DB to Amazon DynamoDB conversion available in preview.
AWS Transform is available in eight AWS Regions: US East (N. Virginia), Asia Pacific (Mumbai, Tokyo, Seoul, Sydney), Canada (Central), and Europe (Frankfurt, London).
To learn more, see Convert cloud-native code to AWS in the AWS Transform User Guide.
Quelle: aws.amazon.com

Beam model by Reflection is now available on Amazon SageMaker JumpStart and AWS Trainium

Beam, the first open weight model offered by US-based Reflection, is now available in Amazon SageMaker JumpStart, the model hub in Amazon SageMaker AI. According to Beam, they operate at the frontier of open weight models in its class, with strong performance across reasoning, coding, and agentic benchmarks. With it, customers can now build advanced coding agents and automated workflows on a frontier open weight model while keeping control of their data and infrastructure and adapting the model to their business. Beam runs alongside other models that customers already use in SageMaker AI and scales to meet production demand with the same controls, audit trails, and monitoring built into every SageMaker AI deployment. Additionally, Beam was ported and optimized for AWS Trainium3, giving customers a high-performance, cost-efficient option for deploying and scaling the model from day one. “Reflection is delivering frontier AI that developers can actually control, not just rent through an API. Bringing Beam to SageMaker AI puts that capability in front of millions of developers on infrastructure they already trust, running in their own AWS account, on their own data, fully in their control,” said Misha Laskin, co-founder and CEO, Reflection.
Engineering teams can use Beam to resolve software issues, generate and review code, and automate routine operations work. Businesses can also use it for complex workflows that span many steps and tools, and for advanced math and science reasoning. Because Beam is released under the Apache 2.0 license, customers can inspect and customize the model, while also running it in their own AWS accounts, so data stays private and under their control, protected by the same AWS security and compliance capabilities they already rely on.  “Advanced AI models like Beam, now available on Amazon SageMaker, let us run open weight frontier AI entirely inside our own secure environments, with full visibility into the weights, the data, and the pipeline. In the age of multi-model AI, the pairing of openness and managed infrastructure is an essential addition to the AI ecosystem. The freedom to deploy and adapt advanced AI, tailored to mission problems with client-specific security and controls, gives more agencies greater flexibility to deploy advanced AI across their enterprise.” said Garrett Berntsen, Chief AI Officer, Accenture Federal Services.
Beam is initially available in Amazon SageMaker JumpStart in US East (N. Virginia) and US East (Ohio). To start, search for “Beam” in SageMaker JumpStart within Amazon SageMaker Studio, or deploy it directly on SageMaker AI.  To learn more, read the AWS/Beam launch blog, SageMaker AI documentation and SageMaker JumpStart documentation.
Quelle: aws.amazon.com

Nemotron 3.5 Super VL model now available on Amazon SageMaker JumpStart

NVIDIA’s Nemotron 3.5 Super VL is now available on Amazon SageMaker JumpStart, expanding the portfolio of foundation models available to AWS customers. This vision-language model from the Nemotron 3.5 family accepts images, video, and text as input and generates text, enabling customers to deploy multimodal AI solutions on AWS infrastructure.
Nemotron 3.5 Super VL is designed for document intelligence, GUI understanding, video question answering, and multimodal agentic applications. It pairs a 120B-parameter hybrid Mixture-of-Experts (MoE) language backbone with 12B active parameters and a vision encoder, supporting context lengths of up to 1 million tokens. The model includes a built-in Multi-Token Prediction (MTP) head for speculative decoding to accelerate text generation, with reasoning configurable per request. It supports ten languages including English, French, Spanish, German, Japanese, Hindi, Korean, and Chinese. Post-trained with multimodal supervised fine-tuning on image, video, document, chart, and GUI data followed by GRPO reinforcement learning, it delivers structured JSON output, tool calling, and configurable reasoning for enterprise agent workflows. SageMaker JumpStart offers two variants: NVFP4 for optimized inference on G7 instances with NVIDIA RTX PRO 4500 Blackwell Server Edition GPUs, and BF16 reference weights on ml.p5en.48xlarge for customization including SFT, RL, distillation, and domain adaptation.
With SageMaker JumpStart, customers can deploy Nemotron 3.5 Super VL with just a few clicks to address their specific AI use cases.
To get started with these models, navigate to the SageMaker JumpStart model catalog in the SageMaker console or use the SageMaker Python SDK to deploy the models to your AWS account. For more information about deploying and using foundation models in SageMaker JumpStart, see the Amazon SageMaker JumpStart documentation.
Quelle: aws.amazon.com

AWS Lambda durable functions are now available in AWS GovCloud (US) Regions

AWS Lambda durable functions are now available in the AWS GovCloud (US-West) and AWS GovCloud (US-East) Regions. Lambda durable functions enable developers to build reliable multi-step applications and AI workflows within the Lambda developer experience.
Lambda durable functions extend the Lambda programming model with new primitives in your event handler, such as “step” and “wait”, allowing you to checkpoint progress, automatically recover from failures, and pause executions without incurring compute charges for on-demand functions. With availability in the AWS GovCloud (US) Regions, government customers and regulated industries can orchestrate complex processes such as order workflows, user onboarding, and AI-assisted tasks while meeting stringent compliance and security requirements.
You can activate durable functions for new Python (versions 3.13 and 3.14), Node.js (versions 22 and 24), Go (versions 1.24 or later), .Net (version 2.2), or Java (17+) based Lambda functions using the AWS Lambda API, AWS Management Console, or AWS SDK. You can also use infrastructure as code tools such as AWS CloudFormation, AWS Serverless Application Model (AWS SAM), and the AWS Cloud Development Kit (AWS CDK).
For more information on durable functions, visit the AWS Lambda durable functions product page or the AWS Lambda Developer Guide. To learn about pricing, visit AWS Lambda pricing. For region availability, visit the AWS Capabilities by Region page. 
Quelle: aws.amazon.com