Self-Hosted AI Isn't Automatically Secure. Here's What Actually Matters.

There isn't one deployment model that works for every organization. The choice depends on confidentiality requirements, internal policies, regulatory obligations, and the resources available to maintain the system.

Self-hosting gives an organization greater control over model deployment and data processing. Air-gapping adds network isolation, but complicates updates and integrations. Enterprise cloud services may provide mature security controls without requiring the organization to operate its own inference infrastructure.

The right question isn't which option sounds most private. It's which option satisfies the organization's actual requirements.

Running an open-weight model locally doesn't remove the risks associated with exposing an application, managing credentials, or maintaining software.

Research published in 2026 illustrates three different failure points: publicly exposed model servers, vulnerabilities in the model runtime, and vulnerabilities in the orchestration layer.

175,000 publicly reachable Ollama hosts

In January 2026, SentinelLABS and Censys published research on internet-accessible Ollama deployments.

Across 293 days, researchers observed 175,108 unique Ollama hosts in 130 countries. Approximately 23,000 formed a persistent core, while many others appeared only temporarily. Nearly half of the observed hosts advertised tool-calling capabilities, potentially allowing models to interact with APIs, execute code, or use external systems.

The findings show how easily locally deployed AI infrastructure can become publicly accessible without the protections organizations may expect from managed services.

Public reachability doesn't establish that those servers were breached. It does show the scale of the exposed infrastructure and the importance of network access controls.

Source: SentinelLABS and Censys — Silent Brothers

Bleeding Llama: sensitive data leaking from model memory

In May 2026, Cyera disclosed *Bleeding Llama* (CVE-2026-7482), a critical Ollama vulnerability with a CVSS score of 9.1.

The researchers demonstrated an attack involving three unauthenticated API requests. An attacker could upload a specially crafted model file, trigger model creation that reads beyond its intended memory boundaries, and use Ollama's model-push functionality to send the resulting data to an attacker-controlled server.

That data could contain sensitive information from server memory, including prompts, conversation content, or credentials.

Cyera reported the vulnerability and its remediation; its advisory did not establish exploitation in the wild.

The attack also illustrates why outbound network controls matter. Restricting connections to unauthorized external destinations can interrupt the demonstrated exfiltration path, even when a vulnerable service is present. It does not replace patching, since other disclosure paths or attacks may remain possible.

Source: Cyera — Bleeding Llama

Ni8mare: the orchestration layer can be vulnerable too

The same security considerations apply to the automation platform connecting an AI model to business systems.

In January 2026, a critical n8n vulnerability known as Ni8mare (CVE-2026-21858) was disclosed. It affected versions from 1.65.0 up to, but not including, 1.121.0 and received a CVSS score of 10.0.

n8n's advisory describes unauthenticated file access through vulnerable form-based workflows. Cyera, the security research team behind Bleeding Llama, demonstrated how the flaw could be chained toward remote code execution under specific conditions.

The vulnerability was fixed in n8n version 1.121.0.

This matters because n8n may hold API credentials, document contents, workflow execution data, and connections to internal business applications. If the orchestration layer is compromised, hosting the LLM privately provides little protection for information that layer can access.

Source: n8n security advisory — CVE-2026-21858

Research: Cyera — Ni8mare

Consider an employee at a financial advisory firm asking an AI assistant to summarize recent investment reports for their clients.

The firm might store thousands of documents in a shared repository. The employee should only have access to the clients they are authorized to serve. The workflow should enforce that boundary before the model receives any information.

A secure retrieval process starts with the employee's authenticated identity. The application checks their permissions, selects the authorized client records, and retrieves only the documents relevant to the request. If the system uses a vector database for document search, authorization must still be enforced on the retrieved results; similarity search alone isn't an access-control mechanism.

The workflow can then remove unnecessary personal identifiers or mask sensitive fields before passing the relevant content to the LLM. Masking isn't always appropriate or sufficient, particularly when the task requires the original values or when supposedly anonymized information can still identify a client.

The model should not receive broad repository credentials or unrestricted tools that allow it to bypass those controls.

For controls on what an AI agent can do after analyzing data, see AI Agents Are Getting Access to Your Business Systems. Who Controls What They Can Do?.

Restricting retrieval is only part of the problem. Sensitive information can persist elsewhere in the automation environment, even when the LLM runs locally.

Execution history

An n8n workflow may handle complete document contents, extracted financial information, prompts, and model responses.

Depending on its configuration, those values can be saved in execution records. Someone with access to the execution history may therefore see information that the original business user was only temporarily authorized to process.

For sensitive workflows, execution-data saving should be configured deliberately. Successful execution data may not need to be retained, while failed executions may require carefully controlled diagnostic records. n8n also supports pruning older execution data, subject to its documented retention behavior.

Logs and backups

Application logs, database backups, error notifications, and monitoring systems can create additional copies of sensitive information.

Disabling successful execution history doesn't automatically remove data already stored in backups or forwarded to external monitoring services.

Organizations need to decide what information is retained, who can access it, how long it remains available, and how it is deleted.

Outbound connections

A locally hosted LLM doesn't necessarily operate offline. The model server or orchestration platform may still be able to contact external APIs, download packages, retrieve models, or send information to other destinations.

For a private deployment, outbound access should follow an explicit policy. Only required destinations should be permitted, and sensitive workflows should not be able to send arbitrary data to external services.

An air-gapped deployment can remove ordinary external network paths, but it introduces other operational requirements for updates, approved imports, and controlled exports.

For an organization that requires locally processed AI, one possible architecture combines Ollama for model inference with self-hosted n8n for orchestration.

Ollama processes the approved prompt content. n8n retrieves information, applies workflow rules, and connects the model to authorized business systems.

Neither component is inherently secure because it is self-hosted. We would design the deployment around several boundaries.

Keep model inference private

The Ollama API should be reachable only by authorized applications on an internal network. Port 11434 should not be directly exposed to the public internet.

Where multiple services or users need access, an authenticated proxy or API gateway can enforce access policies. The model service should run with limited operating-system privileges and receive only the network connectivity required for its role.

Secure n8n separately

n8n needs its own authentication, network restrictions, patching process, and credential controls.

The editor and management interfaces should be restricted to authorized administrators. Public webhook endpoints should be exposed only when necessary, with appropriate authentication, request validation, rate limiting, and network protections.

Some integrations genuinely require externally accessible webhooks. In those cases, exposing a narrowly controlled endpoint is different from exposing the entire management application.

Security updates must be part of the operating process. Ni8mare demonstrates why an outdated orchestration platform can undermine an otherwise private AI deployment.

Together with scoped retrieval and controlled data retention, these infrastructure boundaries help limit the impact of a compromised component. That isolation depends on how the systems are configured, including separate credentials, restricted network access, and appropriately limited permissions.

Running a local model can reduce dependence on external inference APIs, but it creates infrastructure responsibilities.

The organization needs sufficient compute capacity, potentially including GPUs, plus storage, monitoring, backups, and reliable network infrastructure. More demanding models may require substantial hardware investment.

Someone must maintain the model runtime, patch the orchestration platform, rotate credentials, review access permissions, and investigate failures.

These costs should be compared with the operational controls available from enterprise cloud providers, not just with their per-token API pricing.

For some companies, managed enterprise AI will be the more practical choice. For others, confidentiality requirements, contractual obligations, or internal policies will justify the cost and complexity of private deployment.

Before selecting Ollama, a cloud AI provider, or an air-gapped environment, we would map the business process and the information it handles.

Which documents are needed? Who can access them? What data can be sent outside the environment? Where can prompts and responses be stored? Which systems can the automation contact?

Those answers determine the architecture more reliably than starting with a preferred model or hosting platform.

A locally hosted LLM and self-hosted n8n can be a useful foundation for private AI automation. But the security comes from the controls surrounding them: authorized retrieval, limited data retention, restricted network access, and maintained infrastructure.

Self-hosted AI gives you control over the environment. Secure AI requires you to exercise that control.