GitHub Repo
Hermes Agent Community Calls for Limits on Cross-Profile Conversation Search, Public Code Reveals Data Isolation Boundaries
A Hermes Agent community proposal on October 30 said the conversation search tool can target other profiles and read their history. Public code confirms a cross-profile read path, but maintainers have not confirmed the proposed restrictions, and the practical impact depends on deployment permissions.

On October 30, the Hermes Agent community filed an issue asking for cross-profile access restrictions in session_search. The reporter said that when different profiles on the same host are assigned to different users or low-trust tasks, an agent can still read records from other profiles using the profile parameter and conversation links containing profile names. As of this review, the issue remained open, with no confirmation from maintainers or merged fix. Community issue
The official documentation defines profiles as separate Hermes home directories that store configuration, API keys, memory, conversations, and state databases independently. This makes them useful for separating coding assistants, personal bots, and research agents. This storage arrangement prevents state from being mixed; however, the report and code suggest that deployers still need to verify separately whether tools can read data across directories. Profiles documentation
In the current main branch, the search tool parses the profile name from a conversation link, then _resolve_profile_db normalizes the name, validates its format, and confirms that the profile exists before opening the target state.db in read-only mode. The function does not appear to check the caller's profile against an allowlist. Another section of code prohibits automatically searching every profile based only on a bare conversation ID, but explicitly preserves the option to read from a specified profile. Read-only mode prevents writes, but still allows conversation contents to be included in the tool's returned results. Public code
The reporter proposed adding session_search.allow_profiles: the default would preserve existing behavior, a specified list would restrict which profiles can be read, and an empty list would allow access only to the current profile. The author said their branch passed 67 search-tool tests but did not run the full test suite; those results have not been independently reproduced, and the setting is not yet an official feature. Proposal and test details
For engineering teams, the key questions are whether cross-profile search will gain an authorization check and how its default will preserve existing memory retrieval workflows. Current evidence supports the existence of a cross-profile read path, but does not establish that it can bypass operating system file permissions. Risk assessments should account for the directories the process can actually read, which tools are available, and the trust relationships among users.