Context

Second is moving to a multi-agent-per-org model where each user within an organization gets their own agent instance. Each agent has access to user-scoped integrations (e.g., personal Gmail, Calendar, Drive) while sharing org-level resources (files, SOPs, playbooks).

The current tool-level config (tools.allow/tools.deny) is necessary but not sufficient to enforce user-to-user isolation within a single OpenClaw instance. The following platform-level primitives are required before multi-agent rollout.

Prerequisites

1. Agent-scoped session visibility

sessions_list / sessions_history must filter results by the calling agent's identity. Rob's agent should never see Darian's session history or vice versa.

• Today this only works in sandbox mode via agents.defaults.sandbox.sessionToolsVisibility: "spawned"
• Need: Either sandbox all agents, or build a non-sandbox agent-level session filter
• Interim mitigation: sessions_send is denied until this is confirmed

2. Agent-to-channel binding

The message tool must enforce that each agent can only send on channels bound to its user.

• Shared org channels (Slack workspace, shared inbox): accessible to all agents
• Personal channels (individual Gmail, personal calendar): agent-locked — only the owning agent can send
• Risk if missing: Rob's agent could send email as Darian

3. Agent-scoped cron ownership

Cron jobs must be tagged with the creating agent's ID.

• cron list / cron remove / cron update should only return/affect the calling agent's jobs
• Cron-triggered sessions must run under the creating agent's identity and integration scope
• Risk if missing: Darian's agent could modify or delete Rob's scheduled operations

4. Per-agent workspace isolation

Directory structure should enforce per-user boundaries while allowing shared org data:

/data/workspace/
├── shared/          # org-wide files, SOPs, playbooks (all agents read/write)
├── agents/
│   ├── rob/         # Rob's MEMORY.md, notes, personal context
│   └── darian/      # Darian's MEMORY.md, notes, personal context

• read/write/edit/memory_* tools should respect these boundaries
• Agents should not be able to read or write to another agent's personal directory

5. Integration credential scoping

Skills (Shopify, QuickBooks, Google Drive, etc.) need to resolve the correct OAuth tokens based on the calling agent's identity.

• Org-wide integrations (shared Shopify store): use org-level credentials, accessible to all agents
• Personal integrations (Gmail, Calendar, Drive): use the specific user's OAuth tokens
• Risk if missing: Rob's agent could access Darian's Gmail via the Google Drive skill

Acceptance Criteria

• Agent A cannot list or read Agent B's sessions
• Agent A cannot send messages on Agent B's personal channels
• Agent A cannot list, modify, or delete Agent B's cron jobs
• Agent A cannot read or write to Agent B's personal workspace directory
• Agent A's skill invocations use the correct user's credentials for personal integrations
• All of the above are enforced at the platform level, not just by config convention

Related

This issue was identified during a tool permission security assessment for the Second agent. The revised tools.allow/tools.deny config assumes these primitives will be built. Until then, sessions_send is denied and agents.defaults.sandbox.sessionToolsVisibility is set to "spawned" as interim mitigations.