Understanding the Risks and Benefits of Open Weight Models and Harnesses

From Closed APIs to Open Weights

Stories of $10 and $20 million-a-month invoices for coding agents aren't urban legends. They now happen regularly at certain large enterprises, and those numbers aren't the result of a breach or denial-of-wallet attack. They come from developers using AI to write more code, doing exactly what enterprise leadership has asked teams to do over the past year. Bills this size normally get immediate attention from finance and are easy to cut. Use open-weight models instead.

Open-weight models cost about 3 to 5 times less to run than similar closed frontier models. A team can point the same coding agent at a self-hosted Qwen or GLM model and cut their next bill by millions of dollars.

The lower bill leaves something out. When a company pays for a frontier model through an API, the higher price also covers safety work and infrastructure the customer never sees. That work includes safety training, filters that catch prompt injection, a second model that checks risky actions before they run, and strict governance and compliance requirements. When a team switches to an open model and an open harness runtime, most, if not all, of that safety work goes away. The problem is that coding agents still retain full access to developer credentials.

This blog explains the market shift to open-weight models and the related considerations for security leaders. We start with definitions, adoption drivers, use cases, and usage data. Then we cover the risks companies take on with this move and what it takes to secure their agents at runtime, no matter which model is underneath.

Definitions

Open-weight model. A model whose trained parameters are published for anyone to download. Teams can host it on their own hardware and fine-tune it for their own tasks. While the trained parameters are released, the training data and training code is usually kept private. License terms also vary. Some open-weight models allow any use, while others limit commercial use or require an acceptable-use policy. Because so much is held back, we use the term "open weight" instead of "open source."

Examples of open-weight models include Meta's Llama, Mistral, OpenAI's gpt-oss, and a group of Chinese models: DeepSeek, Qwen, Kimi, GLM, and MiniMax.

Open harness. The harness is the agent runtime. It is the command-line tool or IDE extension that runs the agent loop and holds the credentials. It also defines which tools the agent can call and decides which commands actually run. Cline, opencode, OpenHands, Goose, and Kilo Code are popular open-source harnesses, and all of them work with any model.

Security teams need to think about and track the two separately, because companies can swap them out. A team can keep a closed model and move to an open harness. It can also keep a closed harness and point it at an open model, or replace both. Each choice removes a different set of protections, which we’ll explore further below.

Why is adoption growing so quickly? 

Four reasons, starting with the most important:

• Cost. Open-weight models cost about 3 to 5 times less to run than similar closed frontier models. Coding agents work through long chains of steps and use a lot of tokens, so at enterprise scale the savings can reach millions of dollars a month.
• Quality. The capability gap keeps narrowing. Stanford's 2026 AI Index puts the best open model within 3.3% of the best closed one, and on non-frontier work it has already closed.
• Data residency and control. Many companies want to keep code and data in their own environment rather than send them to an external API. Frontier vendors now offer their models through cloud platforms such as Amazon Bedrock, where traffic stays in the customer's cloud account. Even so, many teams still choose to host models themselves.
• Deployment options. Open weights can run on Kubernetes, on a laptop GPU, on EC2, or through a managed provider such as Bedrock, Vertex, Together, or Fireworks.

Enterprises usually run open-weight models in one of the following ways. Each one puts a different share of the security work on the company.

1. Managed open-weight inference. The company calls the model through an API from a managed provider. The provider runs and updates the model, and the company never handles the weight files, so it outsources the risk of a tampered model. 
2. Self-hosting in a private cloud. Managed services cost more than raw GPU time, so companies focused on cost often host models themselves. In that case, the company is responsible for checking the model files and for adding every safety control.
3. Running on the endpoint. Smaller models run directly on developer laptops. This is the cheapest way to start, and it is also the hardest for security teams to see and secure.

Where do open weights show up?

Coding agents. This is the largest use case and the one growing fastest. Most coding harnesses, open or closed, can connect to any model endpoint. Moving a whole team of developers to an open model can be as simple as a settings change. A frontier coding agent can cost more than $5,000 a month for one heavy user, which gives finance teams a strong reason to push for the switch.

Bulk and offline work. This includes jobs like summarizing documents or tagging records at high volume. For narrow tasks like these, an open-source model often does as well as a closed-source model at a much lower cost.

Work that frontier models refuse. Security research and red teaming are common examples. Teams pick local models because those models will do work that frontier models turn down. Some use "abliterated" versions, which are open models with their refusal behavior removed on purpose. The work is often legitimate, but it means the company is running models that will not refuse anything.

In all of these cases, teams choose models based on cost and task performance. Few teams pick a model for its safety training or its resistance to prompt injection. Those gaps become the security team's problem later.

Open-weight usage data

Open-weight traffic on developer routing services rose sharply in 2026. Chinese labs also replaced Meta as the leaders among open models.

Both rows measure token share on a routing surface, and both roughly quintuple within a year. The Chinese-origin row climbs hardest because DeepSeek, Qwen, Kimi, and GLM all ship open weights by default, which is what is pulling the overall share up.

Managing an unbundled safety stack

When a company buys a frontier model through an API, it gets five layers of protection in one package. With an open-weight model, the company only has the layers it adds back itself. The first two layers come with the model weights. The other four depend on where the model is hosted and which harness runs it.

Both kinds of damage happen under the developer's identity, so the logs show a normal user doing normal work.

Compliance, jurisdiction and model behavior

Open-weight models also bring legal and policy duties, even though they aren't attacks.

• Country of origin. No U.S. law or export control bans using published Chinese model weights. Export controls apply to hardware and to exporting models. Company policy or customer contracts may still ban models from certain countries, but most companies can't enforce that.
• License terms. Licenses differ a lot. Some limit commercial use, and others require users to follow an acceptable-use policy.
• Regulation. Under the EU AI Act, a company that substantially changes a general-purpose model can take on the duties of a model provider. ISO 42001 expects a list of which models are in use and why.
• Model behavior. Each lab decides how its model handles refusals and politically sensitive topics. These choices are built into the weights and differ across DeepSeek, Qwen, Llama, Mistral, and gpt-oss.

With a frontier API, the vendor handles the license terms and content policy. With open weights, the company takes on that work and has to prove compliance itself.

Rebuilding the safety stack at runtime

Banning open weights usually pushes their use out of sight, and the cost savings are too large for most companies to ignore. A better goal is to let teams use the model and agent they want while security adds back the missing layers in the runtime. Controls in the runtime work the same way for every model.

Basic security steps with low cost:

• Use managed inference instead of self-hosting where the budget allows. The provider then handles model file integrity.
• Load only safetensors model files from official sources, and pin them by hash.
• Run agent-written code in containers that block unapproved outbound traffic.

Beyond these steps, four capabilities match the risks above. Here is how Noma handles each one.

1. Find models and harnesses (Noma AI-SPM). Find the open-weight models in use and the harnesses that run them, whether they run on laptops or in the cloud. Security should be able to answer which models are running in the company and who is using them. 
2. Control what is allowed (Noma Access Control). Enforce model rules at runtime, such as an approved-model list or a rule that blocks models from a certain country in production. Apply the same rules to harnesses. Otherwise, an unapproved agent can get around an approved-model list by connecting to a different endpoint.
3. Enforce one policy at runtime (Noma AI-DR). Detect prompt injection and block sensitive content around the model rather than relying on its training. The same layer covers the rest of what a weaker model gives up: harmful output it fails to refuse, and misaligned actions the agent takes without being asked. This lets a team use a cheaper model without taking on its weaker safety behavior.
4. Test models on an ongoing basis (Noma Red Teaming). Run attack testing on the open-weight models in use and rank how well each one holds up. Connect the results to discovery, so security gets an alert when a team starts using a model that tests poorly. The goal is to protect the company no matter which model it uses.

The bottom line

A $10 or $20 million-a-month invoice will keep pushing companies toward open-weight models, and for many of them, that is a sound financial choice. The security question is which of the safety layers the company adds back, and where. Layers built into the weights differ by lab and can be removed. Layers in the runtime apply to every model the company adopts next.

To see how Noma finds open-weight models and harnesses across your environment and enforces comprehensive runtime policies around them, sign up for our next webinar, or book a technical walkthrough.