Chapter 6 — Operating systems and virtualization
Lesson map
Lesson 06 published. Map, example, EX016.
flowchart TD
N0["Learning outcomes"]
N1["6.1 Processes and permissions"]
N2["6.2 Containers and virtual machines"]
N3["6.3 Sandboxing generated code"]
N4["6.4 Model files at rest"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX016"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["6.1 Processes and permissions"]
N2["6.2 Containers and virtual machines"]
N3["6.3 Sandboxing generated code"]
N4["6.4 Model files at rest"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX016"]
[Learning outcomes]
|
v
[6.1 Processes and permissions]
|
v
[6.2 Containers and virtual machines]
|
v
[6.3 Sandboxing generated code]
|
v
[6.4 Model files at rest]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX016]
Learning outcomes
You will (1) explain processes, users, file permissions and isolation; (2) use containers and virtual machines to isolate AI components; (3) sandbox code generated or executed by AI tools; and (4) protect model files at rest.
6.1 Processes and permissions
Every service runs as a process under a user account. If the orchestrator runs as root, a bug becomes a full system compromise. Run each component as its own low-privilege user, with read access only to the files it needs. For Ask Brightwell, the orchestrator, retrieval service and tool services each run under their own account, so a bug in the orchestrator cannot read the order database directly. The order tool's account can read orders but not change them, and the returns tool's account can create returns but cannot read other tables. Jonas confirms this on staging by sending a query to the orders table as the orchestrator's account and checking that the database refuses it.
6.2 Containers and virtual machines
Containers package a service with its dependencies and isolate it using kernel features; virtual machines isolate more strongly with a separate kernel. Run model servers, retrieval and tool services in separate containers with minimal images, read-only file systems where possible, and no unnecessary network access. For CodePilot, the self-hosted model server runs in its own container with a read-only file system, so a compromised server cannot rewrite its model files. Ask Brightwell's tool services sit in separate containers with network rules that allow only the orchestrator to call them. Separate images also make it clear which component needs which secret.
6.3 Sandboxing generated code
Coding assistants and agents with a "run code" tool execute text produced by a model — text an attacker may influence. Run such code in a disposable sandbox: no network by default, no access to secrets, CPU and memory limits, a time limit, and destruction after use. CodePilot's original "run tests" button broke every one of these rules: it ran generated code on a shared build server that had deployment keys. The new design starts a fresh container for each run, with no network, no secrets and a time limit, and destroys it afterwards. A planted comment can still shape the code, but the code can no longer reach anything valuable.
6.4 Model files at rest
Model weight files can be swapped or tampered with. Some formats (for example Python pickle-based files) can execute code when loaded. Prefer formats that store only tensors, verify hashes before loading, and restrict who can write to model directories.
"""Lab H: integrity of model artefacts with SHA-256 manifests (stdlib only).
Creates synthetic 'artefact' bytes, records a manifest, then detects a
one-byte tampering and a swapped file. No real models are involved."""
import hashlib, json
files = {"model.bin": bytes(range(256)) * 40, "tokenizer.json": b'{"vocab": ["a", "b"]}',
"config.yaml": b"layers: 4\nheads: 8\n"}
manifest = {n: hashlib.sha256(b).hexdigest() for n, b in files.items()}
print(json.dumps({k: v[:16] for k, v in manifest.items()}, indent=1))
received = dict(files)
tampered = bytearray(received["model.bin"]); tampered[5000] ^= 1
received["model.bin"] = bytes(tampered)
received["config.yaml"] = b"layers: 4\nheads: 8\ntrust_remote_code: true\n"
for n, b in sorted(received.items()):
ok = hashlib.sha256(b).hexdigest() == manifest[n]
print(f"{n:15s} {'OK' if ok else 'MISMATCH'}")
Expected output:
{
"model.bin": "e96760a87768717b",
"tokenizer.json": "f63d2ddabc61f2d9",
"config.yaml": "e5bbb570ca0fcb87"
}
config.yaml MISMATCH
model.bin MISMATCH
tokenizer.json OK
For CodePilot's self-hosted model, Brightwell stores the expected hash of each file in version control and the loader refuses to start if a file differs. Only the deployment pipeline account can write to the model directory, and it logs each write, so a swapped file would be both blocked and visible.
6.5 Worked example (synthetic Brightwell case)
CodePilot offers a "run tests" button that executes generated code on a shared build server with access to deployment keys. Jonas shows on a copy that a comment in a pulled open-source file can lead the assistant to write code that prints environment variables. He moves execution into a throw-away container with no network and no secrets, and adds hash checks for the self-hosted model files; the lab shows how a changed file is caught. The planted comment did not need to exploit anything: it only had to persuade the assistant, and the build server's access did the rest.
6.6 Errors and limits
- Services running as root.
- Executing model-generated code on shared hosts.
- Loading model files without integrity checks.
CodePilot's original design had the second error and Ask Brightwell's earlier orchestrator risked the first. The changes in this chapter give each service its own account, move generated code into a disposable container and check model file hashes before loading. Each error is cheap to avoid when a service is built and expensive to fix once other systems depend on it. The pipeline now runs a check for each error on every deployment.
Exercises
- EX016 — Least privilege. List the permissions the retrieval service needs and does not need. Rubric: 3 = read index, network to orchestrator only; no write, no secrets; 2 = partial; 1 = vague; 0 = none.
- EX017 — Sandbox. Specify five sandbox settings for an agent's code tool. Rubric: 3 = no network, no secrets, CPU/memory, time limit, disposable; 2 = four; 1 = two; 0 = none.
- EX018 — Hash lab. What should happen when the lab reports MISMATCH for model.bin? Rubric: 3 = refuse to load, alert, investigate source; 2 = two; 1 = one; 0 = load anyway.
Synthesis
Operating-system isolation limits what a compromised AI component can do: least-privilege accounts, containers, disposable sandboxes and verified model files.
Continue studying — chapter 06 of 30
← Chapter 05 (draft) · Course chapter index · Chapter 07 (draft) →