Overview

This proposal translates three critical security findings into concrete, community-ready changes. The goal is to strengthen Moltbot's security posture—specifically around subagent isolation and browser tool safety—without disrupting the existing user experience.

I have a local proof-of-concept (PoC) for the fileId mapping ready. Happy to share a draft PR once the design is approved.

Proposed Changes (Task List)

• Enforce sandbox session isolation: Restrict subagents from accessing cross-session data.
• Path sanitization for browser proxy: Replace raw paths with opaque fileId to prevent file exfiltration.
• Session-scoped browser authorization: Implement capability tokens to prevent cross-session browser state leakage.

1) Enforce sandbox session isolation for subagents

Rationale

Currently, subagent sessions can bypass sandbox restrictions, allowing cross-session reads and messaging. This weakens the sandbox boundary. Enforcing this restriction restores the contract that sandboxed sessions cannot see unrelated sessions.

Logic Flow

graph TD
    A[Subagent Session] -->|Request sessions.list / chat.history| B{Gateway Guard}
    B -->|Check: target.spawnedBy == requesterID?| C{Authorized?}
    C -->|Yes| D[Grant Access to Session Data]
    C -->|No| E[Block: Sandbox Scope Violation]

Proposed Implementation

• Remove the subagent exception in restrictToSpawned logic.
• Add a gateway-level enforcement check for session-scoped APIs (sessions.list, sessions.resolve, chat.history).

2) Prevent browser proxy file exfiltration via path sanitization

Rationale

The browser proxy currently reads files based on user-provided paths, risking arbitrary file read/write. Replacing raw paths with opaque IDs and enforcing a strict allowlist eliminates path traversal and symlink abuse.

Secure Artifact Flow

sequenceDiagram
    participant B as Browser Route
    participant S as Storage (Allowlisted Root)
    participant G as Gateway Proxy
    
    B->>S: Write artifact to /browser-artifacts/
    S-->>B: Return local realpath
    B->>G: Register mapping: fileId -> realpath
    Note over G: Only fileId is returned to caller
    G->>S: On Read: Verify realpath is under ALLOWED_ROOT
    G->>S: Reject Symlinks
    S-->>G: Return bytes

Proposed Implementation

• Replace path in browser responses with an opaque fileId.
• Maintain a short-lived mapping of fileId -> realpath for the calling session.
• On proxy read: resolve the fileId, verify it is within the allowlisted root, and reject symlinks.

3) Require session-scoped authorization for browser control

Rationale

Currently, the browser is effectively shared across sessions, risking cross-session data leakage (tabs, cookies). A session-scoped capability token enforces ownership.

Authorization Path

graph LR
    A[Session] -->|browser.request + Token| B[Gateway]
    B -->|Enforce Allowlist| C[Browser Server]
    C -->|Verify Token & Profile| D[Controlled Browser Instance]

Proposed Implementation

• Mint a per-session capability token at session creation.
• Bind browser profiles to session allowlists; require explicit approval for high-risk profiles like chrome.

Request for Community Feedback

I am interested in contributing the code for these changes. Before I start the PR, I'd love to hear the maintainers' thoughts on:

1. Should the gateway guard also cover other session-scoped APIs?
2. What is the best expiration and storage strategy for fileId mappings?
3. What is the most developer-friendly flow for granting access to high-risk browser profiles?