---
title: "Hermes Agent profile isolation with Linux accounts"
description: "Hermes Agent profile isolation through Linux accounts: Local User maps each profile to its own UID. 141 tests passed in the recorded run. Kept in house."
canonical: "https://laboetie.io/products/local-user"
language: en
---
# Local User: Hermes Agent profile isolation

Local User is a Hermes Agent plugin that runs each profile under its own Linux account, so one gateway serves several projects with separated permissions. On the default local backend, every Hermes profile keeps the filesystem access of one user. A root owned policy sets the account, and 141 tests passed in the recorded run.

Status: Private. Access: In house. 141 tests passed in the recorded run.

## Capabilities

- The terminal backend sits on the official Hermes provider interface.
- A root owned policy sets the identity and fails closed on any anomaly.
- The child process drops privileges and clears capabilities.
- Unknown tools and root execution paths are explicitly denied.
- Browser execution stays under the same account.

## Separation built into Hermes profiles

A Hermes profile separates config, memory, sessions, skills and state into its own home. The profile leaves tool access to the filesystem unchanged: on the default local terminal backend, the agent keeps the access of your user account and reaches folders outside the profile directory. Local User adds an operating system boundary to close that gap.

## One Linux account per Hermes profile

An administrator maps each profile to a dedicated non root account in a root owned policy file. Configuration, environment variables and model output cannot select the account. A changed policy, a missing account or a repeated UID stops the backend.

## How La Boétie uses Local User

La Boétie has provisioned the backend on nine project profiles of one Hermes gateway. The admin profile stays outside the policy. The current revision is staged pending activation. The repository is private, and a team with a multi project gateway to separate can send a brief.


## The problem with one gateway and several projects

**Hermes Agent** runs a gateway that can serve several profiles, each with its own memory, skills and settings. Profiles keep context apart. On the default local backend, every profile's terminal commands run as the same operating system user.

That matters as soon as a gateway serves more than one project. An agent for project A can read the files of project B, because the file system sees a single user. A mistake or an injected instruction in one project reaches all of them.

Local User maps each profile to its own Linux account. The kernel then enforces what a profile can touch, using the ordinary file permissions of the machine.

## What each backend gives you

| Backend | Separation | Trade |
|---|---|---|
| Default local | Context only, shared user | Simplest, no boundary between projects |
| Local User | One Linux account per profile | Light, with shared network and host |
| Docker or another container backend | A container per environment | More setup, stronger separation |
| SSH to another machine | A remote host | More hosts to run |
| Separate gateways | One full gateway per project | More processes and more channels to manage |

Local User suits one trusted operator who runs several projects on one server and already has an account for each.

## What Local User does

Each profile on the gateway runs its commands, files and browser work under its own Linux account. An administrator sets the mapping, and neither the model nor a message in the conversation can change it. When something looks wrong, the plugin refuses to run the work.

## Layers worth adding

| Layer | Adds |
|---|---|
| Passwords on local services | Protects databases from other accounts |
| Per account firewall rules | Limits network reach |
| Separate credentials per project | Limits damage from a leak |
| Audit logs | Records who ran what |
| Tighter home permissions | Closes old world readable files |

## Profiles, accounts and containers

Three ideas are often confused.

| Idea | What it separates | What it leaves shared |
|---|---|---|
| Profile | Memory, skills and settings | The operating system user, unless you change the backend |
| Linux account | Files and processes, through permissions | The host, the network and world readable files |
| Container | A view of files, processes and network | The kernel |

Choosing among them depends on how far you trust the work.

| Situation | Reasonable choice |
|---|---|
| One person, one project | The default profile |
| One operator, several projects | Separate Linux accounts |
| Several teams on one server | Containers, with separate credentials |
| Code from strangers | A virtual machine |

## Keeping projects apart in practice

Separation depends on the habits around it.

1. Give each project its own account, and never share one.
2. Keep each project's secrets in files only its account can read.
3. Give each project its own database user.
4. Review old group memberships on the server.
5. Check for world readable files holding credentials.
6. Protect local services with a password.
7. Log who ran what.

## Questions before you share a gateway

- Who administers the server, and can every project trust that person?
- Which data in each project is sensitive?
- What happens if one agent is misled by a web page?
- Can one project's traffic slow the others?
- How will you remove a project cleanly?

## Next step

[Send a brief](https://laboetie.io/brief) if you run several agent projects on one server and need separation you can test. [Agent Runtime](https://laboetie.io/products/agent-runtime) offers a stronger jail for coding agents, and [WhatsApp Extensions](https://laboetie.io/products/whatsapp-extensions) adds reply routing to the same gateway.


## Frequently asked questions

### Do Hermes Agent profiles isolate agents from each other?

Hermes profiles isolate data and leave filesystem access as it was. Each profile has its own config, memory, sessions and skills. On the default local backend, the agent has the access of your user account and can reach folders outside the profile directory. Local User separates profiles at the operating system level with one dedicated Linux account per profile.

### How do I run Hermes Agent profiles as separate Linux users?

Local User does this through the official Hermes terminal provider interface. An administrator lists each profile and its account in a root owned policy at a fixed path, and every project needs a distinct UID. The plugin then runs terminal work, file operations and Python execution as that account. It works without a second gateway or SSH. This describes how the studio runs the plugin in house.

### Is Local User a container?

No. Local User relies on normal Linux UID and GID permissions, and it is neither a container nor a network boundary. Processes under one account can inspect each other, which is why every project needs a distinct UID. World readable host data and host services stay reachable. Tools that do not dispatch through this backend sit outside its boundary.

### Can the model choose its Linux account?

No. Identity comes from the active Hermes profile and a fixed administrator policy. No config value, model argument, environment variable or task ID changes the policy path or selects the account. The policy rejects symlinks, unsupported fields, missing accounts, UID zero and repeated UIDs. Root does not parse model shell commands. The child process checks access to its working directory after the privilege drop.

### Is Local User open source?

Not today. The repository is private and has no LICENSE file, so the plugin has no public install path. La Boétie keeps version 1.0.0 in house for its own Hermes gateway, and the plugin depends on Hermes Agent by Nous Research to run. Teams that need to separate profiles on a shared gateway can reach the studio with a brief.