Les espaces IA

Un espace IA est un hôte DNF de profil ai-space, en général un invité microVM. Il porte un assistant OpenClaw 🡕 réservé à ses membres, avec ses propres secrets et ses propres données.

En cours

Accès web, SSO, canal Matrix, Claude Code, Codex, MCP et skills en place. Hermes arrive dans une prochaine version.

Créer un espace

1. Déclarer l’hôte et ses membres

   Les users de l’hôte sont ses membres : DNF crée pour eux le groupe Kanidm space-<hôte>.

   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 place l’espace sous la supervision de la zone : sans lui, ni la panne de l’espace ni l’arrêt de l’assistant ne déclenchent d’alerte.

   Le propriétaire est le membre dont l’abonnement fait tourner l’assistant : il reçoit les demandes de validation et les messages spontanés (rappels, tâches planifiées). Seul membre, il est implicite. Avec plusieurs membres, il se déclare dans usr/machines/ia-pro/configuration.nix (l’ordre des users n’est pas conservé) :

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

2. Initialiser l’espace

   just space-init ia-pro : clé d’hôte, secrets (cf. Hôtes isolés) et, si le réseau a Matrix, le bot @ia-pro:<domaine>. Committer ensuite usr/secrets/ et var/generated/spaces/.

3. Déployer

   L’hyperviseur, la passerelle de la zone (vhost, DNS) et le HCS (groupe Kanidm) : just apply hyperviseur,gw,hcs.

4. Connecter le fournisseur d’IA

   Une fois par espace, depuis l’hôte (just enter ia-pro), selon le modèle de l’espace (darkone.service.openclaw.model) :

   Modèle	Abonnement	Connexion
   anthropic/* (défaut : anthropic/claude-sonnet-5-5)	Claude Pro/Max, par le CLI claude	sudo -u openclaw -H claude auth login
   openai/*	ChatGPT Plus/Pro, par le plugin codex	openclaw models auth login --provider openai

   La commande openclaw de l’hôte passe d’elle-même sous l’utilisateur du service. openclaw models status vérifie la connexion, qui reste dans /var/lib/openclaw, persistant.

Pourquoi un utilisateur openclaw

L’assistant lit des contenus non fiables (web, messages, documents) : un utilisateur système dédié le tient à l’écart des comptes des membres, de leurs clés et de leurs connexions. Les membres n’ont pas sudo (réservé au groupe wheel) : l’administration passe par le compte nix.

Mise à jour

Un espace créé avant le mot de passe local de l’assistant doit repasser par just space-init <hôte> avant son déploiement : il génère le secret openclaw-gateway-password, par lequel la commande openclaw de l’hôte joint le service.

Matrix

Les membres écrivent au bot @<hôte>:<domaine> en message direct, chiffré de bout en bout. Le canal n’existe que si le réseau déclare le service matrix : sans lui, l’espace fonctionne par son interface web seule.

Élément	Règle
Qui est écouté	Les membres de l’espace (@<login>:<domaine>), en MP seulement ; les autres comptes sont ignorés
Salons	Ignorés : des non-membres y liraient les réponses
Sessions	Une par membre quand ils sont plusieurs, sinon une seule pour tous les canaux
Validation des commandes	Aucune par défaut (cf. Sécurité) ; une demande éventuelle va au propriétaire, en MP
Messages spontanés	Envoyés au propriétaire, en MP
Clés de chiffrement	Dans /var/lib/openclaw, persistant

Vérification de l’appareil

Au premier démarrage, le bot demande à vérifier sa session (openclaw matrix verify status sur l’hôte). Tant qu’elle n’est pas vérifiée, Element signale ses messages comme non vérifiés.

Outils des agents

Les MCP, les skills et les outils se déclarent une seule fois par espace, dans usr/machines/<hôte>/configuration.nix. L’assistant et chaque membre (Claude Code, Codex) reçoivent les mêmes.

{ 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	Rôle
darkone.host.ai-space.mcp	Serveurs MCP, locaux (command, args, env, secretEnv) ou distants (url, headers)
darkone.host.ai-space.skills	Skills par nom : contenu de SKILL.md, fichier ou dossier
darkone.host.ai-space.packages	Outils dans le PATH de l’assistant et chez les membres
darkone.host.ai-space.enableClaude, enableCodex	Claude Code et Codex, actifs par défaut
darkone.service.openclaw.exec	Politique des commandes (cf. Sécurité)
darkone.service.openclaw.identity	Nom, emoji et avatar de l’assistant (name, emoji, avatar) : la configuration étant en lecture seule, l’assistant ne peut pas les changer lui-même
darkone.service.openclaw.workspace	Fichiers du workspace de l’assistant (AGENTS.md, SOUL.md…)
darkone.service.openclaw.projects	Dépôts git clonés une fois dans workspace/projects/<nom>
darkone.service.openclaw.transcription	Transcription locale des notes vocales (whisper.cpp)

Secrets des MCP : secretEnv seulement

env et headers sont écrits dans le store Nix, lisible par tous. Une clé d’API passe par secretEnv, pour un serveur local : chaque variable est lue dans le fichier de secrets de l’espace, sous la clé mcp/<serveur>/<VARIABLE> (just space-sops <hôte>, avant le déploiement). Un serveur distant ne reçoit aucun secret.

Workspace

Les fichiers déclarés sont réécrits à chaque démarrage de l’assistant. Les autres (mémoire, fichiers créés par l’agent) lui appartiennent. Les projets ne sont jamais mis à jour automatiquement ; un clonage en échec est signalé dans journalctl -u openclaw-projects sans bloquer le déploiement. Un dépôt SSH utilise la clé de l’utilisateur openclaw, à créer une fois (sudo -u openclaw -H ssh-keygen -t ed25519) puis à déclarer sur la forge (/var/lib/openclaw/.ssh/id_ed25519.pub) ; la clé du serveur est acceptée au premier clonage.

Les notes vocales, Matrix ou web, sont transcrites sur l’espace avec le modèle small de whisper.cpp (466 Mo, sur CPU), sans service externe. La langue est détectée à chaque note ; transcription.language = "fr" la fixe.

Comptes des membres

Chaque membre a un compte Linux sur l’espace, allégé :

Élément	Sur l’espace
Profil Home Manager	space-member (zsh, git, vim, tmux), à la place du sien
Outils de l’espace	Claude Code et Codex, avec les MCP et skills de l’espace (darkone.home.aiSpace)
Personnalisations	usr/users/<login>/space.nix (tous ses espaces), puis usr/users/<login>/spaces/<hôte>.nix (cet espace), s’ils existent
usr/users/<login>/default.nix	Ignoré : réservé à ses postes
Droits	Aucun groupe (pas de sudo), quel que soit son profil

L’administration de l’espace passe par le compte nix (just enter <hôte>).

Personnaliser un espace

Ces fichiers sont des modules Home Manager ordinaires : paquets, alias, configuration git, autres modules importés. Un MCP personnel s’y ajoute par programs.mcp.servers.<nom>.

Chaque membre connecte ses propres abonnements, une fois : claude (puis /login) et codex login --device-auth.

Accès

Élément	Règle
Adresse	https://openclaw.<zone>.<domaine>
Connexion	SSO Kanidm, réservé au groupe space-<hôte>
Appareil	Appairé à la première visite, sans droit d’administration ni de validation (propriétaire seul)
Administration	openclaw … sur l’hôte, depuis le compte nix
Port de l’assistant	Joignable depuis la passerelle de la zone seulement

Un abonnement par personne

Un abonnement personnel (ChatGPT, Claude) partagé par plusieurs membres sort des conditions d’utilisation : un espace d’équipe prend un plan équipe ou des clés d’API.

Sécurité

Par défaut, l’assistant exécute ses commandes sans validation, comme OpenClaw : la barrière est l’espace lui-même (microVM coupée du LAN, secrets propres à l’espace). Son service est en plus confiné : il n’écrit que dans /var/lib/openclaw et ne voit ni les dossiers ni les processus des membres.

darkone.service.openclaw.exec choisit la politique :

Valeur	Commandes
full (défaut)	Toutes, sans validation
ask	Celles de la liste blanche passent, les autres sont soumises au propriétaire
auto	Un modèle examine celles hors liste blanche et soumet au propriétaire les cas douteux
allowlist	Celles de la liste blanche seulement
deny	Aucune

La liste blanche se remplit sur l’hôte : openclaw approvals allowlist add --agent main <chemin>.

Validation et Claude Code

Avec un modèle anthropic/* (CLI claude), hors full, les pipes, redirections et substitutions sont refusés sans demande : l’assistant devient nettement moins capable. La validation évite les erreurs, elle n’arrête pas un assistant détourné, qui tourne sous le même utilisateur que le service.

Validation réservée au propriétaire

Seul le propriétaire valide, en MP ou dans l’interface web. Un appareil appairé avant ce réglage garde son droit : le retirer avec openclaw devices list puis openclaw devices remove <id>, il se réappaire à la visite suivante.

Ce que l’assistant peut lire

Il tourne sous l’utilisateur openclaw : tout ce que le service détient est à sa portée, dont la connexion du propriétaire au fournisseur d’IA et le jeton du bot Matrix. Un contenu piégé (page web, document, message) peut lui faire divulguer ces informations : ne rien confier à un espace qui ne doive pas pouvoir en sortir.

Des membres de confiance

Un espace est un seul cercle de confiance : l’interface web de chaque membre affiche toutes les sessions, MP des autres compris. Des personnes qui ne se font pas confiance prennent chacune leur espace.