hermes - 💡(How to fix) Fix RFC: Per-user agent isolation and identity-based permission system

So here is how things starts. Days ago I set up my freshly new Hermes agent and was pretty happy showing my girlfriend about it through the telegram gateway, and then , my dear dear girlfriend played a very classic prompt injection on her side and pretending to be me, and it instantly work, not only so, but also contaminated the memory.md, turning Hermes into a Chinese palace drama talking style.

But beyond the fun, this problem is basically making it impossible for more than 1 user to access Hermes through gateway, and also becomes annoying when i try to show my friends how awsome this thing is.

So in last 3 to 4 days, I burnt more than 500 million Deepseek-v4-pro tokens with Hermes itself to try to set this right.

First, tried simple prompting by identity from gateway, and immedately defeated again by my girlfriend.

Then, tried setting identity with tool permissions, it worked but still two persons using one memory.md will contaminate the memory and make conversation basically broken.

Next, tried to set separated memory.md, identity, and tool permission, and deeply modifyed gateway code to reroute. This worked pretty good, but still feels that something is missing.

Then, this afternoon, when I was looking at the dashboard feature and then I realized hermers have multi agent function already.... then how about we just assgin 1 user-specific agent for each user?

So It would be like

     gateway --by identity--> user identity --assign--> user specifc agent <<with permission constrains>>

The permission problem is also a necessary, not really for security, but at least for making this not so messy, users can still contaminate each other's file system and workplace if there is no permission.

so here comes a bigger picture of such a system.

I have pushed the buggy code generated these days by my Hermers agent in these days, and also the code reconstructed by codex to my own fork of hermes-agent.

I genuinely ask for a review or comment about your ideas on this in-working future PR and want to know if the developer team or anyone have already almost finished this feature before me so we dont clash.

The rest below is the suggestion generated by my Hermes agent. Pretty helping and basically what I wanted to say but I wont make this whole issue totally AI generated s**t so I will just paste it here

👇

Why this Request For Comments

I've been running Hermes Agent on EC2 with multiple users (Telegram / QQ / Feishu / WeChat). Per-user isolation is not a nice-to-have — it's a hard requirement the moment you have more than one person talking to the same agent.

I counted six existing issues/PRs all circling the same problem:

• #11430 — memory contamination in group chats
• #12186 — per-user memory files via SHA256 hash
• #14162 — per-conversation context isolation
• #17989 (P1) — per-user memory/session leakage
• #20744 — Docker sandbox for multi-user gateway
• #7517 — native multi-agent support

Each one patches a different leak point. I think the underlying need is something deeper: an identity layer that all these isolation concerns can plug into, so we stop patching individual leaks and build one thing that fixes all of them.

What we built (running in production)

After hitting the same three problems as #17989, we went further and built an identity-based RBAC system. It's running on our EC2 instance right now.

Pipeline:

Message → Gateway
  │
  ├─ AgentRegistry.get_or_create(platform, user_id)
  │     → identities.yaml → AgentProfile
  │         role: owner | trusted | guest
  │         session_db: agents/<name>/state.db
  │         memory_dir: memories/<name>/
  │         workspace_dir: workspaces/<name>/
  │
  ├─ Identity injected into system prompt (immutable boundary)
  ├─ set_current_profile(profile) → thread-local
  └─ SessionDB(profile.session_db_path)

Permission tiers:

Running code: feat/per-agent-isolation branch at https://github.com/LouisYang841/hermes-agent

Where we're heading (not finished)

We have a draft PolicyEngine (single-entry enforcement at handle_function_call()) that we think is the right long-term architecture. Still incomplete:

• Gateway wiring — identity → profile → policy context chain needs completion
• Abstract Policy Backend — PolicyEngine would benefit from a Protocol layer for swappable RBAC/ABAC

Why I'm writing this now

I see six issues all asking for isolation, and a P1 PR (#17989) that fixes data leakage but stops at data. I think the right question is not "how do we patch this leak" but "what's the identity primitive that makes these leaks impossible?"

If there's appetite for this direction, I'd love to:

• Get feedback on the architecture before we build the full v3 PolicyEngine
• Align with whatever you already have in flight (we saw #7517 — is that related?)
• Contribute whichever pieces are most useful, rather than duplicating effort