Permissions et approbation

Deux questions distinctes, deux blocs distincts. permissions dit qui peut mettre un agent en mouvement. approval dit lesquelles de ses actions s'arrêtent pour attendre une personne une fois qu'il tourne.

Qui peut invoquer

agents:
  - name: support-agent
    role: support
    systemPrompt: You are a courteous support assistant.
    permissions:
      type: agent
      trigger: [admin, member]

Propriété	Description
permissions.type	Discriminant de type d'utilisateur. Toujours agent.
permissions.trigger	Qui peut invoquer : all, authenticated, ou un tableau de rôles comme [admin, member].
permissions.emailDomain	Domaine de l'adresse synthétique de l'agent. Vaut agents.sovrium.local par défaut.

trigger régit les surfaces d'invocation — le panneau de chat, l'API, une automatisation. Il ne régit pas ce que l'agent peut ensuite faire : cela reste son rôle plus sa liste blanche d'outils. Un viewer autorisé à déclencher un agent de rôle admin déclenche quelque chose de plus privilégié que lui : lisez donc trigger comme une délégation, et réglez-le délibérément.

Approbation humaine dans la boucle

approval insère une personne entre la décision du modèle et son effet.

Propriété	Description
approval.mode	none (exécuter aussitôt), all (tout attend), ou selective.
approval.required	Actions nécessitant une approbation — un sous-ensemble de tools.actions. Requis si mode: selective.
approval.timeout	Secondes avant expiration d'une approbation en attente. Vaut 3600 par défaut.
approval.escalation	{ after: <secondes>, to: <rôle> } — confier une demande sans réponse à un autre rôle.

approval:
  mode: selective
  required: [record.delete, email.send]
  timeout: 1800
  escalation:
    after: 600
    to: admin

Lisez cela comme une chronologie. L'agent décide d'envoyer un courriel ; la demande part vers un humain. Dix minutes plus tard, personne n'a agi : elle escalade vers admin. Vingt minutes après cela, le délai expire et la demande s'éteint sans avoir été exécutée.

Choisir un mode

Mode	Approprié quand
none	Toutes les actions possibles sont réversibles et à faible enjeu. Un analyste en lecture seule.
selective	L'essentiel du travail est routinier mais quelques actions sortent de l'immeuble. La réponse usuelle.
all	Un agent tout neuf en qui vous n'avez pas encore confiance, ou dont tout le périmètre engage.

selective est le choix courant en pratique, et la discipline consiste à se demander, pour chaque action : si le modèle se trompe, puis-je annuler ? Un record.update sur une table auditée se rattrape. Un email.send, non — le message est parti. Un auth.banUser non plus, du point de vue de l'utilisateur banni.

Passer un nouvel agent en all pendant une quinzaine de jours est un moyen peu coûteux d'apprendre ce qu'il fait réellement avant de resserrer en selective. La file d'approbation fait alors office de journal d'intentions.

Approbation et planification

Les exécutions planifiées respectent l'approbation. Un agent en mode: all sur un cron nocturne ne s'exécute pas à 3 h du matin — il met une demande en file, qui attend l'arrivée de quelqu'un et expire si timeout passe d'abord.

Cette combinaison est généralement une erreur, et elle mérite d'être nommée : un déclencheur sans surveillance associé à un garde-fou surveillé produit un agent qui, très fidèlement, ne fait rien la nuit. Soit vous resserrez en selective pour que la partie routinière avance, soit vous acceptez que la planification ne fasse que préparer du travail pour le matin. Voir Planification et limites.

Pages associées

• Présentation des agents — l'agent que ces blocs configurent.
• Outils — les actions parmi lesquelles approval.required choisit.
• Planification et limites — les exécutions sans surveillance.
• Rôles et RBAC — les rôles nommés dans trigger et escalation.
• Chat IA — l'une des surfaces que régit trigger.