3.8 File and filesystem access controls
How to scope which folders an agent can read and write, and how to keep home directories, secrets, and cloud-synced roots out of default access.
Last reviewed: August 18, 2026
File and filesystem access controls: what security teams need to know
Agents are often useful because they can read and edit files. That access should be intentional. A broad folder grant can expose unrelated projects, personal files, credentials, and synced documents.
Good filesystem control starts before the session. Choose the workspace, exclude sensitive paths, decide what can be written, and make destructive actions hard to approve by accident.
Common file and filesystem access controls security failures
The agent starts in the user's home directory.
Cloud-synced folders expose files from unrelated teams.
Secrets live in the same project root as the work.
Generated files overwrite source or evidence without review.
The agent can delete or rename broad directory trees.
File and filesystem access controls security controls checklist
Start agents in a narrow project directory.
Keep home, Desktop, Downloads, cloud drives, password stores, and secret stores outside normal scope.
Use deny rules for
.env, key files, tokens, and credential directories.Require approval for deletes, moves, broad rewrites, and generated code touching sensitive paths.
Log denied reads and writes to sensitive locations.
Anthropic
Overview
Claude Code is where filesystem policy is enforceable. It starts from read-only permissions and prompts before edits, and permission rules can deny reads and edits of specific paths such as .env files, key material, and credential directories. Deny rules take precedence over ask and allow, so a sensitive-path deny list holds even against a broad allow rule, and managed settings push those rules organization-wide, which is how a file-access standard becomes more than a team convention.
Two adjacent surfaces widen local file reach: desktop extensions and local MCP servers run with local access on Claude Desktop and Claude Code, while Cowork remote sessions can reach folders connected through Claude Desktop only while that app is online. Those files are processed in the remote session on Anthropic's servers, and each local call is checked against the member's folder permissions. Managed Agents cloud sandboxes contain file work inside an isolated Linux container instead.
Claude Tag channel sessions can read and write files inside their per-thread hosted sandbox, but files that exist only there disappear when the sandbox is released. Persisted outputs must be posted to Slack or pushed to a connected repository or service, which creates a separate sharing and authorization event. Do not confuse ephemeral sandbox storage with a guarantee that the thread, memory, transcript, or exported result is ephemeral.
Anthropic documentation
Applicable Harmonic guides for Anthropic
OpenAI
Overview
For Codex, sandbox mode is the filesystem policy. Read-only mode lets the agent inspect but not change files; workspace-write limits writes to the workspace, with command network access off by default; danger-full-access removes the boundary and belongs only in disposable environments. The mode names are the review vocabulary: "which mode, over which directory" answers most file-access questions, and approval policy governs when the agent can escalate past the mode's limits.
Managed configuration can pin which sandbox modes and approval policies are available, so organizations can keep full access out of reach for standard users rather than relying on prompts. Desktop Work uses the same local permission plane as Codex and can open local folders or projects. Work on web and mobile cannot directly access computer files; it uses uploaded files, workspace resources, and connected systems instead. Treat those as data flows rather than filesystem grants.
OpenAI documentation
Applicable Harmonic guides for OpenAI
Frequently asked questions about file and filesystem access controls
What folders should AI agents access?
Only the project directory the task needs, added explicitly and removed when the work ends. Broad grants such as home directories, Documents, or whole-drive access expose unrelated projects, personal files, and synced content the user forgot was there. The folder choice is the single highest-leverage filesystem control because everything else operates inside it.
Should agents read .env files?
Block them by default with deny rules, along with key files, token caches, and credential directories. If a task genuinely needs configuration, provide sanitized examples or inject secrets through an approved mechanism at runtime rather than letting the agent read live values. A leaked .env in a prompt or log is a credential incident, not a hygiene issue.
Are cloud-synced folders safe?
They are risky as agent workspaces on two counts: they often contain files from unrelated teams and projects, and agent writes propagate through sync, so an unwanted mass edit or delete replicates to every device and collaborator before anyone reviews it. Prefer a local, narrowly scoped project directory and copy results into synced locations deliberately.
How should deletes be handled?
Require explicit approval for deletes, renames, moves, and any operation touching many files, and make the approval show the full scope before it executes. Version control is the safety net for repositories; for everything else, prefer soft-delete or staging patterns so a wrong approval is recoverable.
What file activity should be logged?
For the filesystem specifically: denied reads and writes on sensitive paths, which are the high-signal events, plus successful writes and deletes with paths, the workspace root for the session, and any change to file-access policy itself. Pair this with the session-level sandbox-mode logging from 3.1 so an investigator can tie a file event to the boundary that allowed it.
Applicable regulations and frameworks
G.1 Map your controls to NIST AI RMF and CSF 2.0
This article supplies implementation evidence for the NIST AI RMF and matching NIST CSF 2.0 outcomes.
G.3 DORA and AI resilience in financial services
Conditional: for a DORA-regulated workflow, this supports ICT containment, resilience, continuity, and recovery.
G.5 SANS Critical AI Security Guidelines mapping
This article implements relevant SANS Deployment Strategies and Inference Security guidance.
G.6 Write an AI Acceptable Use Policy that holds up
This article supplies a technical or process control used to enforce the acceptable-use policy.
G.7 Ownership and RACI for AI security
This control depends on the ownership and evidence responsibilities defined in the RACI.
G.9 HIPAA controls for AI systems handling PHI
Conditional: for a workflow handling ePHI, this supports HIPAA technical access, integrity, transmission, availability, and audit safeguards.
G.2, G.3, G.4, and G.9 are conditional mappings. They apply only when the deployment is within the legal or regulatory scope described on the linked governance page.
Related handbook guidance
Was this helpful?