Linux's role: the servers and containers behind the SaaS

Linux is the same privilege model, different furniture

The reassuring news first. Everything Chapter 14 taught applies to Linux unchanged at the level that matters. Linux has the kernel and userland split, enforced by the same hardware privilege boundary. It has processes with isolated address spaces. It reaches privileged operations through system calls. Its privileged account, the one with no restrictions, is the superuser, conventionally called root. A defender who understood the bones of Chapter 14 already understands the bones of Linux.

What differs is the furniture. There is no registry; configuration lives in plain-text files, most of them under a directory called '/etc', and in environment variables held by each process. Background programs, the Linux counterpart of Windows services and macOS daemons, are started and supervised by an init system, which on most modern distributions is systemd. And there is no single assumed management product the way Windows assumes Group Policy or Intune and macOS assumes MDM. A Linux machine is managed by whatever the organisation chooses to build: an image it bakes, a configuration-management tool it runs, an agent it installs. Where Windows and macOS hand the organisation a management substrate, Linux hands it a blank page. That difference turns out to matter, because control on Linux depends far more on whether the organisation built the machine than on whether it can push something to a fleet.

The chapter spends little time here on purpose. The interesting part of Linux for a shadow AI defender is not how its privilege model resembles the others. It is what Linux is for.

Linux is the substrate, not usually the seat

Here is the pivot. The overwhelming majority of Linux instances your organisation depends on are not staff desktops. They are servers, and increasingly containers: the web servers, API back ends, databases and model-serving infrastructure that every SaaS product and every AI vendor runs on. The proportion of office workers who use Linux as their daily desktop is small. The proportion of the software they touch that runs on Linux somewhere is close to all of it.

When a staff member sends a prompt to ChatGPT, that prompt is received, queued and processed on Linux machines inside OpenAI's infrastructure. When they call Claude or Gemini, the same is true on Anthropic's and Google's infrastructure. Those machines are operated by the vendor, in the vendor's data centres, and the organisation has no access to them, no agent on them, and never will. This is not a deficiency anyone can remedy. It is the architecture of using someone else's service.

State the consequence plainly, because it is the hinge of the chapter. Device-side control, the entire subject of Chapters 14 to 16, stops at the boundary of devices the organisation can place software on. The servers running the AI service are permanently on the far side of that boundary. Once a prompt has left the staff member's device, the only parties who can see it are the staff member, the network path while it remains observable, and the vendor. The organisation's reach ends at its own edge. This is precisely why a manual about controlling shadow AI cannot stay on the device forever. At some point the question stops being 'what can I install on the endpoint' and becomes 'what does my contract with the vendor say, and what does the shared-responsibility model give me', which is where Part Four takes the argument, beginning with cloud service models in Chapter 21 and the API economy in Chapter 22.

Containers: why one Linux machine is now many disposable ones

Modern Linux software, including AI tooling, rarely runs as a program installed directly on the operating system. It runs in a container. The concept is worth building from the privilege model rather than from the branding.

A container is a process, or a small group of processes, running on the host's shared Linux kernel but given its own isolated view of the system: its own filesystem, its own network interfaces, its own process tree, so that from the inside it looks like a separate machine. That isolation is built from two kernel features. Namespaces partition what a process can see, so that processes in one container cannot see the files or processes of another or of the host. Control groups, usually written cgroups, limit and account for what a process can use, such as memory and processor time. Namespaces are, in the words of the Linux manual pages, the mechanism used to implement containers. (high) A container differs from a virtual machine in that the virtual machine runs its own complete operating system with its own kernel, while a container shares the host's kernel and only isolates the userland around it. The container is lighter and starts in moments; the virtual machine is heavier and more thoroughly separated.

Two consequences follow, and a defender should hold both. The first is that containers are how the cloud back end is built, so the same idea explains the substrate face of the previous section: the AI vendor's service is a fleet of containers on Linux hosts you cannot reach. The second is the one that matters for the endpoint. Because a container brings its own filesystem and runs its workload inside a runtime, running an AI tool can be as quick as issuing a single command to pull and run an image, and the resulting workload leaves less of a trace in the places an endpoint agent habitually looks. An application-allowlisting control tuned to recognise and block named executables, the kind Chapter 15 described, may not catch a model that runs as a process inside a container runtime, because the thing that launched is the runtime, not the named client the policy was written against. Containers, in other words, quietly blunt several device controls at once.

The API and the key: shadow AI with no app and no browser

The second pivot is the one that matters most to a research audience. Every major model is reachable not only through a web app but through an API, and an enormous amount of serious AI work happens that way, from scripts, notebooks and IDEs.

An API call is not authenticated by a federated sign-in. It is authenticated, in the common case, by an API key: a long secret string the user generates in the vendor's dashboard and places into their code, an environment variable or a configuration file. The request carries the key and the service honours it. In the terms of Part Two, this is bearer-token authentication, with all of that pattern's properties and none of its identity-layer visibility. The key is the user's own. The organisation's identity provider is not in the loop, never sees the authentication, and has nothing to log or to block. The enterprise-application audit of Chapter 13, which can surface and revoke a federated grant, has no equivalent grip on a personal API key.

Beyond the plain API call sits a faster-moving development. Models are increasingly wired into agents: software that lets a model call tools and reach data sources on the user's behalf, so that the model is no longer a chat box but an automated actor issuing its own API calls. The Model Context Protocol, an open standard introduced in late 2024 for connecting models to external tools and data, is the most prominent expression of this, and it has spread quickly. (high) For a defender the significance is that the device-side controls have even less to grip on agentic use than on a manual API call, and the network sees only more HTTPS to more API endpoints. The one place this surfaces in the source material for this manual is that Microsoft's Defender for Cloud Apps catalogue has begun categorising AI model providers and MCP servers as discoverable application types, which is discovery and not control, and is lightly documented at that. (medium)

Reading shadow AI controls against the two faces of Linux

Bring the two faces together against the controls, honestly.

The substrate face is where control structurally ends. The AI vendor's Linux servers are out of reach by construction, so the only controls that touch a consumer AI interaction are the ones that act before the data leaves the organisation's own boundary, and those are the network, endpoint, browser and identity controls already covered. There is nothing on the far side for the organisation to deploy. The practical effect is that the centre of gravity for governing the data, once it is in use against a cloud AI service, shifts away from controlling the device and toward controlling the data and the contract: classification, the terms the vendor agrees to, the shared-responsibility split that Part Four develops, and the proportionate-monitoring questions that Part Five develops. The chapter's job is to let the reader feel where the boundary falls, not to pretend it can be pushed back.

The power-user-endpoint face is where the controls still reach, but more weakly than for a browser. Return to the opening scene on a managed machine. An endpoint agent, whose mechanics belong to Chapter 23, can in principle observe that a Python process opened an outbound connection to a model API. That is process-and-network telemetry: it establishes that something talked to an AI endpoint, not what was said. Network protection can block the API hostname if it is on the blocklist and the device is on a filtered path, subject to the same edge cases Chapter 15 set out. Endpoint data loss prevention could inspect a file the dataset was read from, but a few hundred rows assembled in memory in a notebook and streamed to an API may never touch a watched file or the clipboard, so the paths DLP relies on can be sidestepped with no intent to evade at all. The controls degrade in a clear order: from reading the prompt, which only the browser-resident controls do, to seeing that a process spoke to an API, which a managed endpoint agent can do, to nothing, which is what an unmanaged or off-network machine yields. For API-shaped use, even the best case sits lower on that ladder than it does for browser-shaped use.

The self-hosted model is the case nothing reaches, and it completes a thread that ran through Chapters 15 and 16. A model run locally, especially inside a container, with the data never leaving the machine, is reachable only by application control, and on Linux there is no AppLocker or App Control for Business assumed by default. Whether the organisation can constrain it depends entirely on whether it owns the build of the machine and the container pipeline. On an organisation-built, managed Linux workstation, it can limit which images run and what the machine may pull. On a developer's self-administered Linux box, or inside the Windows Subsystem for Linux that Chapter 15 flagged, it cannot. The privacy paradox deserves to be stated without flinching: the local model is at once the most privacy-preserving option for the data, because nothing leaves the machine, and the least governable, because nothing is visible. A defender should sit with the implication, which is that pushing too hard against sanctioned cloud AI can rationally drive a capable user toward a local model the organisation can see even less of. Part Five returns to this under the heading of driving usage underground.

None of this is a digression for a population-health audience. The staff who work in notebooks and against APIs, often with the most sensitive small-n data, on Linux or Linux inside a virtual machine because that is where the data-science tooling lives, are the same staff with the widest data access and the greatest technical means. Widest access and greatest means is exactly the combination a shadow AI programme most needs to account for, which is why Linux earns a chapter rather than a footnote.

Last updated 9 August 2026