Filesystem and network scope

By the end, you can

• Distinguish read, write and execute filesystem grants, and treat network access as a boundary separate from filesystem access, with exfiltration as its specific risk (LA-3).
• Identify unsafe permission choices in a proposed agent configuration, and configure a least-privilege run plan for a given scenario (LA-2, LA-3).

Before you start

This is Module 3, Lesson 3 of the Local AI Agents course, and the last lesson before Module 4's work on evidence and evaluation. It assumes this module's first two lessons — a dedicated, disposable workspace, and credentials kept out of an agent's reach by default — plus Module 1's automatic / approval-required / out-of-scope classification and its excessive-functionality and excessive-permissions distinction. This lesson names the specific grants a workspace boundary is made of, adds network access as a boundary of its own, and asks you to combine all of it into one written run plan.

Read, write and execute are three different grants, not one toggle

"File access" is often treated as a single switch: on or off. It is really three separate grants, and a task rarely needs all three.

OWASP's guidance on excessive agency applies here exactly as it did to the tool grants in Module 1 Lesson 3: functionality or permissions "not needed for the intended operation" are excessive whether or not they are ever used. A log-summarizing task that can read logs needs read access only — granting write or execute "in case it's useful" repeats the same pattern this course has already named twice, on a different axis.

• Read — list or open existing files. A task that only summarizes or checks content needs this and nothing more.
• Write — create, modify or delete files. A task needs this only if producing its output means changing something on disk.
• Execute — run a file as a program or script. Very few everyday agent tasks need this at all, and it is the grant most likely to turn a scoping mistake into an active problem rather than a passive one.

Network access is a distinct boundary, not a filesystem detail

Network access does not fit neatly inside the read/write/execute set, because it is not about the workspace at all — it is about whether data can leave the workspace, regardless of how tightly the filesystem itself is scoped. A perfectly read-only, perfectly disposable workspace can still leak its contents if the agent can make an outbound request to an address it — or something it read — chose.

OWASP's guidance on prompt injection makes this concrete rather than hypothetical: one documented pattern causes "the LLM to insert an image linking to a URL, leading to exfiltration of the private conversation." Nothing was written to disk in that example. The leak happened entirely over the network boundary, triggered by content the system processed rather than by anything the operator asked it to do.

This is a risk to name honestly, not a reason to treat all network access as forbidden. A task that legitimately needs to call one specific API should be able to. The unsafe pattern is the same unscoped-grant pattern from Lesson 1's workspace and Module 1's tool grants, applied to network reach:

• Named destination only — the agent may reach one stated host or endpoint, not "the internet."
• Named verbs only — for example, read-only requests to a lookup API, not arbitrary requests of any kind.
• No following of attacker-reachable links — the agent must not resolve or request a URL found inside content it read, which is exactly the mechanism the exfiltration example above depends on.

Combine the scopes into a least-privilege run plan

A least-privilege run plan is a short, written statement of exactly what a specific bounded task may do across all four grants, decided before the run — the concrete artifact this module has been building toward.

• Filesystem read scope — exactly what may be read, named specifically enough that "everything in the workspace" is not an acceptable answer if the workspace holds more than the task's declared input.
• Filesystem write scope — what, if anything, may be created or modified, and where.
• Execute scope — almost always none; state the justification when it is not.
• Network scope — none, or one named destination and named verbs.
• Classification — for anything beyond the automatic set, Module 1's approval-required or out-of-scope label, using OpenAI's guardrails guidance: human review "pauses the run so a person or policy can approve or reject a sensitive action" before it takes effect.

A worked example: a dependency-upgrade summary agent

A local agent is asked to read a project's dependency manifest and draft a summary of available upgrades. Run plan: read scope is the one named manifest file, plus read-only requests to the package registry's lookup API for version information — nothing else in the project tree, no other API. Write scope is a single new draft file inside the task's dedicated workspace from Lesson 1; nothing outside it. Execute scope is none — the task never needs to run any script to compare version numbers. Network scope is limited to the one named registry host, GET requests only, with no following of any link that might appear inside a package's own description text. Nothing in this run plan is automatic without review the first time it runs; once the manifest-read and registry-lookup pattern has been reviewed and found safe, it is a reasonable candidate to move toward automatic, following Module 1 Lesson 2's classification procedure.

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.

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. LLM06:2025 Excessive Agency — OWASP Gen AI Security Project. Defines excessive functionality and excessive permissions, the same standard this lesson applies separately to read, write, execute and network grants.
2. LLM01:2025 Prompt Injection — OWASP Gen AI Security Project. Documents a concrete exfiltration example where a manipulated response inserts a link that leaks data over an outbound network request.
3. Guardrails and human review — OpenAI API documentation. Explains pausing a run for human approval before a sensitive tool action, the mechanism a network or write action's approval-required classification hands control to.