security: Agent writes public-link user PII to shared agent memory, leaking it to all other users

[vybe]

Summary

When a user of a public agent link asks the agent to "remember" personal information, the agent writes that data to its own file-based memory store (/home/developer/.claude/projects/-home-developer/memory/). This memory is loaded into every future conversation the agent has — with all users, across all channels. Personal details one user shares (name, contact info, preferences) are silently exposed to every subsequent user of that agent. This is a P0 privacy violation: PII from one user leaks to all other users via the agent's shared workspace.

Component

Agent Runtime / Public Links / Per-User Memory (MEM-001)

Priority

P0 — PII cross-user leakage

Observed Behavior

1. User A chats with an agent via a public link and says "please remember my name is [NAME]".
2. The agent calls the Write tool and saves [NAME] to /home/developer/.claude/projects/-home-developer/memory/user_NAME.md.
3. The platform loads this memory file at the start of every future execution (it appears in memory_paths.auto).
4. User B opens the same agent — the agent's system context now contains User A's name, email, and any other details User A asked to save.
5. No error is raised; no permission is denied; the file write succeeds silently.

Root Cause

Trinity's auto-memory system (memory_paths.auto) is agent-scoped, not user-scoped. The path /home/developer/.claude/projects/-home-developer/memory/ lives in the agent container's shared workspace. All executions — regardless of which user triggered them — share this directory.

When a user explicitly requests that information be saved and the agent has the Write tool available (which it does, even in bypassPermissions mode — see related issue #887), the agent follows its memory instructions and writes the data to the shared store.

The per-user memory feature (MEM-001, public_user_memory table) only operates via automatic background summarization every 5 messages; there is no MCP tool for agents to explicitly write to the per-user store. The agent therefore falls back to the only write mechanism available: its own shared filesystem.

Privacy Impact

• User A's PII (name, contact details, preferences) is stored in a file readable by:
  • All other users of the same agent
  • The agent operator (via workspace file browser)
  • Any MCP client with access to the agent
• The agent actively presents this information to other users ("I remember you're [name from User A]")
• There is no opt-out, TTL, or isolation boundary

Reproduction Steps

1. Deploy any agent with public link access enabled
2. Open the agent via its public link as User A
3. Send: "please remember that my name is [any name]"
4. Observe the agent writes a memory file to its workspace
5. Open the same agent as User B (different session/browser)
6. Ask the agent "do you know anything about me?" or simply observe what context it loads
7. Agent responds with User A's personal details

Suggested Fix

Three layers of defense are needed:

1. Immediate: Platform-injected guardrail (INJECT-136)

Inject a platform instruction that prohibits agents from writing user-identifying information from public link or WhatsApp/Telegram/Slack sessions to the shared agent memory directory:

When operating in a public link or channel-based session:
- Do NOT write user-identifying information (names, emails, contact details, personal facts) to the agent memory directory.
- The agent memory at ~/.claude/projects/ is shared across all users. Writing personal data there creates a privacy violation.
- To persist user preferences, use the platform's per-user memory system (write_user_memory tool) when available.

2. Medium term: Expose a write_user_memory MCP tool

Extend MEM-001 to provide an explicit tool agents can call to write to the public_user_memory table, scoped to the verified user email:

# New MCP tool
def write_user_memory(agent_name: str, user_email: str, key: str, value: str):
    """Write a user-scoped memory entry to public_user_memory table."""
    # Stored isolated per (agent_name, user_email) — never accessible cross-user
    ...

This gives agents a correct, safe alternative to the shared filesystem.

3. Long term: Block writes to the memory directory from channel-triggered executions

When an execution is triggered by whatsapp, telegram, slack, or public_link, the platform should either:

• Scope memory_paths.auto to a per-user subdirectory (e.g. /home/developer/.claude/projects/-home-developer/memory/users/{hashed_email}/)
• Or suppress the memory_paths injection entirely for public-session executions

Related

• Related issue: bug: Read-only mode hooks don't block Write/Edit tools, only Bash #887 (read-only mode doesn't block Write tool — same Write call is how the PII is written)
• MEM-001: per-user memory background summarization (public_user_memory table)
• INJECT-136: platform instructions via --append-system-prompt
• public_user_memory table: agent_name, user_email, memory_blob, updated_at

[vybe]

/claim

[github-actions]

Claimed by @vybe. Label status-in-progress added.

Next steps:

1. Create branch: feature/888-<short-slug>
2. Implement the feature
3. Open a PR with Fixes #888

[vybe]

/claim

[github-actions]

@vybe This issue is already assigned to vybe. Use /unclaim first if you want to take over.

[vybe]

/claim

[github-actions]

@vybe This issue is already assigned to vybe. Use /unclaim first if you want to take over.