Autorisations et approbations

Plusieurs limites indépendantes s'appliquent à chaque appel d'outil, et la plus stricte l'emporte. Aucune d'elles ne dépend du bon comportement de l'IA.

Les niveaux

Votre rôle dans le compte. Les propriétaires et les administrateurs gèrent tout. Les membres peuvent voir les machines et connecter des clients d'IA. Les rôles personnalisés accordent des autorisations individuelles, comme approuver des demandes ou consulter le journal d'audit. Un groupe peut réserver des machines, pour que seuls ses membres les atteignent.
La connexion. Lorsque vous approuvez un client, vous choisissez ses portées, les machines qu'il atteint et sa politique.
Les règles de commande et les approbations de la politique. Elles déterminent quelles commandes s'exécutent, lesquelles sont refusées et lesquelles attendent une personne.
Le plafond propre à la machine. Le fichier ceiling.toml de la machine plafonne ce que n'importe quelle politique peut y autoriser. L'agent l'applique localement : même la passerelle ne peut donc pas aller au-delà.
Le compte du système d'exploitation. Les commandes s'exécutent sous le compte qu'utilise l'agent ou la connexion SSH, avec les droits de ce compte.

Politiques

Une politique appartient au compte et est choisie pour chaque connexion. Elle définit :

Clé	Ce qu'elle contrôle
`shell`	`off`, `sandboxed` (Landlock sous Linux, Seatbelt sous macOS) ou `full`. Windows propose `off` et `full`.
`files`	Les chemins que les outils de fichiers peuvent utiliser, chacun en lecture seule ou en lecture-écriture ; `*` pour tous.
`deny`	Des chemins qui semblent ne pas exister, par exemple des fichiers de clés.
`gui`	Les outils d'écran : `off`, `observe` ou `act`, éventuellement pour les seules applications listées.
`tunnel_targets`	Les adresses que la redirection de ports et les partages web peuvent atteindre.
`commands`	Règles de commande.
`approval`	Approbations : quels outils en exigent toujours une, qui approuve, et combien de temps une demande attend.

Deux politiques sont fournies avec chaque compte : full (shell et fichiers sans restriction, écran désactivé) et read-only (pas de shell, fichiers en lecture seule, fichiers secrets courants masqués, écran désactivé). Les outils d'écran sont désactivés tant qu'une politique ne les active pas ; d'ici là, ils ne sont même pas listés pour l'IA.

Règles de commande

Mode shell (par défaut) : les règles reconnaissent les commandes par motif, la première correspondance l'emporte, et chaque règle indique allow, deny, approve ou confirm. Les commandes imbriquées dans d'autres ($(…), sudo, bash -c, -EncodedCommand de PowerShell) sont aussi vérifiées, et le résultat le plus strict l'emporte. Un shell est assez souple pour que les règles du mode shell soient un garde-fou, et non une limite de sécurité.
Mode liste autorisée : seuls les programmes listés s'exécutent, lancés directement sans shell ; la liste est donc une limite stricte. Les sessions shell et les terminaux ne sont pas disponibles dans ce mode.
Jeux de règles prêts à l'emploi : linux-readonly, windows-readonly, no-destructive, deploy.
Les règles sont vérifiées par la passerelle, puis à nouveau par l'agent sur la machine.

Indépendamment de toute politique, LetKite refuse les commandes qui effacent un système (par exemple rm -rf /, mkfs ou l'écriture sur un disque brut) et exige confirm=true pour les commandes à haut risque, comme un redémarrage, l'arrêt d'un service, la suppression de paquets ou une suppression récursive. L'IA a pour consigne de vous montrer la commande exacte avant de confirmer.

Approbations

Un appel nécessite l'approbation d'une personne lorsqu'une règle de commande indique approve, ou lorsque la politique liste l'outil sous approval.tools. Outils qui peuvent exiger une approbation : exec, exec_many, shell_run, job_start, write_file, delete_path, copy_between_hosts, transfer_start, gui_act, tunnel_open, terminal_open, wake_node, wake_device.

Qui approuve : la personne qui a connecté l'IA (les propriétaires et les administrateurs le peuvent aussi), n'importe quel administrateur, ou une personne autre que celle qui a fait la demande (principe des quatre yeux).
Comment : l'approbateur reçoit un lien par e-mail et, s'il a installé l'application web LetKite, sous forme de notification push sur son téléphone. Approuver nécessite une clé d'accès ou un code d'authentification ; refuser, non.
Exactement ce qui a été demandé : une approbation couvre une seule demande, avec le même outil, la même machine et les mêmes arguments, et ne peut servir qu'une fois.
Expiration : 10 minutes par défaut (de 1 minute à 24 heures, selon la politique). Au plus 20 demandes par connexion peuvent être en attente en même temps.

Pendant qu'un appel attend, le client d'IA reçoit un message indiquant qui a été sollicité et jusqu'à quand, avec la consigne de vous en informer. Il peut attendre avec l'outil approval_wait, puis répéter l'appel avec exactement les mêmes arguments. Une demande refusée ne doit pas être relancée.

Le plafond de la machine

Chaque machine a un fichier local que seul son administrateur peut modifier : /etc/letkite/ceiling.toml sous Linux et macOS, %ProgramData%\letkite\ceiling.toml sous Windows. Il plafonne le shell, les fichiers, les chemins masqués, l'accès à l'écran, la redirection de ports et d'autres éléments sur cette machine. L'agent vérifie chaque demande au regard de ce fichier : le propriétaire de la machine garde ainsi le dernier mot, même si la passerelle était compromise.