La Boétie
Send a brief

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.

Send a brief

141 tests passed in the recorded run

Status
Private
Access
In house

Local User capabilities

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.

On this page

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

BackendSeparationTrade
Default localContext only, shared userSimplest, no boundary between projects
Local UserOne Linux account per profileLight, with shared network and host
Docker or another container backendA container per environmentMore setup, stronger separation
SSH to another machineA remote hostMore hosts to run
Separate gatewaysOne full gateway per projectMore 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

LayerAdds
Passwords on local servicesProtects databases from other accounts
Per account firewall rulesLimits network reach
Separate credentials per projectLimits damage from a leak
Audit logsRecords who ran what
Tighter home permissionsCloses old world readable files

Profiles, accounts and containers

Three ideas are often confused.

IdeaWhat it separatesWhat it leaves shared
ProfileMemory, skills and settingsThe operating system user, unless you change the backend
Linux accountFiles and processes, through permissionsThe host, the network and world readable files
ContainerA view of files, processes and networkThe kernel

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

SituationReasonable choice
One person, one projectThe default profile
One operator, several projectsSeparate Linux accounts
Several teams on one serverContainers, with separate credentials
Code from strangersA 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 if you run several agent projects on one server and need separation you can test. Agent Runtime offers a stronger jail for coding agents, and 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.