Governing Open and Closed Models Across the Enterprise AI Stack

Open models transfer control to the enterprise, but they also transfer responsibility.

That tradeoff is central to their value. Organizations can determine where an open model runs, which data it processes, how it is optimized, and when it is updated. They are less dependent on a provider changing its model, pricing, usage policies, geographic availability, or support for a particular workload.

This flexibility is especially important for regulated, highly sensitive, latency-sensitive, and disconnected environments. An organization may need to keep data within a specific jurisdiction, operate inside a private cloud or on-premises data center, customize a model for proprietary terminology, or maintain access when an external service is unavailable.

Open models can also improve leverage within a broader model strategy. HyperFRAME Research Lens data shows that 79% of organizations anticipate using multiple foundation models concurrently, while 48% are pursuing hybrid LLM strategies. Enterprises are unlikely to select one model and standardize every AI workload around it. They will combine proprietary frontier models, smaller specialized models, and open models based on cost, performance, privacy, latency, and control requirements.

However, running an open model requires the enterprise to assume operational functions that a proprietary provider would otherwise perform. These include securing model artifacts, validating updates, testing behavior, managing inference infrastructure, monitoring usage, evaluating vulnerabilities, and responding when safeguards fail.

The organization must also determine whether the model it downloaded is the model it intended to deploy. Model weights, adapters, fine-tuning data, dependencies, and inference containers become part of the AI supply chain. A compromised model repository or unverified artifact can introduce risk before the model ever receives a prompt.

Many enterprises want the control associated with open models without yet having the operating model required to manage them. The result can be fragmented deployments in which teams download models independently, apply inconsistent evaluations, and connect them to enterprise data without centralized visibility. Open-model governance cannot stop at approving a license or maintaining a list of permitted models.

The same scrutiny must apply to proprietary models. Provider-managed controls offer meaningful benefits. A model vendor can monitor misuse, restrict access, update safeguards, investigate abnormal behavior, and disable compromised accounts. Enterprises also avoid operating the underlying model infrastructure themselves.

Yet proprietary access does not eliminate operational risk. A closed model connected to customer databases, code repositories, cloud consoles, financial systems, or communications platforms can cause material harm even if the provider’s safeguards remain intact. The provider may govern what the model is willing to generate, but it does not necessarily control what the enterprise application allows the model to access or execute.

An enterprise can therefore deploy a well-governed model inside a poorly governed system.

This problem is becoming more urgent as models evolve into agents. Agents do more than generate responses. They select tools, retrieve context, chain tasks, make decisions, and take actions. The potential impact is no longer limited to an inaccurate answer. An agent can expose data, modify code, send messages, initiate transactions, provision infrastructure, or repeat a permitted action at an unanticipated scale.

In that environment, a model’s openness is only one input into risk. The more important question is what the complete system allows the model to do.

The Runtime Becomes the Control Boundary

Traditional model governance focuses on selecting approved models, reviewing training practices, testing outputs, and monitoring accuracy or bias. Those controls remain necessary, but they are insufficient for agentic systems. The operational control boundary must extend into the runtime surrounding the model.

• Identity: Every model and agent should operate under a verifiable identity tied to a defined owner, purpose, and environment.
• Credentials: Access should rely on short-lived, task-specific privileges rather than persistent credentials shared across agents or applications.
• Data access: Retrieval should be limited to the information necessary for the task, with existing user and data permissions preserved.
• Tool permissions: Agents should receive access only to approved tools and actions, not every capability exposed by an application or MCP server.
• Action limits: Policies should govern not only whether an action is allowed but also its frequency, value, scope, and cumulative impact.
• Human approval: High-impact or irreversible actions should require explicit authorization at the point of execution.
• Network boundaries: Agents should operate within constrained environments that limit unexpected communication and lateral movement.
• Observability: Organizations need a record of the model, prompt, context, tools, decisions, and actions involved in each workflow.
• Containment: Security and operations teams must be able to suspend an agent, revoke credentials, isolate an execution environment, and stop downstream activity in real time.

These controls are relevant regardless of whether the underlying model is open or closed. The implementation may differ, but the objective is the same: limit the authority of the complete AI system and preserve evidence of what occurred.

This shifts enterprise risk assessment away from a simple open-versus-proprietary comparison. A smaller open model deployed locally with no external network access and narrow read-only permissions may present a limited blast radius. A proprietary frontier model operating through an agent with access to production credentials and transaction systems may present a much larger one.

The reverse can also be true. An unpatched open model downloaded from an untrusted repository and connected to sensitive data can create risks that a managed API would have reduced. Governance decisions must reflect the specific model, workload, deployment, and controls rather than assuming one architecture is always safer.

Building a Common Governance Framework

Enterprises need a common evaluation framework that can be applied across open and proprietary models while accounting for the differences between them.

At the model level, organizations should evaluate capabilities, known failure modes, provenance, security testing, software dependencies, update practices, and the ability to modify or remove safeguards. Open models may require deeper artifact validation and internal testing because the enterprise is responsible for deployment. Proprietary providers should be evaluated on transparency, data handling, availability, usage controls, change management, and the evidence they provide about model behavior.

At the system level, organizations must evaluate the data the model can retrieve, the tools it can invoke, the credentials it receives, the actions it can take without approval, and the scale at which those actions can occur. They also need the ability to detect abnormal behavior, reconstruct execution, and stop or reverse activity.

This system-level assessment increasingly determines actual operational risk. A model may pass safety evaluations and still create unacceptable exposure if the surrounding application grants it excessive authority.

Governance should also reflect the workload. A model summarizing public documents should not be governed in the same way as an agent modifying production code or initiating financial activity. Controls should increase with data sensitivity, decision importance, autonomy, connected systems, action irreversibility, and potential financial or operational impact.

This provides a more useful risk model than categorizing every open deployment as high risk and every managed service as controlled.

From Model Choice to Operational Accountability

The growing use of multiple models makes centralized governance more difficult. Different business units may use managed APIs, cloud-hosted open models, locally deployed models, embedded application models, and coding assistants simultaneously. Each may have different logging, identity, policy, and security mechanisms.

Enterprises need visibility across that fragmented environment. They must know which models are in use, which applications depend on them, what data they access, what tools they call, how much they cost, and which actions they perform.

A model inventory is a starting point, not the final control. Governance must follow the full execution path from the user or agent identity through the model, retrieved context, selected tools, and resulting actions.

This is where AI gateways, agent gateways, observability platforms, identity systems, data-governance tools, and runtime security controls are beginning to converge. No single control plane yet governs every model, data platform, tool, and deployment environment. Enterprises risk creating multiple governance layers that each see only one portion of the workflow.

The long-term requirement is not necessarily one product. It is a consistent policy and evidence model across the stack. Organizations should be able to apply common rules to an agent regardless of whether it uses an open model in a private environment, a proprietary API, or several models within the same workflow.