Profile Isolation in Agent Harnesses

The invariant

A multiplexed agent harness may run several named profiles inside one long-lived process. Each profile can own different configuration, credentials, state databases, provider accounts, MCP servers, terminal policy, sandbox mounts and output files.

The important invariant is therefore stronger than “the request was routed to profile X”:

Every phase that can observe or mutate profile-owned state must execute under the same durable owner identity, including phases that run after the original turn scope has ended.

This matters because many failures happen after routing was correct. A request can enter under the right profile, then later resolve ${VAR}, test an MCP server, translate a container path, hydrate a resumed session or deliver an attachment after the original context variables have already been restored.

Ownership has to survive the whole lifecycle

Phase	What must stay profile-scoped	Typical failure if ambient/default state wins
Ingress and routing	profile identity, home/config root	request reaches the wrong configuration
Secret expansion	vault/environment mapping, provider credentials	another profile’s token is used or a valid profile token appears missing
MCP/provider control plane	server config, headers, auth workers, connection tests	false-green/false-red health result or credential crossover
Session and persistence	state DB, transcript, session metadata	another profile’s history or state is read or mutated
Tool/runtime execution	terminal policy, sandbox identity, volume map	command or file operation targets the wrong runtime
Deferred/background work	owner identity across callbacks, queues and jobs	later work falls back to process-global state
Media/artifact delivery	sandbox roots, output mounts, path validation	valid output is dropped or a same-named file from another profile is delivered
Caches and memoization	cache key must include the ownership dimensions it depends on	one profile’s resolved client, credential or capability leaks into another

The safest implementation pattern is to derive the owner from durable request/session identity, then explicitly re-enter that profile’s runtime scope whenever later work needs profile-owned state. Process-global environment variables are not an ownership model.

Fresh Hermes evidence: control-plane secret scope

Hermes issue #109901, closed 13 September 2026, reproduced a secondary-profile Desktop MCP health probe that failed when the profile’s Authorization token came from Bitwarden Secrets Manager. A fresh profile-scoped CLI process connected successfully, but the shared Desktop backend entered only the profile home scope before resolving the MCP configuration. Secret expansion then correctly failed closed rather than falling back to another profile’s process environment.

Commit 0388d03f225719fc0df3a239c39bbc103fbf1888 generalizes the correction beyond that one route. The profile-scoped RPC path used by control-plane methods including mcp.servers.*, mcp.catalog, skills.manage, plugins.manage, cron.manage and insights.get now enters the requested profile’s complete runtime scope rather than rebinding only HERMES_HOME. The implementation hydrates that profile’s external secret sources and applies its secret and terminal scope without mutating process os.environ.

The regression is intentionally adversarial: the secondary profile’s .env contains one token while the process environment contains a different default-profile token. The MCP Authorization header must resolve to the secondary profile value. That test shape matters because “connection succeeds” is insufficient evidence when the wrong credential could also be valid.

Fresh Hermes evidence: post-turn media delivery scope

Hermes issue #109024, closed 14 September 2026, documents the complementary delivery-side failure. A multiplexed named profile produced a Docker file successfully, but later MEDIA: processing occurred after the routed turn scope had ended. Path translation then consulted ambient/default profile sandbox and volume state. The result could be a dropped valid file; more seriously, a same-named default-profile file could be selected instead.

Commit 28138f2524335edda86b55da6d71eec60c7e65b0 makes media extraction and validation re-enter the source profile’s home and terminal-policy scope before resolving Docker paths and explicit output mounts. Its regression creates the same filename in default and secondary profile mounts and verifies that the secondary profile’s bytes are the ones delivered.

This is the same ownership problem as the MCP probe, just at a different lifecycle phase: correct ingress routing does not prove correct post-ingress ownership.

This extends the stable v0.21.2 isolation campaign

Hermes stable v2026.9.11 / v0.21.2 already shipped a broad multi-profile isolation campaign. Its release notes call out fixes preventing secondary profiles from inheriting default allow-lists, adapters from sending credentials to the default profile host, stdio MCP servers from receiving default-profile vault secrets, MEDIA: delivery from attaching another profile’s sensitive state, routed callbacks from escaping their profile, and per-process credential memos from supplying a sibling profile’s bearer.

The two post-release fixes above expose the durable architectural lesson behind that campaign: isolation has to cover control-plane RPCs and delivery continuations, not only the main agent turn.

Engineering rules that generalize

1. Use an explicit owner identity. A profile name, tenant id or principal id must travel with the work item; do not reconstruct ownership from whichever global context happens to be active later.
2. Re-enter scope at deferred boundaries. Queues, callbacks, RPC handlers, background jobs, delivery workers and resume paths are common places where request-local context has already been reset.
3. Fail closed for secrets. If multiplexing is enabled and no profile secret scope is active, refusing resolution is safer than falling back to process environment state.
4. Keep ambient state read-only where possible. Avoid mutating os.environ to emulate profile switching inside a shared process; scoped resolvers are easier to reason about and test.
5. Key caches by every ownership dimension they depend on. Provider/model alone is insufficient when credentials, endpoints, tool policy or sandbox identity vary by profile.
6. Validate the delivery path, not only execution. A tool can create the correct file and still leak or lose it during later path translation, artifact collection or message delivery.
7. Test with deliberately conflicting valid state. Give default and secondary profiles different valid tokens and same-named files. A test that only checks for success can miss cross-profile substitution.
8. Exercise scope exit explicitly. Regression tests should run the deferred phase after the original profile context has ended; otherwise they may accidentally prove only the easy in-scope path.

A useful negative-test matrix

A multi-profile harness should be able to demonstrate at least these cases:

• secondary profile secret exists, default process secret is different → secondary value wins;
• secondary secret is absent, default process secret exists → operation fails closed rather than borrowing it;
• both profiles contain the same relative filename with different bytes → owner profile bytes are delivered;
• only default profile contains the requested file → secondary delivery rejects it;
• background/deferred handler runs after ingress context exits → owner identity is still recoverable from durable task/session metadata;
• cache warmed by profile A → profile B resolves its own client/credential/policy rather than reusing A’s profile-sensitive object;
• restart/resume under a shared gateway → persisted owner mapping remains authoritative;
• invalid or deleted profile → work fails explicitly rather than falling back to the default profile.

Relation to UHP, MCP, A2A and ACP

This page describes a harness-runtime isolation pattern, not a new interoperability protocol.

• UHP: Hermes profiles are not UHP objects. UHP standardizes a client↔server↔selected-harness execution contract; an implementation that multiplexes several internal profiles still has to enforce its own ownership and data-isolation rules.
• MCP: MCP can be one of the resources whose configuration and credentials are profile-owned. MCP wire semantics do not determine which local profile’s vault, environment or process state a host implementation should consult.
• A2A / ACP: those protocols may carry work to or from an agent runtime, but they do not make Hermes-style profile homes, Docker mounts or local credential scopes interchangeable.

Nothing in the Hermes fixes establishes native Hermes UHP adoption, changes MCP/A2A/ACP wire semantics, or constitutes new HarnessRouter conformance evidence. HarnessRouter’s Hermes backend remains a separate adapter/reference-implementation boundary.

Primary sources

• Hermes current repository
• Hermes v2026.9.11 / v0.21.2 release
• Issue #109901 — Desktop MCP health probe lacks secondary-profile secret scope
• Commit 0388d03f — profile-scoped RPC binds home, secrets and terminal policy
• Issue #109024 — named-profile Docker MEDIA resolves against ambient default profile
• Commit 28138f25 — bind post-turn media delivery to the source profile
• Checked Hermes source cutoff 98a33248
• UHP / HarnessRouter source

---

This is an independent technical guide. The isolation rules above are engineering conclusions from the cited implementation evidence, not vendor certification or a new UHP requirement.