feat: profile boundary isolation for cross-profile data protection

[whyihaveyou]

Summary

Add is_within_profile_boundary() guard to file tool operations to prevent named profiles from accessing other profiles' data directories (memory, sessions, config).

Problem

In multi-profile setups (e.g., separate Feishu bots per profile), all profiles share the same Python venv and codebase. Without boundary enforcement, one profile's agent could accidentally — or via LLM hallucination — read or modify another profile's memory, sessions, or configuration.

This was discovered after a real incident where a frog profile agent rebuilt the shared venv, breaking TLS for all profiles simultaneously.

Changes

File	Description
hermes_constants.py	Add is_profiled_mode(), get_profile_boundary(), is_within_profile_boundary() — soft isolation that blocks cross-profile access while preserving full filesystem access for project work
tools/file_tools.py	Add boundary checks at all four file operation entry points (read_file, write_file, patch, search)
tests/test_profile_boundary.py	28 tests covering default profile (admin, unrestricted), named profiles (restricted), symlinks, tilde expansion, edge cases

Design Decisions

• Soft isolation, not sandbox: Named profiles still need to read/write project code, system configs, and installed tools. The guard only blocks access to ~/.hermes/profiles/OTHER_PROFILE/.
• Default profile is admin: The default profile (HERMES_HOME == ~/.hermes) has no restrictions — it needs access to all profiles for management tasks (profile list, skill syncing, etc.).
• LLM-level only (for now): The guard applies to file_tools.py (the LLM's file interface). Terminal and execute_code can still bypass via cat/open(). A future PR could extend this to approval.py patterns.

Known Limitations

• Does not cover terminal_tool.py or code_execution_tool.py — those can still access arbitrary paths via shell commands. Suggested follow-up: add dangerous path patterns to approval.py.
• Venv sharing is the remaining blast radius — this PR addresses data isolation, not dependency isolation.

Test Plan

• 28 new tests all pass
• Existing test suite passes on this branch
• Tested in production with two profiles (default + frog) on macOS

[teknium1]

Thanks for the profile-isolation work. Current main has since merged a narrower soft cross-profile write guard in #31290 (d3c167b64472ee35e52d5201014e940c965579ef), but this patch needs substantial re-scoping before it can be salvaged.

Problems

• tools/file_tools.py:583 only checks the explicit path; normal V4A mode="patch" calls provide targets in patch headers with path=None, so this guard does not inspect them. Current main extracts and checks V4A targets at tools/file_tools.py:1731-1783.
• The new is_profiled_mode() reads raw HERMES_HOME, bypassing the context-local profile override supported by current hermes_constants.py:23-77.
• The proposal hard-blocks cross-profile reads/searches across an entire profile. Current main intentionally permits explicit read-only cross-profile session access via tools/session_search_tool.py:631-675; the broader policy needs an explicit threat-model decision.

Suggested changes

• Build any follow-up on the current agent/file_safety.py classifier and its scoped soft-guard/explicit-consent model.
• Cover V4A targets, task-relative paths, and context-local profile resolution.

Automated hermes-sweeper review.

[teknium1]

For mode="patch", callers normally omit path, so this list remains empty and the *** Update File: target is never boundary-checked. Extract every V4A Update/Add/Delete/Move target before this loop; current main's equivalent handling is at tools/file_tools.py:1731-1783.