File path read/write scopes are machine-enforced rules that constrain what an agent can read from disk and where it can write, down to specific directories and patterns. In Claw EA, you treat these rules as policy-as-code so they are enforced at execution time, not “requested” via a prompt.

This matters because prompt-only controls do not survive prompt injection, tool misuse, or a plugin that ignores instructions. With OpenClaw as the baseline agent runtime, you can combine sandboxing, tool policy, and a signed WPC to make filesystem access predictable and auditable.

Step-by-step runbook

  1. Inventory the agent’s real file needs by task. Split into read scopes (inputs, templates, reference docs) and write scopes (outputs, reports, patches), and list exact paths for each environment.

  2. Decide your boundary: host or sandbox. Prefer running file tools in an OpenClaw sandbox (Docker) and only mount the minimum directories required, explicitly setting ro or rw on each bind mount.

  3. Reduce the available tool surface. In OpenClaw, keep your tool profile tight and deny any file or shell tools you do not need, because unrestricted exec can bypass file policies by generating new tooling paths.

  4. Write a WPC = Work Policy Contract that declares allowed read and write path patterns, plus explicit denies for high-risk locations. Store the WPC in the WPC registry (served by clawcontrols) so the policy is a signed, hash-addressed artifact.

  5. Issue a CST = scoped token (issued by clawscope) for the job, including the scope hash and optionally pinning the policy hash. Use marketplace anti-replay binding (job-scoped CST binding) so a CST cannot be reused outside the intended run.

  6. Route model calls through clawproxy so you get gateway receipts for model calls. This gives you verification-grade evidence of which model requests were made under which CST and policy context.

  7. At the end of the run, export the proof bundle and store it for audit, optionally publishing to Trust Pulse for viewing. If you need per-file open/read/write telemetry, implement it in your OpenClaw tool wrappers and include the resulting logs as additional artifacts alongside the proof bundle.

Threat model

File scopes primarily prevent “local data spill” and “local persistence” failures, where an agent reads secrets or writes into sensitive areas. They also reduce lateral movement when a tool or plugin is compromised, because the allowed filesystem surface is small.

Threat What happens Control
Prompt injection asks the agent to read secrets The agent attempts to read SSH keys, cloud credentials, browser profiles, or .env files and exfiltrate them. Default-deny read scopes with explicit allowlists; keep secrets outside any mounted sandbox binds; avoid mounting home directories.
Path traversal and wildcard abuse The agent targets ../ or broad globs to escape intended directories. Normalize paths and enforce prefix checks; disallow relative paths; use explicit patterns and deny rules for parent traversal tokens.
Symlink escape A path inside an allowed directory is a symlink to a disallowed location, causing reads or writes to land outside the scope. Resolve realpath before authorization; disallow symlink following for sensitive tools; enforce “no symlink” in write targets.
Persistence by writing into startup or config locations The agent writes to shell rc files, scheduled tasks, service definitions, or app plugin directories. Explicit deny list for known persistence locations; write scopes restricted to a dedicated output directory; sandboxed execution.
Log and artifact poisoning The agent overwrites evidence files, modifies logs, or replaces a report after review. Separate write scopes for outputs vs evidence; append-only log strategy (can be implemented); store proof bundles out-of-band.

On Windows fleets, pair path scopes with NTFS ACLs and separate service accounts to ensure the OS denies access even if a tool is misconfigured. In Microsoft environments, identity controls like Entra ID Conditional Access and PIM apply to interactive access and admin elevation, but they do not replace per-job file scopes inside the agent runtime.

Policy-as-code example

This example shows a compact, JSON-like policy shape you can carry as a WPC and translate into OpenClaw sandbox binds plus tool-level checks. Keep it explicit: list what is allowed, then deny the rest.

{
  "wpc_version": "1",
  "policy_name": "agent-file-scopes:v3",
  "target_runtime": "openclaw",
  "filesystem": {
    "read_allow": [
      "/workspace/input/**",
      "/workspace/templates/**",
      "C:\\\\agent\\\\input\\\\**"
    ],
    "write_allow": [
      "/workspace/output/**",
      "C:\\\\agent\\\\output\\\\**"
    ],
    "deny": [
      "/home/**/.ssh/**",
      "/etc/**",
      "/proc/**",
      "/var/run/docker.sock",
      "C:\\\\Users\\\\**\\\\.ssh\\\\**",
      "C:\\\\Windows\\\\System32\\\\**"
    ],
    "rules": {
      "require_absolute_paths": true,
      "resolve_realpath_before_check": true,
      "deny_symlink_write_targets": true
    }
  },
  "openclaw": {
    "sandbox": {
      "mode": "all",
      "workspaceAccess": "rw",
      "docker_binds": [
        { "host": "/srv/agent/input",  "container": "/workspace/input",  "mode": "ro" },
        { "host": "/srv/agent/output", "container": "/workspace/output", "mode": "rw" }
      ]
    },
    "tools": {
      "deny": ["elevated.exec"],
      "allow": ["read", "write", "edit", "apply_patch"]
    }
  }
}

Operationally, treat the WPC hash as the stable identifier. Your deployment should fetch and verify the WPC from clawcontrols, then configure the runtime from that artifact so “what was enforced” is deterministic.

What proof do you get?

For model traffic, clawproxy emits gateway receipts for model calls. Those receipts can be bundled with job metadata into a proof bundle, so an auditor can verify which model calls occurred under a specific CST and the pinned WPC hash.

For filesystem controls, the proof you can always show is the policy artifact itself: the signed, hash-addressed WPC plus the CST scope hash and optional policy hash pinning. If you need per-operation evidence like “file X was written at time Y,” implement file tool wrappers that log allowed and denied accesses and include those logs as additional artifacts alongside the proof bundle.

Where appropriate, publish the proof bundle to Trust Pulse for storage and viewing. Keep the policy hash, CST identifiers, and receipt IDs consistent across your incident response workflow so you can answer “what ran under what rules” without reconstructing state from prompts.

Rollback posture

Rollback for file scope controls should be fail-closed. When something goes wrong, your safest move is to reduce write permissions, rotate the CST, and rerun under a tighter WPC rather than trying to “undo” unknown writes.

Action Safe rollback Evidence
Agent wrote to an unexpected directory Update the WPC to remove the write scope, re-issue a CST pinned to the new policy hash, and rerun in a fresh workspace/output directory. New WPC hash in the WPC registry; CST scope hash; proof bundle showing the change boundary.
Suspected secret exposure via local reads Move secrets out of any mounted paths, tighten read scopes to a minimal input directory, and rotate impacted credentials outside the agent system. WPC deny rules; OpenClaw sandbox bind list (as config artifact); gateway receipts showing what model calls occurred during the window.
Need to temporarily allow a new output path for a hotfix Create a short-lived WPC variant that adds a single write path and expires operationally by issuing a short-TTL CST, then revert to the prior WPC hash after the run. Two WPC hashes (before and after); job-scoped CST binding; proof bundles for both runs.
Tooling bypass attempt via elevated execution Keep tools.elevated denied by default; if it must exist, gate it behind separate operational approvals (can be implemented) and isolate it to a break-glass agent profile. OpenClaw effective tool policy via inspection; WPC policy that denies elevated exec; proof bundle tying the run to that policy hash.

FAQ

Why are prompt instructions not enough for file safety?

Because the model can be induced to ignore them, and tools can be invoked in ways your prompt did not anticipate. Policy-as-code makes the runtime deny the operation even if the model requests it.

Should I enforce file scopes in the sandbox, the tool layer, or both?

Both when possible. Use the sandbox to reduce what the process can see, and use tool-layer checks to enforce exact path rules and to handle cases like symlink resolution.

How do I handle Windows paths and mixed OS fleets?

Write OS-specific allowlists and deny lists, and keep the effective policy explicit per environment. On Windows, also rely on NTFS ACLs to ensure the OS denies access even if an agent tool is misconfigured.

Can an agent still leak data if it can read allowed files?

Yes, it can summarize or copy allowed content into outputs or model messages. File scopes reduce what can be read, and clawproxy gateway receipts give you evidence of model calls, but you still need data classification and redaction decisions for what enters the workspace.

What is the minimum audit package I should retain?

Retain the WPC artifact (by hash), the CST scope hash and any policy hash pinning, and the proof bundle containing gateway receipts for model calls. If you add file access logs, retain them as immutable artifacts referenced by the same job metadata.

Sources