AI spaces

An AI space is a DNF host with the ai-space profile, generally a microVM guest. It hosts an assistant OpenClaw 🡕 reserved for its members, with its own secrets and its own data.

In progress

Web access, SSO, Matrix channel, Claude Code, Codex, MCP and skills are in place. Hermes arrives in a future release.

Create a space

1. Declare the host and its members

   The host’s users are its members: DNF creates the Kanidm group space-<hôte> for them.

   etc/config.yaml

   - hostname: "ia-pro"
     zone: "lan:1.40"
     profile: "ai-space"
     features: ["microvm-guest:hyperviseur", "monitoring-node"]
     users: ["alice", "bob"]
     services:
       openclaw: {}

   monitoring-node places the space under the zone’s supervision: without it, neither a space failure nor an assistant shutdown triggers an alert.

   The owner is the member whose subscription runs the assistant: they receive validation requests and unsolicited messages (reminders, scheduled tasks). If the sole member, it is implicit. With multiple members, it is declared in usr/machines/ia-pro/configuration.nix (the order of users is not preserved):

   { darkone.service.openclaw.owner = "alice"; }

2. Initialize the space

   just space-init ia-pro: host key, secrets (see Isolated hosts) and, if the network has Matrix, the bot @ia-pro:<domaine>. Then commit usr/secrets/ and var/generated/spaces/.

3. Deploy

   The hypervisor, the zone gateway (vhost, DNS) and the HCS (Kanidm group): just apply hyperviseur,gw,hcs.

4. Connect the AI provider

   Once per space, from the host (just enter ia-pro), depending on the space’s model (darkone.service.openclaw.model):

   Model	Subscription	Connection
   anthropic/* (default: anthropic/claude-sonnet-5-5)	Claude Pro/Max, via the claude CLI	sudo -u openclaw -H claude auth login
   openai/*	ChatGPT Plus/Pro, via the codex plugin	openclaw models auth login --provider openai

   The host’s openclaw command automatically switches to the service user. openclaw models status checks the connection, which stays in /var/lib/openclaw, persistent.

Why an openclaw user

The assistant reads untrusted content (web, messages, documents): a dedicated system user keeps it apart from members’ accounts, their keys and their connections. Members do not have sudo (reserved for the wheel group): administration goes through the nix account.

Update

A space created before the assistant’s local password must go through just space-init <hôte> again before deployment: it generates the openclaw-gateway-password secret, which the host’s openclaw command uses to reach the service.

Matrix

Members write to the bot @<hôte>:<domaine> in direct message, end-to-end encrypted. The channel only exists if the network declares the matrix service: without it, the space runs on its web interface alone.

Element	Rule
Who is listened to	The space’s members (@<login>:<domaine>), DM only; other accounts are ignored
Rooms	Ignored: non-members would read the replies there
Sessions	One per member when there are several, otherwise a single one for all channels
Command validation	None by default (see Security); any request goes to the owner, via DM
Unsolicited messages	Sent to the owner, via DM
Encryption keys	In /var/lib/openclaw, persistent

Device verification

On first startup, the bot asks for its session to be verified (openclaw matrix verify status on the host). Until it is verified, Element flags its messages as unverified.

Agent tools

MCP servers, skills and tools are declared once per space, in usr/machines/<hôte>/configuration.nix. The assistant and each member (Claude Code, Codex) receive the same ones.

{ pkgs, ... }:
{
  darkone.host.ai-space = {
    mcp.fetch = {
      command = "uvx";
      args = [ "mcp-server-fetch" ];
    };
    mcp.github = {
      command = "github-mcp-server";
      args = [ "stdio" ];
      secretEnv = [ "GITHUB_PERSONAL_ACCESS_TOKEN" ];
    };
    mcp.docs.url = "https://mcp.example.com/mcp";
    skills.rapport = ./skills/rapport;   # dossier avec SKILL.md
    packages = [ pkgs.uv pkgs.pandoc pkgs.github-mcp-server ];
  };

  darkone.service.openclaw = {
    workspace."AGENTS.md" = ./AGENTS.md;
    projects.notes = "https://forge.example.com/alice/notes.git";
  };
}

Option	Role
darkone.host.ai-space.mcp	MCP servers, local (command, args, env, secretEnv) or remote (url, headers)
darkone.host.ai-space.skills	Skills by name: content of SKILL.md, file or directory
darkone.host.ai-space.packages	Tools in the assistant’s PATH and for members
darkone.host.ai-space.enableClaude, enableCodex	Claude Code and Codex, enabled by default
darkone.service.openclaw.exec	Command policy (see Security)
darkone.service.openclaw.identity	Assistant name, emoji and avatar (name, emoji, avatar): the configuration being read-only, the assistant cannot change them itself
darkone.service.openclaw.workspace	Assistant workspace files (AGENTS.md, SOUL.md…)
darkone.service.openclaw.projects	Git repositories cloned once into workspace/projects/<nom>
darkone.service.openclaw.transcription	Local transcription of voice notes (whisper.cpp)

MCP secrets: secretEnv only

env and headers are written to the Nix store, readable by all. An API key goes through secretEnv, for a local server: each variable is read from the space’s secrets file, under the key mcp/<serveur>/<VARIABLE> (just space-sops <hôte>, before deployment). A remote server receives no secret.

Workspace

Declared files are rewritten at each assistant startup. The others (memory, files created by the agent) belong to it. Projects are never updated automatically; a failed clone is reported in journalctl -u openclaw-projects without blocking deployment. An SSH repository uses the openclaw user’s key, created once (sudo -u openclaw -H ssh-keygen -t ed25519) then declared on the forge (/var/lib/openclaw/.ssh/id_ed25519.pub); the server’s key is accepted at first clone.

Voice notes, Matrix or web, are transcribed on the space with whisper.cpp’s small model (466 MB, on CPU), with no external service. The language is detected per note; transcription.language = "fr" sets it.

Member accounts

Each member has a Linux account on the space, trimmed down:

Element	On the space
Home Manager profile	space-member (zsh, git, vim, tmux), instead of their own
Space tools	Claude Code and Codex, with the space’s MCP and skills (darkone.home.aiSpace)
Customizations	usr/users/<login>/space.nix (all their spaces), then usr/users/<login>/spaces/<hôte>.nix (this space), if they exist
usr/users/<login>/default.nix	Ignored: reserved for their workstations
Rights	No group (no sudo), regardless of their profile

Administration of the space goes through the nix account (just enter <hôte>).

Customize a space

These files are ordinary Home Manager modules: packages, aliases, git configuration, other imported modules. A personal MCP is added there via programs.mcp.servers.<nom>.

Each member connects their own subscriptions, once: claude (then /login) and codex login --device-auth.

Access

Element	Rule
Address	https://openclaw.<zone>.<domaine>
Login	Kanidm SSO, reserved to the space-<hôte> group
Device	Paired on first visit, with no administration or validation rights (owner only)
Administration	openclaw … on the host, from the nix account
Assistant port	Reachable from the zone gateway only

One subscription per person

A personal subscription (ChatGPT, Claude) shared by several members is outside the terms of service: a team space takes a team plan or API keys.

Security

By default, the assistant runs its commands without validation, like OpenClaw: the barrier is the space itself (microVM cut off from the LAN, secrets specific to the space). Its service is additionally confined: it only writes to /var/lib/openclaw and sees neither members’ directories nor processes.

darkone.service.openclaw.exec chooses the policy:

Value	Commands
full (default)	All, without validation
ask	Allowlist ones pass, the rest are submitted to the owner
auto	A model examines those outside the allowlist and submits doubtful cases to the owner
allowlist	Allowlist ones only
deny	None

The allowlist is filled on the host: openclaw approvals allowlist add --agent main <chemin>.

Validation and Claude Code

With an anthropic/* model (claude CLI), outside full, pipes, redirections and substitutions are refused without prompting: the assistant becomes markedly less capable. Validation prevents mistakes; it does not stop a compromised assistant, which runs under the same user as the service.

Validation reserved to the owner

Only the owner validates, via DM or in the web interface. A device paired before this setting keeps its right: remove it with openclaw devices list then openclaw devices remove <id>; it re-pairs on the next visit.

What the assistant can read

It runs as the openclaw user: everything the service holds is within its reach, including the owner’s connection to the AI provider and the Matrix bot token. Malicious content (web page, document, message) can make it disclose these: entrust nothing to a space that must not be able to send them out.

Trusted members

A space is a single circle of trust: each member’s web interface shows all sessions, including others’ DMs. People who do not trust each other each get their own space.