Problem
In multi-agent setups, all agents run as the same OS user and have unrestricted filesystem access through the read, write, edit, and exec tools. There is no way to restrict which files an agent can access.
Real-world impact: We run 3 agents (Dave/COO, Jim/CSO, Fin/CFO) with different trust levels and roles. Jim and Fin should not be able to read openclaw.json (contains tokens, API keys, bot credentials) or access each other's workspaces. Currently, the only guardrail is prompt-based instructions in SOUL.md — which we tested and found unreliable:
- GPT 5.3-Codex (Fin): Respected the SOUL.md instruction and refused to read config ✅
- Gemini 3 Flash (Jim): Ignored the instruction and read the config file ❌
- Worse: Jim refused when the user asked directly (appeared compliant) but complied when another agent asked via A2A (hidden non-compliance)
Prompt-based guardrails are not enforcement. Models vary in compliance, and A2A requests bypass apparent user-facing compliance.
Proposed Solution
Per-agent file path allowlist/denylist, enforced at the tool execution layer (not the prompt layer).
{
"agents": {
"list": [
{
"id": "jim",
"access": {
"rules": [
{ "allow": "/home/mark/clawd-jim/**", "ops": ["*"] },
{ "allow": "/home/mark/.openclaw/extensions/**", "ops": ["read"] },
{ "deny": "/home/mark/.openclaw/openclaw.json", "ops": ["*"] },
{ "deny": "/home/mark/.openclaw/certs/**", "ops": ["*"] },
{ "deny": "/home/mark/clawd/**", "ops": ["*"] },
{ "deny": "/home/mark/clawd-finance/**", "ops": ["*"] }
]
}
}
]
}
}
Key requirements:
- Enforced at tool level —
read, write, edit check paths before execution
exec tool coverage — best-effort path extraction from shell commands
- Per-agent overrides — different agents get different access scopes
- Deny by default option — whitelist mode where only explicitly allowed paths are accessible
- A2A respects caller's restrictions — when Agent A asks Agent B to do something, Agent B's file restrictions still apply
Prior Art
Issue #513 proposed a comprehensive design for this (path-based access control with glob patterns, per-agent overrides, deny-wins mode). It was closed during maintainer triage, not because it was implemented or rejected. The design in #513 is excellent — this issue is a real-world validation that the feature is needed.
Also related: #9348 (sandbox write/exec inconsistency), #7284 (per-model tool policies).
Environment
- OpenClaw 2026.2.6-3
- 3 agents, local mode (no Docker sandbox)
- Multi-agent with A2A enabled
Problem
In multi-agent setups, all agents run as the same OS user and have unrestricted filesystem access through the
read,write,edit, andexectools. There is no way to restrict which files an agent can access.Real-world impact: We run 3 agents (Dave/COO, Jim/CSO, Fin/CFO) with different trust levels and roles. Jim and Fin should not be able to read
openclaw.json(contains tokens, API keys, bot credentials) or access each other's workspaces. Currently, the only guardrail is prompt-based instructions in SOUL.md — which we tested and found unreliable:Prompt-based guardrails are not enforcement. Models vary in compliance, and A2A requests bypass apparent user-facing compliance.
Proposed Solution
Per-agent file path allowlist/denylist, enforced at the tool execution layer (not the prompt layer).
{ "agents": { "list": [ { "id": "jim", "access": { "rules": [ { "allow": "/home/mark/clawd-jim/**", "ops": ["*"] }, { "allow": "/home/mark/.openclaw/extensions/**", "ops": ["read"] }, { "deny": "/home/mark/.openclaw/openclaw.json", "ops": ["*"] }, { "deny": "/home/mark/.openclaw/certs/**", "ops": ["*"] }, { "deny": "/home/mark/clawd/**", "ops": ["*"] }, { "deny": "/home/mark/clawd-finance/**", "ops": ["*"] } ] } } ] } }Key requirements:
read,write,editcheck paths before executionexectool coverage — best-effort path extraction from shell commandsPrior Art
Issue #513 proposed a comprehensive design for this (path-based access control with glob patterns, per-agent overrides, deny-wins mode). It was closed during maintainer triage, not because it was implemented or rejected. The design in #513 is excellent — this issue is a real-world validation that the feature is needed.
Also related: #9348 (sandbox write/exec inconsistency), #7284 (per-model tool policies).
Environment