Skip to main content

    How to Find Ollama, LM Studio, and llama.cpp on Employee Laptops

    Local models leave almost nothing on the network. Here is what they do leave on the machine, how to check a whole fleet, and how to spot a local AI server that other machines can reach.

    The short version

    How do I detect local LLMs on employee laptops?

    Check the machine, not the network. Once a model is downloaded, a local LLM runs without calling the internet, so DNS and proxy logs go quiet. Look for the runtime's process, a listening port (Ollama uses 11434), and model files, then run those checks fleet-wide with MDM or osquery.

    Before you start

    The checks on this page read files and system state; none changes a setting. Some runtime commands, such as ollama list and lms ls, can start the runtime's background service, so only query runtimes that are already running. Run the checks on your own machine, or with the knowledge of the person whose machine it is. Checking devices can count as employee monitoring, so agree the scope with HR, legal, or your privacy team first, and report by tool and team rather than by person. The shadow AI detection guide has the full caveat. This is general information, not legal advice.

    Why local models are a different kind of shadow AI

    A local LLM is a large language model that runs on a person's own computer, through a runtime such as Ollama, LM Studio, or llama.cpp, instead of being called from a cloud AI provider. After the download, nothing leaves the laptop, so DNS, proxy, and CASB tools see the download at most.

    That is genuinely lower risk for data leaving the company: prompts stay on the device. The risks are different ones:

    • Unvetted model files and licenses, some of which do not allow commercial use.
    • A local AI server exposed to the network without authentication.
    • Outdated runtimes with known flaws, such as the Ollama vulnerability tracked as CVE-2026-7482, for which 0.17.1 is the minimum version with the fix.
    • Coding agents pointed at a local endpoint.
    • No provider invoice, so local AI never shows up in a spend review.

    Most organizations do better sanctioning a local AI setup than banning it. It is still shadow AI until someone knows it is there.

    Signals each runtime leaves

    Ports are configurable and defaults change between versions, so match on process names first and use ports as a second signal.

    Signals Ollama, LM Studio, and llama.cpp leave on a machine: process, default listen address, model location, and how to list models
    RuntimeProcess or commandDefault listen addressWhere models liveHow to list models
    Ollamaollama (ollama serve); the desktop app adds an Ollama process127.0.0.1:11434. The OLLAMA_HOST setting changes it (Ollama FAQ)~/.ollama/models; installed as a system service, /usr/share/ollama/.ollama/models. OLLAMA_MODELS moves itollama list, ollama ps, or /api/tags (API docs)
    LM StudioThe LM Studio app; the lms commandIts local server uses port 1234 in LM Studio's own examples; check the port shown in the app. "Serve on Local Network" makes it reachable from other machinesThe folder set in the app's My Models tablms ls (on disk), lms ps (loaded) (lms docs)
    llama.cppllama-server, llama-cli127.0.0.1. The current README default port is 9931; older builds default to 8080, and many container setups still use it (server README)Wherever the user keeps .gguf filesGET /v1/models, GET /health

    Others include Jan, GPT4All, LocalAI, vLLM, and Docker's model runner. Check their process names rather than relying on a port list.

    Check one machine by hand

    Five checks for a terminal running zsh or bash, starting with the ones that touch nothing. On machines without one, run the same checks through your fleet tools, such as osquery or your device management inventory.

    1. Look for runtime processes

    List running processes and look for the runtimes' names: ollama, llama-server or llama-cli, and LM Studio or its lms command.

    In a terminal (zsh or bash)

    ps -axo pid,comm | grep -iE 'ollama|llama|lm studio|lms'

    2. Look for local AI servers listening

    List listening TCP ports and check which runtime owns each one and which address it is bound to. 127.0.0.1 means only the same machine can reach it; an asterisk or 0.0.0.0 means other machines on the network may be able to.

    In a terminal (zsh or bash)

    lsof -nP -iTCP -sTCP:LISTEN | grep -iE 'ollama|llama|^lm'

    The ^lm pattern matches LM Studio and its lms command at the start of the line, where lsof prints a shortened command name. Run it with sudo to include servers started by other users or by a system service.

    3. Ask the runtime what it has

    Start with checks that touch nothing: the Ollama manifests folder lists downloaded model names, and an Ollama server that is already running returns the same list from its API. Runtime commands such as ollama list and lms ls can start the runtime's background service, so only query runtimes that are already running. Model names are what the inventory needs, not anything people typed.

    In a terminal (zsh or bash)

    ls -R ~/.ollama/models/manifests   # Ollama model names and tags; starts nothing
    curl -s http://127.0.0.1:11434/api/tags   # only if Ollama is already running
    
    # Only if the runtime is already running:
    ollama list     # models on disk
    ollama ps       # models loaded now
    lms ls          # LM Studio models on disk
    lms ps          # LM Studio models loaded now

    4. Find model files on disk

    Search the home folder for large .gguf and .safetensors files, and check the Ollama models folder, which stores its models under hashed file names rather than .gguf names. A full search is slow on large disks, so run it when the machine is idle.

    In a terminal (zsh or bash)

    find ~ -type f \( -name '*.gguf' -o -name '*.safetensors' \) -size +500M 2>/dev/null
    ls ~/.ollama/models

    5. Check installed apps and packages

    Check the machine's installed applications for Ollama and LM Studio, the Homebrew formulas ollama and llama.cpp and the lm-studio cask where Homebrew is used, and Python tool managers for local AI front ends.

    In a terminal (zsh or bash)

    brew list --formula | grep -E '^(ollama|llama\.cpp)$'
    brew list --cask | grep -E '^lm-studio$'
    uv tool list
    pipx list

    Check the whole fleet

    The tools named here are examples, not endorsements. Use the ones you already run.

    Device management inventory

    Use your device management tool's installed-software report, in Jamf, Microsoft Intune, Kandji, or similar, to find the Ollama and LM Studio apps. Add a custom inventory script that runs the checks above and reports runtime names, versions, and model names only.

    osquery

    The processes, listening_ports, apps or programs, homebrew_packages, and python_packages tables cover the same signals. A starter query:

    SELECT p.name, p.path, l.address, l.port
    FROM listening_ports l JOIN processes p USING (pid)
    WHERE p.name LIKE '%ollama%' OR p.name LIKE 'llama-%'
       OR l.port IN (11434, 1234, 9931);

    Leave out the cmdline column: command lines can contain secrets, such as a key passed to llama-server --api-key. Elastic's osquery integration ships prebuilt packs that inventory local LLM runtimes, AI coding agents, and MCP servers.

    EDR process telemetry

    Process-start and file-creation events catch runtimes starting and model files arriving. Splunk publishes detections for local LLM frameworks built on this kind of telemetry.

    Network signals, with limits

    DNS or proxy hits on model registries, such as the Ollama library or Hugging Face, show downloads, not use. Treat them as a lead to follow up on the machine.

    Check for exposed local AI servers

    A local AI server becomes reachable from other machines when someone sets OLLAMA_HOST=0.0.0.0, turns on LM Studio's "Serve on Local Network", starts llama-server --host 0.0.0.0, or publishes a container port such as -p 11434:11434, which binds every interface by default. These servers usually have no authentication.

    This happens at scale: a Cisco study found over 1,100 Ollama servers reachable from the internet in a 2025 scan, and 2026 reports on CVE-2026-7482 put the number far higher, at roughly 300,000 (NYU Shanghai RITS summary).

    Old versions add risk: CVE-2026-7482 lets an unauthenticated request to a reachable Ollama server leak process memory (CSA research note). Upgrade to the latest release; 0.17.1 is the minimum for CVE-2026-7482.

    To fix an exposed server, bind it to 127.0.0.1, firewall the port, put authentication in front with a reverse proxy if it must be shared, and keep the runtime updated.

    Only scan networks you are authorized to scan.

    One option: Behest Radar

    Behest Radar recognizes local models run with Ollama, LM Studio, or llama.cpp, and names the model. It recognizes them by the shape of the request, not by port or process name, so a model served on a non-default port still shows up as a local model with its host; it does not show which runtime is serving it. It also keeps a local list of suspects: unknown hosts whose traffic looks like AI inference, for a person to confirm.

    It is observe-only and does not change, slow, or stop anything. A standalone install makes no network connections of its own. It does not replace an installed-software inventory: it shows AI in use, not every file on disk. Check the download page for the installers available today.

    Decide what to allow

    A short local AI policy usually covers:

    • Approved runtimes and their minimum versions.
    • An approved model list, with licenses checked.
    • Loopback-only binding unless a shared server is approved.
    • Whether company data may go into local models.
    • How people request a new model.

    Record each finding in your shadow AI inventory using the shadow AI audit template, and add the rules to your AI usage policy.

    Frequently asked questions

    Can network monitoring detect local LLMs?
    Only partly. DNS, proxy, and CASB logs can show a model being downloaded, for example from Hugging Face or the Ollama library, but once the model is on the laptop it answers without network traffic. To see local LLMs in use, check the machine: running processes, listening ports, model files, and installed apps.
    What port does Ollama use?
    Ollama listens on port 11434 and binds to 127.0.0.1 by default, so only the same machine can reach it. The OLLAMA_HOST setting changes that address. If you find Ollama listening on 0.0.0.0 or a network interface, other machines may be able to use it without authentication, so treat it as an exposure to fix.
    Are local LLMs a security risk?
    They carry different risks from cloud AI. Prompts stay on the machine, which helps keep data inside the company. The risks are unvetted model files and licenses, local AI servers exposed to the network without authentication, and outdated runtimes with known vulnerabilities. Most organizations do better sanctioning a local AI setup than banning it.
    How do I find local LLMs on every company laptop?
    Use tools you already have: your device management tool's installed-software inventory finds the apps, osquery finds runtime processes and listening ports, and EDR telemetry shows runtimes starting. Behest Radar recognizes local models run with Ollama, LM Studio, or llama.cpp. Machines connected to Behest Control appear in one device inventory, where local model use shows up without the model name, which stays on the machine.
    Does Behest Radar see local models?
    Yes. Behest Radar recognizes local models run with Ollama, LM Studio, or llama.cpp by the shape of the request, on any port, and names the model, though not which runtime serves it. It is observe-only and does not change, slow, or stop anything. Radar does not read prompts by default; only Behest Control's full sharing level adds a redacted prompt excerpt.
    Do local LLMs cost anything?
    There is no per-token bill, so local models never appear on an AI provider invoice or in expense reports. The costs are hardware, power, and the time people spend running them, plus the risk of using a model whose license does not allow commercial use. Record them in your AI inventory like any other tool.

    See the local models on your own machine

    Behest Radar is a free download. Then see how shadow AI discovery fits with governing and budgeting the AI you approve.

    Behest Radar: Find the shadow AI on your machines. Free download.

    Get Radar free