Run a Local LLM on a Work Laptop With No Admin Rights

Short answer: yes on Ollama — its Windows documentation states outright that "The Ollama install does not require Administrator, and installs in your home directory by default", and it also ships a no-installer zip you can run from any folder you can write to. Budget about 4GB for the binary and point OLLAMA_MODELS at your D: drive before you pull anything. The real blocker on a managed device is rarely the installer — it is AppLocker, application control, or your acceptable-use policy.

That last one comes first on this page, because getting this wrong is a conduct problem, not a technical one.

---

Check Your Policy First

Being technically able to install something on a company laptop is not the same as being allowed to, and on a managed device the two are decided by different people. Read this section before you download anything.

You are probably here for a good reason. Someone told you not to paste client files, patient records, case notes or unreleased financials into a hosted chatbot — and they were right. Running the model locally is genuinely the correct instinct: the data never leaves the machine, which is the whole argument in our local AI privacy guide. But a device your employer owns and manages is governed by their rules regardless of how sound your reasoning is.

Three things to check, in this order:

1. Your acceptable-use / software policy. Many explicitly prohibit installing unapproved software on managed endpoints, per-user installs included. Some go further and prohibit any executable not on an approved list. If yours does, stop here — a policy breach discovered later is worse than not having the tool.
2. Whether "no admin rights" means "not approved" or just "not provisioned". These get confused constantly. In plenty of organisations nobody has local admin and requests are routine; in others the absence of admin is the control. Ask.
3. Whether your data is in scope for something stricter. Regulated data — health, legal privilege, cardholder, export-controlled — often carries approval requirements that apply to the tool, not just the data path.

The productive move is usually a two-line email to IT security, not a workaround. "I need to summarise documents that must not leave the device; can I run a local model?" is a much better conversation than being found with an unapproved runtime. Local inference is an easy sell to a security team precisely because it removes an egress path — you are asking for the option they normally prefer. If it helps, our air-gapped deployment guide is written in the language security reviewers use.

Nothing below is a technique for defeating a control your employer deliberately put in place. It is how the software behaves when the constraint is simply that nobody hands out admin passwords.

---

The Four Options, Ranked

Ranked by how likely each is to work on a locked-down Windows machine, not by popularity.

A note on how to read that table: "needs admin" here means what the vendor's own documentation says about the installer. It says nothing about application control, which sits underneath all four and is covered further down.

llamafile: one file, one gotcha

llamafile packages llama.cpp and a model into a single executable using Cosmopolitan Libc — the project's own description is that it "collapses all the complexity of LLMs down to a single-file executable." On Windows you rename the downloaded file to add a .exe extension and run it. There is no installer, no registry entry, nothing in Program Files.

The gotcha is documented by the project and it matters more than it sounds: "Only executables under 4GB can run on Windows, so any llamafile above 4GB won't work." That rules out most self-contained files worth using, since a 7B at Q4 plus the runtime is right at the boundary and anything larger is over it. The project's own workaround is to download the llamafile binary separately and run it against external GGUF weights — which is still installer-free, just not literally one file. Our llamafile setup guide walks the tool itself.

LM Studio: verify, don't assume

LM Studio is the friendliest option and the one we can say least about with confidence. What its documentation does confirm: Windows needs AVX2 on x64, x64 and ARM (Snapdragon X Elite) are supported, 16GB RAM is recommended and 4GB+ of dedicated VRAM is recommended — the last of which most business laptops do not have. It also confirms LM Studio "does not require the internet in order to work" once models are local, and that you can sideload models obtained outside the app, which matters if model downloads are blocked at the proxy.

What we cannot confirm from vendor documentation is whether its Windows installer runs entirely per-user on your build. Test it, don't assume it: run the installer and watch for a UAC prompt. A prompt means it wants elevation and you are done; no prompt means it is installing into your profile — which then puts you squarely into the AppLocker question below. AVX2 is worth checking first anyway, since some older corporate fleet machines will fail that requirement outright. If you are weighing the front-ends against each other, our Jan vs LM Studio vs Ollama comparison covers the trade-offs.

---

Ollama Without Admin

Ollama is the strongest option here because the vendor documents the constraint directly rather than leaving you to discover it. The exact sentence, from Ollama's Windows documentation: "The Ollama install does not require Administrator, and installs in your home directory by default." Space requirement, also from the docs: "You'll need at least 4GB of space for the binary install" — models are on top of that.

Path A: the installer, relocated

If your C: drive is the problem rather than the permissions, the installer takes a directory flag:

OllamaSetup.exe /DIR="d:\some\location"

That is the exact form given in Ollama's documentation. It moves the application. It does not move the models — see the next section, because this is the mistake that fills the drive you were trying to avoid.

Path B: no installer at all

Ollama publishes a standalone archive, described in its docs as "A standalone ollama-windows-amd64.zip zip file ... containing only the Ollama CLI and GPU library dependencies for Nvidia." Two variants exist alongside it:

Unzip into a folder you can write to and run the CLI from there. This is the version to reach for if you want the smallest possible footprint on a machine that is not yours: no installer, no shell integration, no uninstaller to run — you delete the folder. It is also the version to put on a USB stick or a personal external drive, though see the blockers section before assuming removable media will execute.

For the ordinary admin-available path on your own machine, our Ollama Windows installation guide is the one to follow instead; this page exists specifically because that one assumes permissions you do not have.

---

Moving 20GB Off the C: Drive

OLLAMA_MODELS is the setting that matters, and Ollama's docs are explicit that you set it in your user account — no admin needed. From the documentation: "To change where Ollama stores the downloaded models instead of using your home directory, set the environment variable OLLAMA_MODELS in your user account."

Set it before your first pull, not after, or you will download the weights twice.

setx OLLAMA_MODELS "D:\ai\models"

setx writes to the per-user environment, which is exactly the scope Ollama's documentation points at. Open a new terminal afterwards — setx does not affect the session you typed it in. If you prefer the GUI, it is the same thing: search for "environment variables for your account", which on most managed builds is reachable without elevation because it only edits your own profile.

Two things that trip people up:

• The app directory and the model directory are independent. /DIR= moved a ~4GB application. OLLAMA_MODELS moves the tens of gigabytes that actually matter. Setting one and not the other is the most common version of this mistake.
• Check the drive is really yours to use. Plenty of corporate D: partitions are recovery volumes, encrypted data drives with quota, or network-mapped. A folder-redirected or roaming profile path is worse still: you do not want a 20GB model directory syncing to a file server. Confirm you are writing to genuinely local, genuinely unmanaged space.

Model choice does most of the work in keeping that directory small — the Ollama model RAM/VRAM table shows what each tag costs before you download it, and quantization explained covers why the Q4 tag is nearly always the right one here.

---

What Will Still Block You

Application control is the real gate, and it does not care what the installer says. This is where honest guidance diverges from most search results.

AppLocker default rules

Microsoft publishes the default executable rules, and they are unambiguous:

Read that as a non-admin and the consequence is immediate: your user profile is in neither allowed path. A per-user install to %LOCALAPPDATA%, an unzipped folder in your Documents, a llamafile on the Desktop, a binary on a USB stick — under default rules, none of them are permitted to execute for a standard user. The installer will happily copy the files. The policy stops them running.

Microsoft's own documentation notes that the %windir% default rule sweeps in a Temp subfolder that ordinary users can write to, and warns that "allowing applications to be run from this location might conflict with your organization's security policy." That is Microsoft flagging a weakness in a starter policy — not a technique. Deliberately staging an executable somewhere to slip past an application-control policy is the kind of thing that ends employment, and we are not going to write the instructions.

The rest of the stack

• App Control for Business / WDAC. Stricter than AppLocker and increasingly the default on new corporate fleets. Typically allow-lists by publisher signature, so an unsigned or unfamiliar binary simply does not launch. There is no user-side setting.
• SmartScreen. Warns on files with no established reputation, downloaded from the internet. On many builds a standard user can click through; on hardened ones the option is removed entirely. This one is a warning, not usually a wall.
• EDR agents. A new process that loads GPU libraries, opens a listening port on localhost and reads large files off disk is behaviourally interesting to every EDR product on the market. It may be blocked; it may be allowed and logged. Assume your security team can see it — because they can, and finding out that way is worse than asking first.
• Proxy and TLS inspection. Model pulls are large HTTPS downloads from a registry your proxy has probably never seen. Blocked downloads are common even where execution is fine. LM Studio's documented sideloading and Ollama's ability to import local GGUF files are the answers here, using weights you obtained on a machine you own.
• Removable media policy. USB execution is frequently blocked independently of everything above. The portable-on-a-stick plan is the one most likely to fail silently.
• Disk encryption and quota. BitLocker is fine; a 20GB directory on a quota-limited or redirected profile path is not.

The pattern across all six: the failure is almost never the installer, and almost always a policy layer beneath it. If you hit a wall, that tells you something about your organisation's posture — which is information worth having before you spend an afternoon on it.

---

What It Will Actually Feel Like

On a typical 16GB business laptop with integrated graphics, plan on a 7-8B model at Q4 and single-digit tokens per second. This is the expectation-setting section, and it is deliberately unflattering.

The ceiling is set by memory bandwidth, and you can do the arithmetic yourself:

That last row is a ceiling, not a prediction. Real CPU inference lands well below theoretical bandwidth, and a corporate laptop is also running an EDR agent, a VPN client, disk encryption and a mail client while you work. Single-digit tokens per second is the honest expectation.

What follows from that:

• Summarising and rewriting documents works. You paste, you wait, you get a usable answer. This is the use case that justifies the whole exercise.
• Interactive chat is tedious. Waiting 30 seconds for a paragraph changes how you use a tool.
• Long context is punishing. Prompt processing on CPU is slow, so a 40-page document costs real minutes before generation even starts.
• 13B+ is not a serious plan on 16GB. Weights alone eat most of the budget, and a corporate build is not going to give it back.

Our honest laptop guide has the wider hardware picture, and Ollama's system requirements give the floor. For picking a model that fits this envelope, best Ollama models is sorted by size for exactly this reason.

---

What We Could Not Test

We did not have a genuinely locked-down corporate endpoint to test on, so we are telling you what to check rather than reporting results we did not get. Everything above that is stated as fact comes from vendor documentation or Microsoft's published rule definitions, checked 18 August 2026. Specifically not tested by us:

• Behaviour under a live AppLocker or App Control policy. The default-rule table is Microsoft's published policy definition and the consequence for profile paths follows from it directly — but your organisation's policy is not the default, and only your machine can tell you what it is. Try to run the standalone zip; if it refuses, you have your answer in ten seconds.
• Whether LM Studio's Windows installer elevates. Watch for the UAC prompt. That is the whole test.
• Real tokens/sec on a locked-down 16GB laptop with an iGPU. The table above is arithmetic, clearly labelled. We do not publish benchmarks we have not run.
• USB execution and EDR responses. Both are entirely organisation-specific.

If your machine turns out to be fully locked down, the honest answer is that this is not a problem to be solved from your side of it. Ask for an approved path, or run the model on hardware you own and keep the work laptop out of it — our offline and air-gapped guide covers doing it properly on a machine you control.

---

The Short Version

1. Check your acceptable-use policy before you download anything. Technically possible and permitted are different questions.
2. Ollama documents that its install does not require Administrator and installs to your home directory. ~4GB for the binary, models on top.
3. The standalone ollama-windows-amd64.zip is the best fit for a managed machine — no installer, no registry, delete the folder to uninstall.
4. Set OLLAMA_MODELS before your first pull. /DIR= moves the 4GB app; OLLAMA_MODELS moves the 20GB that matters.
5. AppLocker's default rules allow Everyone only %windir% and %programfiles%. A per-user install is in neither. If that is your policy, ask for an exception — do not go looking for a gap.
6. Expect a 7-8B Q4 model at single-digit tokens/sec. Good enough for summarising documents that must not leave the device. Not good enough to enjoy.

---

Sources

• Ollama Windows documentation — the no-Administrator statement, the 4GB requirement, OllamaSetup.exe /DIR=, OLLAMA_MODELS, and the standalone / rocm / mlx archives
• Microsoft Learn — Executable rules in AppLocker — the default executable rule table
• Microsoft Learn — Understanding AppLocker default rules — the %windir%\Temp caveat
• llamafile README — single-file executable, Cosmopolitan Libc, the Windows 4GB executable limit
• LM Studio system requirements and offline documentation — AVX2, RAM/VRAM recommendations, offline operation and sideloading

All checked 18 August 2026.

---

FAQ