Local AI Agents · Module 3 · Lesson 1 of 3

Workspace hygiene

Why a dedicated, disposable workspace per agent task is the concrete, on-disk form of Module 1's data boundary, and why mixing agent work with live personal or production data is this module's root unsafe pattern.

Lesson · 15–20 minutes · Text-first

By the end, you can

  • Explain why mixing agent work with live personal or production data in one workspace is the root unsafe pattern this module addresses (LA-3).
  • Configure a dedicated, disposable workspace scoped to a bounded task's declared inputs, and state what must not be present in it (LA-3).

Before you start

This is Module 3, Lesson 1 of the Local AI Agents course, and the first lesson in Safe local setup. It assumes Module 1's five boundaries — task, data, tool, authority, and time-and-cost — and Module 1 Lesson 3's distinction between excessive functionality and excessive permissions in a tool grant. It also assumes Module 2's bounded input statement: source, scope, retention and sensitivity, decided before a task runs. This lesson turns the data boundary into a concrete, on-disk decision: where an agent actually runs, and what it can reach simply by being there.

A workspace is the data boundary made physical

Module 1's data boundary said what an agent may read and retain. It did not say where the agent sits while it works — and that turns out to matter as much as the tool grant itself. A tool scoped narrowly, exactly as Lesson 3 of Module 1 described, still only protects what it claims to protect if nothing else reachable from the agent's working location supplies the same access by another route.

OWASP's guidance on excessive agency defines excessive permissions as an extension holding "permissions on downstream systems that are not needed for the intended operation." A read-files tool written to only ever open files the agent is pointed at can still end up an excessive-permissions problem in practice, if the folder it runs in also happens to contain a tax return, a customer database export or an SSH key — because "the intended operation" was never actually fenced off from everything sitting next to it. The tool's own carefulness does not fix a location that was careless.

  • Root unsafe pattern: running agent work inside, or alongside, a working directory that also holds live personal or production data the task was never meant to touch.
  • The tool grant and the workspace location are two separate boundaries. Both have to hold. A narrow tool in a wide-open location is not a narrow grant.

One task, one dedicated, disposable workspace

The fix is not a cleverer tool — it is a habit: give each bounded task its own workspace, created fresh for that task, containing only what the task's input statement named, and disposable once the run ends.

Anthropic's engineering guidance backs this as a general pattern for trusting an agent with more autonomy, not a Local AI Agents invention: it recommends "extensive testing in sandboxed environments, along with the appropriate guardrails" before widening what an agent can do. A dedicated, disposable workspace is that sandbox, applied to routine runs rather than only to testing — the same reasoning, used every time instead of once before launch.

  • Dedicated — created for this task alone, not reused from a previous task or shared with the operator's everyday working directories.
  • Scoped to the declared input — holds only what Module 2's input statement actually named (source, scope), copied in deliberately, not whatever happened to already be in the folder.
  • Disposable — safe to delete or reset after the run without losing anything beyond the run itself, because nothing irreplaceable was ever stored there.
  • Separated — nowhere near anything the operator cannot afford to lose, leak or have quietly modified.

Why "it's just my laptop" is not the same question

Running an agent on your own development machine is not, by itself, the unsafe choice this lesson is about. The unsafe choice is running it inside — or with reach into — the same directories, browser profile, downloads folder or credential store you use for everything else. "My laptop" answers where the compute happens. It does not answer what the agent's workspace actually contains, and those are different questions with different answers.

Directory scoping is how you answer the second question in writing: name the exact directory tree the agent's tools may touch, and check that nothing outside it is reachable — not through a relative path, not through a symlink, not through a tool that quietly resolves "the parent folder" when asked.

A worked boundary: sorting a folder of research PDFs

An agent is asked to sort a messy folder of research PDFs into topic subfolders.

Version A runs the agent directly inside the operator's home directory, with read and write access to that whole tree, because the PDFs happen to live there already — next to tax documents, personal photos and a folder of SSH keys. The task only needed the PDFs, but the workspace choice handed it everything else in the same place.

Version B copies the PDFs into a fresh directory created for this run only, grants the agent's tools read and write access to that directory alone, and contains nothing else — no tax documents, no keys, no unrelated files. When the task finishes, the sorted result is reviewed and moved back by the operator (or by a separate, approval-required step), and the temporary workspace is deleted. The task gets done exactly the same way in both versions. Only the blast radius of a mistake changes.

Accessibility notes

This lesson is text-first, with no images, audio, video or downloadable artifacts. The practice exercise's model answer sits behind a native disclosure control that is reachable and operable by keyboard and correctly announced by screen readers. The knowledge check uses native radio-button inputs with a visible question and options, and posts its result to a live status region so assistive technology announces the outcome without a page reload.

Practice

Workspace boundary sketch: expense-receipt sorter

A local agent is asked to sort a folder of scanned expense receipts by month. The proposed setup points the agent at the operator's full Documents folder, because the receipts folder is a subfolder of it, and that folder also contains signed contracts, a password-manager export and a folder of family photos.

  1. Name what is unsafe about pointing the agent at the whole Documents folder for this task.
  2. Describe the dedicated, disposable workspace you would create instead: what goes into it, and what is deliberately left out.
  3. State what happens to that workspace once the sorting task is finished.
  4. Explain in one sentence why a narrowly-written sorting tool does not, by itself, fix an overly wide workspace.
Compare with a bounded first version

Pointing the agent at the whole Documents folder is unsafe because the task only needs the receipts, but the workspace choice also exposes signed contracts, exported passwords and family photos — none of which the sorting task's input statement named. A dedicated workspace copies only the receipt files into a freshly created folder for this run, with no other document types present. The write scope stays inside that same folder; nothing outside it is touched. Once sorting is confirmed complete, the workspace is deleted or reset, and the sorted receipts are moved back to their real destination as a separate step. A narrowly-written tool only protects what it claims to protect if the workspace does not hand it a wider reach through the folder it happens to be running in — the tool's own carefulness cannot compensate for a location that was never scoped.

Knowledge check

Try the idea

An agent that organizes PDF research papers is given read and write access to the operator's entire home directory, including a folder of SSH keys and a personal photo library, because creating a separate folder felt like extra setup. Is this workspace safe for the task?
Low-stakes practice only. This does not score, block progress or create a learner record.

Sources and limits

This lesson synthesises the sources below into a practical learning model. It is not a security standard, legal advice or a guarantee that any particular agent design is safe.

  1. Building effective agentsAnthropic Engineering. Recommends extensive testing in sandboxed environments with appropriate guardrails before trusting an agent more widely.
  2. LLM06:2025 Excessive AgencyOWASP Gen AI Security Project. Defines excessive permissions as downstream access beyond what the intended operation needs — a tool's own scope only holds if nothing else reachable from the agent's location supplies that access instead.
  3. LLM02:2025 Sensitive Information DisclosureOWASP Gen AI Security Project. Names personal identifiable information, financial details, health records, confidential business data, security credentials and legal documents as the categories a workspace boundary has to keep out.