Aide du Hub TheSocle · alfred.whitelists.ecran

Alfred — Whitelists

Les profils d'actions qu'Alfred a le droit d'appeler. Une liste noire globale s'applique en plus, sans exception.

Voir l'élément dans l'écran : alfred/whitelists

Explication

Alfred agit sur le Hub par les actions des workers (docker_worker__restart_app, james_worker__list_messages…). Il ne peut appeler que celles de son profil, appelé ici whitelist.

Chaque run reçoit un profil : celui de sa tâche, de la boîte mail qui l'a déclenché, ou du pair A2A qui l'a demandé. Le modèle d'IA ne voit même pas les autres actions : elles ne lui sont pas proposées.

Trois profils sont installés avec le Hub et ne se suppriment pas :

Profil Contenu
readonly toutes les actions en lecture seule. Profil par défaut.
mail lecture seule, lecture et envoi de courrier, appel des applications, outils web
apps lecture seule, démarrage et redémarrage d'applications, appel des applications

À droite, la liste noire (deny-list) : des actions destructrices qu'aucun profil ne peut accorder, même en les nommant.

Fiche complète

Ce que l'écran appelle

À l'ouverture : GET /hub/alfred/whitelists → alfred_admin.list_whitelists. La liste noire vient du code (AlfredDenyList.describe), pas d'une action.

Où vivent les données

alfred.z_alfred_whitelist : nom unique, description, liste d'actions (JSON), marqueur is_seeded.

Comment un profil devient des outils

Au lancement d'un run (AlfredToolBridge.resolveEffective) :

  1. @readonly est remplacé par toutes les actions déclarées en lecture seule ;
  2. chaque autre nom est gardé s'il existe au registre des actions ;
  3. tout ce qui tombe sous la liste noire est retiré.

S'y ajoutent les outils propres à Alfred quand le profil les nomme : alfred__send_mail, alfred__web_search, alfred__fetch_url, alfred__ask_peer (délégation à un pair A2A).

Sommaire du démonstrateur