Is your company considering moving some of its AI work from cloud services like ChatGPT to Ollama deployed within the corporate network ? If so, you probably have more than a few questions. It's not just about installing a binary: we're talking about protecting sensitive data, preventing leaks to the internet, and ensuring that no attacker can tamper with your models or logs.
In recent months, over 175.000 instances of Ollama have been discovered publicly exposed on the internet without adequate protection. Many belong to startups or technical teams who wanted to test quickly… and left the door wide open. To prevent this from happening to you, here's a comprehensive and practical checklist for securely deploying Ollama in corporate environments.
Understanding what Ollama is and what using it in a company entails.
Before making any changes in production, it's important to understand that Ollama is a platform for running LLMs locally , on your own hardware (PC, server, VPS, workstation with GPU, etc.) without relying on external APIs from OpenAI, Anthropic, and others. It uses the llama.cpp library , adding a model management layer, HTTP server, and a very simple CLI.
This approach has obvious advantages for a corporate network: the models and data stay within your infrastructure , you don't pay per token, and you're not dependent on third-party pricing, privacy, or availability decisions. In return, you become responsible for everything: security, performance, updates, and ensuring nothing is accidentally exposed.
Ollama allows the use of large language models (LLMs) such as Llama 3, Mistral, Gemma, Qwen, or DeepSeek, as well as their code, vision, or advanced analysis variants. Many of these are quantized (q4_K, q8_0, etc.) to reduce size and memory consumption, at the cost of a slight loss of precision, making them easier to run on "normal" machines without the need for GPU farms.
From a security standpoint, the most important thing to understand is that Ollama exposes a default API server at 127.0.0.1:11434 . If you change this behavior to offer the service to other computers within the network (or worse, from outside) without taking precautions, you risk falling into the same trap as thousands of exposed instances detected on the internet.
Real risks: public exposure of Ollama instances
Recent studies that have identified over 175.000 publicly accessible instances of Ollama reveal a clear pattern: rapid deployments without any authentication or network segmentation . Many teams simply set up a server on a VPS or on a port directly accessible from the internet and left it as is.
The main problem with this situation is that anyone can connect to the Ollama API and issue prompts, load models, consume resources, or even attempt to exfiltrate information if the service is connected to internal systems. Remember that Ollama is typically used to process internal documents, logs, source code, or sensitive information; leaving that accessible through a global port scan is a recipe for disaster.
Furthermore, if an attacker can freely interact with the instance, they have room to discover how it's integrated into your workflows , what automations exist with n8n or other tools, and look for weak points: incident response scripts, database integrations, connections to critical systems, etc.
In corporate environments, the integrity of the models is also a concern . A poorly protected Ollama could become a vector for introducing manipulated models, replacing variants with malicious ones, or changing configurations (for example, prompt templates) that affect the behavior of the company's internal assistant without anyone noticing in the short term.
This is all exacerbated when Ollama is integrated with automation tools like n8n or other self-hosted systems (Nextcloud, internal applications, CI/CD pipelines). In these scenarios, unauthorized access to the model API can lead to lateral movement and privilege escalation within the automated workflows themselves.
Pre-deployment security checklist
Before deploying Ollama to the rest of the organization on a corporate network, it's advisable to follow a basic checklist to minimize typical configuration errors. The idea is that, even if you want to move quickly, you don't sacrifice essential security controls.
The first step is to decide where the instance will reside: physical server, virtual machine, container, or internal VPS . Whichever option you choose, the server must be part of a controlled network segment (for example, an internal services VLAN) and should not be directly exposed to the internet via NAT or port forwarding without a reverse proxy and very strict rules.
In terms of technical requirements, Ollama as a binary is lightweight, but the models themselves are not. You need sufficient RAM for the model sizes you want to load (7B typically requires at least 8-16 GB for smooth operation, 13B requires 16-32 GB, and even larger models significantly increase memory requirements). The CPU is not usually a bottleneck unless you have very old machines; with a modern 4-8 core processor, the experience improves considerably.
The GPU is optional, but in corporate networks with a SOC or a heavy development team, it's worthwhile: GPU inference drastically reduces response times , making it viable to use larger models for analysis, code generation, or automation tasks without them taking forever.
Finally, check the disk space . Each model can range from ~2-5 GB in small, quantized versions to 40-50 GB or more in large models, and some behemoths exceed 200 GB. If the server will host several models (general chat, a specific code model, a vision model, etc.), it's not uncommon to need more than 200 GB dedicated solely to weight files.
Secure configuration of the Ollama service
Once the environment is chosen, it's time to configure the Ollama service carefully. On Linux, the standard installation using `curl -fsSL https://ollama.com/install.sh | sh` starts a systemd service listening on 127.0.0.1:11434 . This initial behavior is reasonably safe, because the API is only accessible from the host itself.
The first point of the checklist consists of verify the effective configuration of the serviceOn systems with systemd you can use sudo systemctl status ollama y sudo journalctl -u ollama to review boot logs and confirm that the listening host is local. Any subsequent changes to expose it to other machines must be done deliberately and documented.
To adjust parameters, including where models are stored or which interface the server listens on, you can create or modify a service override with sudo systemctl edit ollama.serviceThere, environment variables are defined such as OLLAMA_HOST, OLLAMA_MODELS, OLLAMA_KEEP_ALIVE o OLLAMA_DEBUG that control the behavior of the daemon.
A common mistake is changing OLLAMA_HOST to 0.0.0.0:11434 to provide network service without supporting this change with firewall rules or an authenticated proxy. This combination is what ends up appearing in reports of "publicly exposed Ollama instances." If you need to open the service, always do so behind a reverse proxy with TLS and strong authentication , and restrict access using control lists and VPNs.
It's also worth deciding what to do with OLLAMA_KEEP_ALIVE : keeping models loaded in memory improves performance, but if the machine is shared or there are other services, you might want to aggressively release memory. Furthermore, from a security perspective, keeping fewer things resident can reduce the attack surface in certain very specific situations.
Network segmentation, VPN, and access control
In a corporate network, the goal is not only to keep Ollama hidden from the outside, but also to ensure it's well-contained even within the network . The network checklist should begin by placing the server in a dedicated internal subnet for AI services or similar applications, isolated from the rest of the network segments by a firewall and without direct routes from guest networks or unprivileged users.
Access to the Ollama API should ideally pass through a corporate VPN or secure tunnel, so that only authenticated devices and users can reach the service. This is especially important if you plan to integrate it with tools used from laptops or remote devices, such as n8n, support dashboards, or internal development team applications.
To control which web origins can call the service from the browser, Ollama provides the OLLAMA_ORIGINS variable , which handles CORS and prevents any domain from sending requests to the API. In corporate networks, it makes sense to restrict it to specific internal domains or to localhost if only backend applications will be using it.
At the operating system level, the server firewall (iptables, nftables, ufw or equivalent) must exactly reflect your threat model: port 11434 accessible only from specific IPs , no NAT to the Internet, no unnecessary ports open, and connection logging to detect unusual access.
If you ultimately decide to offer the API off-server using a proxy like Nginx, Caddy, or Traefik, be sure to configure strong TLS, security headers, and robust authentication (e.g., corporate OAuth, client certificates, etc.). The idea is that no one should communicate directly with Ollama except the proxy, and that the proxy should handle authentication, authorization, and rate controls if necessary.
Model management, storage, and logs
In a corporate deployment, model management is also a critical part of security. Models downloaded by Ollama are stored, according to the standard Linux installation, in /usr/share/ollama/.ollama/models (or in the path you define in OLLAMA_MODELS). This directory should have restrictive permissions and be part of your backup and change control strategies.
The checklist should include the periodic review of installed models, using commands like `ollama list` to see what's loaded, and `ollama show <model>` to inspect metadata, configuration, and templates. Any model that is not authorized or documented should be removed with `ollama rm` and, if necessary, its origin investigated.
For internal customizations (for example, models tailored to your knowledge domain), it's common to use Ollama cp to create custom variants by referencing base models. This is where Ollama's registry comes in : you can upload your internal models with Ollama push to a controlled repository to ensure that versions deployed in different environments (development, pre-production, production) are consistent and traceable.
Regarding logs, the Ollama instance generates useful information through journalctl -u ollamaFrom a security and compliance standpoint, it's beneficial to centralize these logs in your SIEM system or equivalent in order to... detect anomalous usage patterns, recurring errors or access attempts from unauthorized sources.
Finally, it is advisable to define a clear policy on the conversation history that Ollama keeps (for example, in ~/.ollama/history (for certain interactive uses). In corporate environments, it may not be advisable to maintain conversations indefinitely, or it may need to be done in compliance with specific retention policies, with controls on who can access those histories.
Secure integration with n8n and other workflows
One of Ollama's biggest draws for businesses is its ability to connect to automation tools like n8n to build AI-powered workflows: analyzing support emails, generating responses, classifying incidents, reviewing code, moderating content, and more.
The cleanest way to do this in a corporate network is to deploy n8n and Ollama on the same server or the same internal network , connecting n8n to Ollama's local API (by default, http://localhost:11434) through its dedicated node or an HTTP node configured to send prompts and read responses in JSON.
With this design, sensitive data (customer emails, internal documents, system logs, source code) is processed entirely within your infrastructure and is not released to the internet unless you choose to do so. For many regulated sectors, this simplifies compliance with GDPR, HIPAA, or other regulations because you can demonstrate where the data is processed and under what controls.
In the n8n integration checklist you should include: verifying that the configured URL points to localhost or an internal IP address , testing with a simple flow (manual trigger + HTTP node + response) to rule out network problems, and validating that n8n is also protected with authentication and not uncontrollably exposed to the internet.
A typical use case in businesses is the automated analysis of support emails: an email node in n8n detects new messages, sends the email body to Ollama requesting that it classify the issue and prepare a response, and another node decides whether to send the response automatically or pass it on to a human agent. All of this is executed without the emails leaving your VPS or internal server , and without variable token costs.
Uses of Ollama in cybersecurity and operations
Beyond general use cases (internal assistants, documentation generation, development support), Ollama has a very interesting fit in cybersecurity teams , especially when combined with technical analysis-oriented models like Qwen or DeepSeek.
A well-chosen model can help you analyze logs, detect suspicious patterns, generate vulnerability proofs of concept (PoCs) , explain exploits, map techniques to frameworks like MITRE ATT&CK or NIST, and propose mitigation measures tailored to your environment. The key is that all of this is done on internal data, within the corporate network, without any data being sent to external services.
In SOC or incident response environments, you can use Ollama to generate post-incident reports from log dumps, event summaries, traffic captures, and analyst notes. It also serves as a wizard for creating response scripts and playbooks, automating some of the repetitive work and freeing up more time for tactical decisions.
In DevSecOps, code-oriented models can scan repositories for insecure patterns , explain risks associated with vulnerabilities (CVE, CWE), and suggest fixes. Integrating them into CI/CD pipelines using the Ollama API allows this analysis to occur before deployment, and always locally.
However, it's important to remember in the security checklist that, even with a very good model, it cannot replace human judgment . AI outputs should be seen as recommendations, never as infallible pronouncements. It's advisable to explicitly define which decisions Ollama can automate and which always require validation from a security professional.
Model selection and resource management
For a secure and efficient deployment in a corporate network, choosing the right models is just as important as securing the network itself. It's not just about which model "performs best," but about which model you can afford to run with your available resources and what size makes sense for each use case.
For general chat, internal documentation, or FAQs, models like Llama 3, Mistral, Gemma, or Qwen in 7B or 13B quantized sizes usually work very well . They offer a reasonable balance between quality and RAM/CPU/GPU usage. For programming tasks and code analysis, it's best to opt for specific variants (DeepSeek-coder, CodeLlama, etc.).
If you need multimodality (for example, for the model to understand images, diagrams, or screenshots), you should look at models with "vision" capabilities such as LLaVA, Moondream, or Bakllava , which can process images along with text. However, these models tend to be more resource-intensive, so this must be taken into account when sizing your hardware.
A good checklist practice is to maintain an internal catalog of authorized models , including their versions, sizes, quantities, and official use cases. This catalog should be updated whenever you change models, add new variants, or retire old models, and it should ideally be aligned with the organization's security and compliance requirements.
Finally, don't forget that quantization (q2, q4, q8, fp16, etc.) isn't just a technical matter: it directly affects accuracy. In some contexts (summaries, brainstorming) you can accept highly compressed models; in others (legal decisions, diagnoses, critical financial analysis) you might prefer less quantized models, with higher output quality at the cost of consuming more resources.