Régler la politique des postes depuis la console

Écrire la politique que la passerelle évalue avant chaque action : retirer un outil à l'agent, faire demander un outil à chaque appel et interdire une règle de session depuis l'onglet Policy de la console.

La politique est écrite par l’administrateur dans la console et évaluée par la passerelle avant chaque action. Elle n’est jamais interprétée par le modèle, et elle ne se désactive ni ne s’assouplit depuis un poste (livre blanc sécurité V3, section 5). Elle fixe les outils que l’agent garde, ceux qui demandent un accord à chaque appel, les commandes libres et les règles de session interdites. Cette page décrit comment la régler depuis l’onglet Policy de la console, par des listes et des menus, et ce que la console installe à votre place.

Par défaut, aucune commande n’est libre : chaque modification et chaque commande sont présentées au développeur. L’administrateur peut lister des commandes libres, retirer un outil à l’agent sans redéploiement, et autoriser ou interdire au développeur de ne pas revalider une commande déjà validée (livre blanc sécurité V3, section 5.1). La politique ne règle aucun accès réseau de l’agent : le bac à sable n’a aucune destination joignable (livre blanc sécurité V3, section 4.1).

Pour ouvrir la console et y entrer, voir Ouvrir la console d’administration.

Ouvrir l’onglet Policy

Le résumé de l’onglet Policy dans la barre latérale dit ce qu’il gouverne : « What this organization’s developer workstations may do. » La console porte une autre politique, celle de la passerelle elle-même, qui règle qui peut administrer quoi ; cette page ne la concerne pas.

L’écran s’ouvre dans l’un de trois états :

Ce que la console sait	Ce que l’écran affiche	Ce que vous faites
la passerelle n’a pas annoncé l’organisation servie	un avertissement This console does not know what to govern, sans bouton	redémarrer la passerelle, ou vérifier qu’elle atteint cette base
l’organisation n’existe pas encore en base	« The organization `<nom>` does not exist yet » et un bouton Create `<nom>`	créer l’organisation
l’organisation existe	« No policy is installed yet. » ou « Policy `<révision>`, installed on `<date>` by `<auteur>`. »	régler la politique, puis l’appliquer

Le premier état est un incident, à traiter côté passerelle. Les deux autres sont des états normaux.

Sous la ligne d’état, l’écran tient un brouillon du document en vigueur. Chaque geste décrit ci-dessous modifie ce brouillon ; rien n’est installé avant Apply changes.

Retirer un outil à l’agent

Panneau Tools the agent may use. Sa description résume l’effet : « A removed tool is not even offered to the agent. » Un outil retiré n’apparaît pas dans le catalogue présenté au modèle ; un appel forcé est refusé en nommant la règle de l’organisation.

Ouvrez le menu Tool to remove. Chaque entrée donne le nom de l’outil, ce qu’il fait en une phrase et les surfaces qui le portent : « Bash », « Runs a shell command », « terminal, editor ».
Cochez un ou plusieurs outils. Le bouton dit ce qu’il va faire : Remove tool pour un outil, Remove 3 tools pour trois. Il reste inactif tant que rien n’est coché.
Cliquez le bouton. Les outils cochés passent dans la liste des outils retirés, chacun avec sa description et un bouton Restore, et ne sont plus proposés dans le menu.

La restauration se fait ligne par ligne, par Restore.

La section repliée Tools that ask every time suit le même patron pour les outils qui demandent l’accord d’un humain à chaque appel : menu Tool that must ask, bouton Ask every time ou Ask every time (2 tools). Sa ligne de titre dit son état, « none » ou la liste des outils concernés. Un outil retiré n’est pas proposé dans ce menu, et inversement.

Ce que ces listes n’éditent pas, et que la console nomme quand il existe :

une règle à motif, telle que Bash(rm *) ou Write(src/**), ou une entrée que la console ne sait pas classer, telle que *. Elles restent en vigueur et s’éditent dans le document JSON ; le panneau les cite dans la ligne « Also in force, editable under Advanced » ;
les règles allow, comptées dans la même ligne (« 1 allow rule »). Ce sont les commandes libres que vous listez ; voir Commandes libres et accord « ne plus demander ».

Un nom présent dans la politique et absent du catalogue du produit, l’outil d’un connecteur externe ou une faute de frappe, est listé avec la mention « not in the product’s catalogue », et peut être restauré.

Les trois listes correspondent aux trois verdicts du champ permissions de la politique : exclude, ask et allow. Un poste ne peut pas assouplir ces règles : une commande que la politique ne libère pas reste soumise au développeur, et un outil retiré reste retiré. Le nom d’un outil est le même sur toutes les surfaces ; la liste complète est dans le catalogue partagé du produit.

Interdire une règle de session

Panneau Other rules, section repliée Session rules. Sa ligne de titre dit son état : « nothing forbidden », ou la liste des règles interdites (« remembered approvals, session export forbidden »).

Dépliée, la section présente des règles, chacune avec un champ à deux positions, Not restricted et Forbidden :

Règle à l’écran	Champ de la politique	Ce que Forbidden interdit sur les postes
External connectors (MCP servers)	`allowMcpServers`	démarrer un connecteur externe
Remembered approvals (“don’t ask again”)	`allowRememberedGrants`	ne pas revalider une commande déjà validée : « ne plus demander » du terminal, réglage « Automatic » des éditeurs
Session export	`allowSessionExport`	faire sortir le contenu d’une session : transcription, envoi d’artefact
Other organizations	`allowOtherOrgs`	travailler pour une autre organisation que celle-ci

Forbidden écrit false dans le document. Not restricted retire le champ du document, ce qui est le sens d’un champ absent. Un true explicite en vigueur se lit Not restricted et n’est réécrit que si vous touchez au champ.

Appliquer

Dès que le brouillon diffère du document en vigueur, une barre apparaît au bas de l’écran. Elle nomme la révision qui sera installée et porte deux boutons : Discard, qui ramène le brouillon au document en vigueur, et Apply changes.

La console propose le nom de la révision : v3 en vigueur donne v4 ; rien en vigueur donne v1 ; un nom libre reçoit un compteur, pilote donne pilote-2. La durée de validité reprend celle de la politique en vigueur, ou un jour (86 400 secondes) à défaut. Les deux se changent sous Advanced.

Le document installé est le document en vigueur avec vos modifications, tous les autres champs intacts. La console ne réimprime pas ce qu’elle n’a pas touché.

À l’installation, l’écran affiche In force from the next request : « Revision <nom> applies to every workstation of this organization from its next request. » La ligne d’état se met à jour et le brouillon repart du document relu.

Un refus s’affiche sous Nothing was installed, avec le motif tel que le serveur l’a écrit, et le brouillon est conservé :

Situation	Réponse de la console
le document est refusé par le vocabulaire (champ inconnu, entrée invalide)	`400`, « This policy was refused and nothing was installed: » suivi du motif. Un champ inconnu refuse le document entier
la révision est vide, ou la validité n’est pas un entier de secondes positif	`400`, avec le champ en cause
la console ne sait pas qui agit	`503`, « Cette console ne peut pas établir qui impose cette politique […] » ; l’installation passe alors par `npm run install-organization-policy` sur la passerelle
la passerelle n’a rien annoncé	`503`, « Cette console ne sait pas quelle organisation la passerelle sert […] »
la trace d’audit n’a pas pu être écrite	`503`, rien n’a été installé

Toute modification de politique est journalisée, avec l’ancienne et la nouvelle valeur et son auteur, qui est l’identité vérifiée par votre annuaire (livre blanc sécurité V3, sections 5.1 et 7.2). Un refus est journalisé de la même façon. L’auditeur relit ces actes ; l’onglet Policy ne les montre pas.

Ce qui reste dans le document JSON

La section repliée Advanced montre le document entier et permet de l’éditer : champ Revision, champ Validity, in seconds, zone The policy, as JSON, bouton Install this document. Le document y est prérempli avec celui en vigueur. Un texte qui n’est pas du JSON est refusé avant tout appel (« This document is not readable JSON: … ») ; un refus du serveur laisse le texte en place.

Passent par cette section, et par elle seule : les règles d’outils à motif, les règles allow et les connecteurs approuvés (approvedConnectors).

Un document produit par les listes de cette page ressemble à ceci :

{
  "permissions": {
    "exclude": ["CreateRuleBlock"],
    "ask": ["Bash"]
  },
  "allowRememberedGrants": false
}

Quand la politique prend effet

La passerelle évalue la politique avant chaque action, côté services, de sorte qu’un poste ne peut pas la contourner (livre blanc sécurité V3, section 5.1). Elle relit la base à chaque requête : un outil retiré, une commande libérée ou une règle interdite depuis la console s’applique à l’action suivante, dans une session déjà ouverte, sans redémarrage ni redéploiement.

Sur un poste, lemni policy affiche la politique en vigueur, sa révision, et chaque réglage gouverné avec sa valeur et son origine ; voir lemni policy.