Self-Hosted AI Isn't a Lockbox: Why Open-Weight Models Still Need Egress Controls

Many companies believe that self-hosting an open-weight AI model solves their privacy and security problems. The logic feels simple: if the model runs on your own servers, your data never leaves your building. A new finding from Cohere challenges that belief. It shows that self-hosted open-weight models still need egress controls, rules that limit what data can leave a system. In plain terms, the model may live in your house, but the data can still walk out the door.

This is not a small technical detail. It is a shift in how businesses should think about AI security. The question is no longer just “Where is the model hosted?” The better question is “Where does the data go?” That change will shape how AI is built, bought, governed, and trusted in the years ahead.

The Promise and the Blind Spot of Self-Hosted AI

Open-weight models are AI models whose weights are available for download. Companies can run them on their own hardware or in their own cloud accounts. This offers real benefits: more control, predictable costs, the ability to fine-tune, and less dependence on a vendor’s API. For industries with sensitive data, health care, finance, legal, government, self-hosting looks like the safe choice.

But self-hosting creates a blind spot. People focus on ingress, the data going into the model, and forget about egress, the data coming out. Egress includes model outputs, logs, error messages, telemetry, agent actions, and any external service the model or its tools can reach. If those paths are open, the model can become a bridge to the outside world.

The Cohere finding is a warning about that bridge. It shows that owning the model weights is not the same as owning every data path around the model. A self-hosted model can still send data out through prompts, responses, plugins, monitoring tools, or connected systems. Without egress controls, the “private” AI system is private in name only.

What Cohere’s Finding Actually Changes

The finding does not mean self-hosted AI is bad. It means the security model around self-hosted AI has been incomplete. For years, the debate focused on cloud versus on-premises. That debate is now too narrow. A model can be on-premises and still leak data. A model can be open-weight and still be part of a risky data flow.

The real lesson is that the model is not the perimeter. The perimeter is the data. Security teams need to map every place data can go: from the user to the model, from the model to the output, from the output to logs, from logs to analytics, from agents to APIs, and from support tools to vendors. If any of those paths is uncontrolled, the system is exposed.

This is a mature idea in cloud security. Companies do not assume a database is safe just because it runs in their own data center. They use firewalls, identity checks, encryption, and audit logs. AI systems need the same discipline. Cohere’s finding simply makes that point impossible to ignore for open-weight deployments.

Where Data Really Leaves a Self-Hosted AI System

Data can leave a self-hosted AI system in more ways than most teams expect. The most obvious path is the model’s response. If a user asks a question about sensitive records, the answer may contain private details. If the model is connected to a chat interface, that answer can be copied, shared, or stored in a place with weaker controls.

Logs are another major path. Teams often log prompts and outputs for debugging, quality checks, and audits. Those logs may be sent to a central logging service, a cloud analytics tool, or a third-party monitoring platform. In that moment, the data has left the self-hosted environment. The same is true for error reports, performance metrics, and crash dumps.

Agents and tools add more paths. Modern AI systems can browse the web, call APIs, read files, send emails, and run code. Each of those actions is an egress channel. A model that can call an external API can also be tricked into sending data to that API. A model that can generate links can encode information in a URL. A model that can write code can create a script that moves data.

Retrieval systems and connectors are another risk. Many AI systems pull documents from internal wikis, shared drives, databases, and ticketing systems. If those connectors use external services or broad permissions, the model may expose data that was never meant to be in the same room. The model is local, but the data supply chain is not.

Why Open-Weight Models Can Become Exfiltration Tools

An open-weight model is not malicious by design. But it is powerful and flexible. That is exactly what makes it useful, and what makes it risky. A model can summarize, translate, compress, encode, and reformat data. It can turn a private document into a public-sounding story. It can hide sensitive details in code, tables, or links. It can follow instructions from an attacker who slips them into a document or web page.

This is why egress controls matter. If a model can only send data to approved destinations, a prompt injection attack has fewer places to go. If outputs are scanned for sensitive patterns, leaks can be caught before they spread. If agents run in a sandbox with a strict allowlist, they cannot call any API they want. Controls do not make the model less useful. They make it safer to use.

The Cohere finding also points to a governance gap. Many AI policies focus on which model is approved, not on how data moves around it. A company may approve an open-weight model for sensitive work, then connect it to a chat tool, a logging pipeline, and a set of agents without reviewing the combined data flow. Each piece looks fine. The whole system is not.

The Future of AI Security: From Model Perimeter to Data Perimeter

The future of AI security will look more like network security and less like model shopping. Buyers will ask vendors for data flow maps, egress policies, audit logs, and controls for agents. They will want to know not only where the model runs, but where its outputs can go. They will ask whether the model can call external services, whether logs leave the environment, and whether telemetry can be turned off.

This will create new product categories. AI egress gateways will sit between the model and the outside world. Model firewalls will inspect prompts and outputs for sensitive data. Data loss prevention tools will be tuned for AI traffic. Identity systems will govern which agents can act on which data. Observability platforms will flag unusual data flows, such as a sudden spike in output size or repeated queries that look like data harvesting.

Regulation is likely to follow the same path. As AI systems handle more sensitive data, auditors will ask for evidence that data flows are controlled. A self-hosted deployment with no egress controls will be hard to defend. The Cohere finding gives regulators and security teams a simple test: show me what can leave the model, and show me how you stop it.

Practical Playbook for Businesses

For business and technical leaders, the lesson is actionable. Start with a data flow map for every AI use case. List what data goes in, what comes out, where logs go, what tools the model can call, and who can access the system. Then apply controls at each exit point.

• Put an egress gateway in front of the model. Route all outbound traffic through a system that can inspect, allow, or block data transfers.
• Use allowlists for external calls. If the model or its agents do not need to reach a service, block it by default.
• Scan prompts and outputs for sensitive data. Use data loss prevention rules for personal information, financial records, health data, and trade secrets.
• Treat model output as untrusted. Do not let outputs trigger actions without checks. Validate links, code, and API calls.
• Sandbox agents. Give agents the smallest set of permissions they need. Limit file access, network access, and execution rights.
• Control logs and telemetry. Decide what gets logged, where it goes, who can see it, and how long it is kept. Turn off vendor telemetry if it is not needed.
• Monitor for anomalies. Watch for unusual output sizes, repeated queries, encoded text, and unusual external calls.
• Red team the system. Try to exfiltrate data through prompts, outputs, tools, and logs. Fix what you find.
• Require human approval for high-risk actions. Sending email, moving files, and calling external APIs should not be fully automatic in sensitive settings.
• Audit and review. Keep records of egress policy changes and review them as the AI system changes.

These steps are not one-time tasks. AI systems change quickly. New tools, new connectors, and new models create new data paths. Egress controls need to be part of the deployment lifecycle, not a checkbox at the start.

What This Means for the AI Market

For AI vendors, the Cohere finding is a market signal. Open-weight models will be judged not only on quality and cost, but on how well they support safe deployment. Vendors that ship built-in egress controls, clear data flow documentation, and agent sandboxing will have an advantage. Vendors that leave security to the customer will face harder questions in procurement.

For buyers, self-hosting should not be treated as a security answer by itself. It is one part of a design. The full design includes identity, network controls, data classification, logging, monitoring, and incident response. The Cohere finding shows that this is true even when the model weights are under your control.

For society, the stakes are high. AI systems are moving into health care, education, public services, and finance. If self-hosted models leak data, trust in AI will suffer. Egress controls are a practical way to keep that trust. They let organizations use powerful open-weight models without turning them into open doors.

Conclusion

Self-hosted open-weight models are a major step forward for AI adoption. They give organizations more control and more options. But control of the model is not control of the data. The Cohere finding makes that clear. A model can be local and still send data out through outputs, logs, agents, and connected tools.

The future of AI security will be built around data perimeters, not model perimeters. Companies that map their data flows and put strong egress controls in place will be able to use open-weight models with confidence. Companies that rely on self-hosting alone may find that their private AI system is not private at all. The question is not whether you host the model. The question is whether you can see, and stop, what leaves it.