GitHub Repo
Hermes Agent patches cross-profile credential fallback; full isolation remains unverified
The main branch now tracks directory ownership in credential scopes, addressing some isolation issues involving missing values and initialization failures. Review comments still raise questions about other fallback paths, so deployers need to check their installed version.
On September 23, Nous Research merged a set of credential isolation fixes into the Hermes Agent main branch, addressing cases where the agent continued using credentials from its startup environment after switching profiles when keys were missing or reads failed. The fixes cover the desktop backend, scheduled jobs, and MCP connections. What is currently confirmed is the change to the main branch; existing installations cannot be assumed to include it. [Merge record](https://github.com/NousResearch/hermes-agent/pull/120128)
Each Hermes profile has its own data directory and credentials. The problem was that the previous credential scope stored only names and values, without recording which directory they belonged to. Some backends run tasks for other profiles even when the mode that lets multiple profiles share a process is disabled. In those cases, a missing value could trigger a fallback to the process environment, retrieving a key from the startup profile. [Original patch description](https://github.com/NousResearch/hermes-agent/pull/119459)
The new logic adds directory ownership information to the scope. When serving another profile, it returns the caller’s default value if a key cannot be found. Tests cover normal routing and task execution paths where the home directory has not been switched; environment-based credential injection for the startup profile itself is preserved. [Patch and tests](https://github.com/NousResearch/hermes-agent/pull/119459) From a deployment perspective, if a research profile lacks a service key, the expected outcome should be an unavailable feature or a prompt to complete the configuration. Automatically borrowing credentials from a work profile could send requests to the wrong account, changing both the scope of data access and which account incurs the charges.
Another fix places scope setup inside a block that guarantees cleanup. Previously, if a directory was corrupted or had been deleted, an error partway through initialization could leave partially initialized state behind, causing subsequent operations to continue pointing to the wrong directory. The patch adds cleanup on failure and regression tests, and also prevents a failure to re-register one MCP connection from blocking other connections. [Initialization patch](https://github.com/NousResearch/hermes-agent/pull/119486)
However, reviewers on the pull request still raised concerns about the shared tool credential resolver, some API key reads, and authorization settings for plugins that had not yet been registered. These comments concern specific commits. They cannot be treated as definitive findings of vulnerabilities in all current versions, nor do they justify claiming that the entire class of cross-profile issues has been eliminated. [Review discussion](https://github.com/NousResearch/hermes-agent/pull/120128)
Deployers should next verify their installed commit, configure credentials for each profile, and test missing values, read exceptions, and profile switching. The official architecture documentation also explicitly limits the scope of isolation: profile isolation does not cover end-user authentication and authorization, so access controls at the service entry point still need to be designed separately. [Architecture documentation](https://hermes-agent.nousresearch.com/docs/developer-guide/multiplexing-gateway)