hermes - 💡(How to fix) Fix [Feature]: Add tenant workspace template and governance scaffolding for profiles [1 pull requests]

Feature Description

Hermes profiles already provide a strong foundation for running multiple independent agents on the same machine. According to the Profiles documentation, each profile can have its own config, .env, SOUL.md, memories, sessions, skills, cron jobs, gateway state, API keys, and bot tokens.

However, profiles are also explicitly not sandboxes. On the local terminal backend, a profile still runs with the same filesystem permissions as the host user. This means that while Hermes state is profile-scoped, agent-created files, scripts, skill drafts, cron source files, and project work can still be written outside the intended tenant workspace unless operators enforce their own conventions.

This feature request proposes a narrower, operator-facing layer on top of profiles:

Profiles isolate Hermes runtime state.
Tenant workspaces organize tenant-created artifacts.
Full sandboxing remains a deeper separate layer.

The goal is not to replace Docker or OS-level sandboxing, but to provide an official operator pattern and CLI-supported scaffolding between basic profile isolation and full container/VM isolation.

Motivation

A common multi-profile deployment pattern is:

~/.hermes/profiles/<tenant>/
  config.yaml
  .env
  SOUL.md
  memory/
  sessions/
  skills/
  cron/
  gateway state

~/agent-workspaces/<tenant>/
  projects/
  scripts/
  skills/
  cron/
  docs/
  data/
  runtime/
  candidates/
  support/
  incidents/
  TENANT_MANIFEST.md
  CRON_MANIFEST.md

In this model:

• the profile is the agent runtime
• the workspace is where tenant-owned work artifacts live
• shared assets are promoted only after review

This is useful because tenants may create their own cron jobs, private skills, scripts, tools, and project files. Those artifacts should stay inside their own workspace by default.

It also creates a clean path for support and reuse:

• private skills remain private by default
• reusable skills can be nominated as candidates
• support requests can use scoped support packets
• incidents can be summarized without exposing private memory or sessions
• operator/admin agents can help without reading an entire tenant profile

Related Issues / Not a Duplicate

There are already several related issues around profile isolation and multi-tenant Hermes deployments. This proposal is intended to complement them, not duplicate them.

Related issues:

• #30585 — Profile isolation
  Discusses that profiles are not fully isolated and that one profile/agent can write into another workspace or config area. This proposal is closely related, but focuses on an operator-facing tenant workspace convention and template layer first.

• #34352 — Solving the Multi-Tenant Hermes Problem
  Discusses the broader architectural problem of multi-tenancy, especially memory/session isolation and storage-layer enforcement. This proposal is narrower: it does not attempt to solve full multi-tenant memory isolation. It proposes a profile-level tenant workspace mode, governance templates, and candidate/support packet workflows on top of existing profiles.

• #4587 — Multi-profile gateway is not safe
  Discusses profile-blind gateway stop/restart/update behavior when multiple profile gateways run concurrently. Tenant workspace mode would not solve that directly, but it is part of the same operator need: running multiple profile-scoped agents safely on one host.

• #4671 — HERMES_HOME/profile isolation smoke quirks
  Tracks remaining operator-facing inconsistencies around HERMES_HOME and profile-scoped behavior. This proposal would benefit from those cleanup efforts and could add tenant-specific doctor checks.

• #12099 — Session key hardcodes agent:main, breaking multi-profile session isolation
  This is a session isolation bug. Tenant workspace mode is not a replacement for correct session scoping, but the same deployments need both: correct profile/session identity and a clean workspace boundary for tenant-created artifacts.

Scope difference:

Existing issues: deeper isolation and multi-tenant correctness.
This proposal: an operator-facing tenant workspace mode and governance template that can be implemented incrementally on top of profiles.

The first version could be documentation + CLI scaffolding only, without claiming to be a security sandbox.

Proposed Solution

Add a first-class tenant workspace mode for profiles.

Example:

hermes profile create colleague-a --template tenant

This could create:

~/.hermes/profiles/colleague-a/
~/agent-workspaces/colleague-a/
~/agent-workspaces/colleague-a/TENANT_MANIFEST.md
~/agent-workspaces/colleague-a/CRON_MANIFEST.md
~/agent-workspaces/colleague-a/candidates/
~/agent-workspaces/colleague-a/support/
~/agent-workspaces/colleague-a/incidents/

And configure the profile with something like:

profile:
  tenant_mode: true
  tenant_name: colleague-a

workspace:
  root: /home/user/agent-workspaces/colleague-a
  enforce_write_scope: warn   # possible values: off | warn | block
  candidate_dir: /home/user/agent-workspaces/colleague-a/candidates
  support_dir: /home/user/agent-workspaces/colleague-a/support
  incident_dir: /home/user/agent-workspaces/colleague-a/incidents

shared_assets:
  skill_policy: candidate_only
  cron_policy: manifest_required

The tenant template could inject a governance block into SOUL.md, such as:

## Tenant Governance

You are an isolated tenant profile.

Runtime state belongs to this profile.
Work artifacts belong in this tenant workspace.

You may operate within this tenant's sandbox when the tenant user authorizes it.

You must not represent the default/admin agent, other tenants, or shared/core systems.

You must not read or modify other profiles, other tenant workspaces, default profile state, shared credentials, global cron jobs, or shared skill libraries unless explicitly authorized by the operator/admin.

Private skills, cron jobs, workflows, and prompts are private by default.

Reusable artifacts may be nominated as candidates, but candidate output must be sanitized and must not include private memory, session content, API keys, customer data, chat IDs, or secrets.

Shared promotion requires review.

Suggested CLI / UX

1. Tenant profile creation

hermes profile create client-a --template tenant

Creates both:

~/.hermes/profiles/client-a/
~/agent-workspaces/client-a/

2. Tenant doctor

hermes profile doctor --tenant client-a

Checks:

• profile exists
• HERMES_HOME resolves correctly
• terminal.cwd is inside the workspace
• workspace root exists
• tenant manifest exists
• cron manifest exists if cron jobs exist
• no obvious shared/default credentials are reused unexpectedly
• gateway token appears profile-local
• candidate/support/incident folders exist
• profile is not using default workspace accidentally

3. Workspace write-scope warning

When workspace.enforce_write_scope: warn, file-writing tools could warn or require confirmation if a profile attempts to write outside:

~/agent-workspaces/<tenant>/

When block, the write could be blocked unless explicitly approved.

This does not have to be a security boundary at first. Even an operator-facing warning mode would reduce accidental cross-profile contamination.

4. Skill candidate workflow

Possible commands:

hermes skills nominate <skill-name>
hermes skills candidates list
hermes skills candidates inspect <candidate>
hermes skills promote <candidate>

Policy:

private skill
→ sanitized candidate bundle
→ review
→ shared skill

Private skills should not automatically enter a shared library.

5. Support packet workflow

Possible command:

hermes support packet create

Generates a scoped, sanitized packet containing:

• issue summary
• affected profile
• affected skill/cron/script name
• relevant error messages
• expected behavior
• allowed review scope
• explicit exclusions
• no secrets
• no raw memory/session dumps by default

This would let an admin/operator agent help a tenant without reading the whole private profile.

Why This Matters

Hermes is increasingly useful beyond single-user personal agents:

• friends/family agents
• internal team agents
• client-specific agents
• role-based company agents
• customer support bots
• CRM assistants
• content production assistants
• scheduled reporting agents

Profiles are the right primitive, but operators need a repeatable convention for:

• where tenant work should live
• what can be shared
• what must remain private
• how support should happen
• how tenant-created skills become shared assets
• how to avoid default/admin profile contamination

Relationship to Existing Behavior

This proposal does not claim profiles are full security sandboxes.

Instead, it builds on the current official profile model:

• profiles isolate Hermes runtime state
• workspaces organize tenant-created artifacts
• tenant governance templates teach agents the operating rules
• optional write-scope enforcement can start as warnings before becoming stricter

This seems complementary to existing multi-profile and multi-tenant isolation discussions.

Alternatives Considered

1. Full Docker / VM isolation for every tenant

This is stronger, but heavier. It is appropriate for high-risk clients or untrusted tenants, but may be too much for internal colleagues, friends, or low-risk role agents.

2. Manual operator convention only

Operators can already create profiles and workspaces manually, but this is easy to forget and hard to standardize. A first-class template would make the safe path the default path.

3. Shared global skill library only

This makes reuse easy, but creates privacy and contamination risks. A candidate-review workflow is safer.

Possible First Implementation

A minimal first version could be documentation + template only:

hermes profile create <name> --template tenant

Would:

1. create the profile
2. create the workspace
3. set terminal.cwd to the workspace root
4. write TENANT_MANIFEST.md
5. write CRON_MANIFEST.md
6. add a tenant governance block to SOUL.md
7. create candidate/support/incident folders

Later iterations could add:

• write-scope warnings
• tenant doctor checks
• skill nomination workflow
• support packet generator
• stricter workspace enforcement