What happens when multiple users share one Hermes process for MCP access?

Why shared Hermes sessions break the MCP trust boundary

When one Hermes process serves multiple users, the MCP client state stops being user-specific and becomes process-specific. That means the process can reuse the same connections, token cache, and authorization context across people, so the boundary is no longer “this user” but “this process.” In practice, that is a sharing model, not isolation.

The key problem is that MCP access often depends on both network connections and stored OAuth tokens. If those live inside one process, any session state that the process can see may also be reachable by other users routed through the same process. A profile can separate preferences, but it does not automatically separate runtime authority or secret material.

This is why the answer changes depending on whether you are asking about convenience or security. Shared process access may work for demos or single-operator setups, but for real multi-user use it creates cross-user visibility and access bleed unless the runtime is isolated at the OS or container boundary.

What actually gets shared across users

In a shared process design, the most important shared objects are the MCP connection state and the OAuth token store. If the process keeps a token after one user authenticates, another user can inherit the same session context unless the implementation actively partitions it. That can affect which servers are reachable, which tools are visible, and what downstream actions the process can perform.

That sharing can also create confusing failure modes. One user may see another user’s authorised resources, or an old token may remain valid long enough to authorise requests under the wrong context. The risk is not just accidental disclosure, it is also incorrect authorisation state being reused in a way the operator did not intend.

• MCP Security Guide explains why token passthrough and OAuth handling need clear boundaries.
• Model Context Protocol: Authorization specification describes audience-bound tokens and the server-side authorization model.
• RFC 8707: Resource Indicators for OAuth 2.0 shows how token audience restriction helps reduce cross-resource reuse.

How to keep multi-user MCP access properly separated

The practical fix is to separate users at the runtime boundary, not just at the profile layer. Per-user profiles help with configuration hygiene, but they do not create a sandbox. A real isolation boundary such as distinct containers, separate OS users, or another equivalent process boundary is what prevents one user’s process state from becoming another user’s access path.

For teams operating shared Hermes workflows, the deciding rule is simple: if the process can hold user-specific tokens, it should also be user-specific in execution context. If that is not possible, you need to redesign the access path so that tokens are not shared in-process and each user’s MCP session is independently scoped and disposable.

• IAM and IGA Basics is useful for separating authentication, authorisation, and entitlement decisions.
• Cloud Workload Identity Guide reinforces why shared static credentials are a poor fit for multi-tenant access paths.
• Access Reviews and Certification Guide helps teams verify that shared access paths are not silently accumulating privilege.

Risk and Threat Considerations

Shared process state turns a local convenience into a cross-user exposure point. If a token, connection, or cached authorization decision is reused in the wrong context, one user may gain unintended visibility into another user’s tools, data, or actions, and an attacker who compromises one session may inherit more reach than expected.

Failure mechanism: A single process retains OAuth tokens and MCP connection state for multiple users, so the process cannot reliably distinguish which session owns which authority. That creates cross-session leakage, confused-deputy behaviour, and excessive effective privilege.

Impact: Users can see or act through credentials they did not obtain, access can persist longer than intended, and incident response becomes harder because the process itself is the shared blast radius.

Practitioner Guidance

What to verify: Confirm whether Hermes stores MCP tokens, refresh material, and server connections in process memory or shared local storage. If yes, treat the deployment as single-user unless you can prove hard isolation between user contexts.

Decision rule: If more than one person will use the same Hermes instance, require separate runtime isolation for each user, not just separate profiles. If the team cannot provide that boundary, move MCP access behind a per-user gateway or separate instance model.

Common mistake: Teams often assume a profile switch is enough because the UI looks separated. The real question is whether authority-bearing state is separated, because that is what determines whether one user can influence another’s MCP access.

Practitioner takeaway: Treat shared-process MCP access as shared privilege until the runtime boundary proves otherwise; profiles are configuration, isolation is what preserves trust.

Related resources from NHI Mgmt Group

• How should teams govern MCP access when multiple tenants share the same user identity?
• Why do AI gateways complicate access governance when multiple models, regions, and tools share one entry point?
• What happens if users lose access to their second-factor device and have no recovery process?
• What happens when Anthos cluster access is mapped to namespace roles but users still need operational work across multiple environments?