La délégation IA consiste, pour une personne, à laisser un logiciel agir en son nom, dans certaines limites, et parfois à laisser ce logiciel confier une partie du travail à un autre logiciel. Cette page définit le vocabulaire utilisé sur ce site et le relie aux noms publics employés par le moteur Authority.

Un exemple simple

  1. Humain → agent. Une personne autorise un agent d’achat à créer des bons de commande jusqu’à 1 000 EUR jusqu’à la fin de l’année. Les commandes supérieures à 100 EUR exigent son approbation explicite.
  2. Agent → sous-agent. L’agent d’achat confie une part plus étroite à un sous-agent : des commandes jusqu’à 300 EUR, jusqu’à la fin novembre.
  3. Sous-agent → action. Le sous-agent demande à un système fournisseur de créer une commande de 250 EUR.
  4. La question. Avant d’agir, le système fournisseur doit savoir si une chaîne d’autorité ininterrompue, remontant à cette personne, couvre cette action précise à cet instant, et si l’approbation requise existe.

Chaque notion ci-dessous désigne une partie de cette question.

Les acteurs

Principal humain

La personne dont l’autorité est exercée en dernier ressort. Dans Authority, une chaîne ne peut aboutir à AUTHORIZED que si elle remonte à une délégation racine dont le délégant est marqué HUMAN_ROOT. Une chaîne dont la racine est un agent n’a pas d’origine humaine établie et donne UNKNOWN.

Agent

Un logiciel qui agit pour un principal en vertu d’une délégation. Un agent reçoit une autorité ; il ne la possède pas.

Sous-agent

Un agent qui a reçu son autorité d’un autre agent par une sous-délégation (SUBDELEGATION_CREATED). L’agent délégant doit lui-même avoir été autorisé à déléguer (can_delegate).

Partie utilisatrice (relying party)

Le système qui doit décider s’il peut exécuter l’action demandée : une API de paiement, un système fournisseur, un service interne. C’est la partie qui pose la question. Authority est un outil capable d’y répondre ; la partie utilisatrice reste responsable de ce qu’elle fait de la réponse.

Quatre questions souvent confondues

Identité

Qui ou quoi est un acteur. Authority V0 traite les principaux comme des identifiants opaques ; il n’établit pas qui se trouve derrière eux.

Authentification

La preuve qu’une requête provient bien d’une identité donnée. Elle est hors du périmètre de la V0 : l’hôte fournit les identités authentifiées, et chaque événement est marqué ASSERTED_UNVERIFIED.

Autorisation

Le fait qu’un acteur puisse ou non réaliser cette action, avec ces paramètres, à ce moment. Authority répond par l’un de quatre résultats : AUTHORIZED, DENIED, REQUIRES_APPROVAL ou UNKNOWN.

Délégation

La manière dont une autorisation passe d’un principal à un autre, assortie de limites. La délégation explique d’où vient une autorisation ; c’est la chaîne que le moteur reconstruit.

Les limites portées par une délégation

Périmètre

Ce que couvre une délégation. En V0, une capacité est une paire exacte (resource, action) : aucun joker et aucun héritage implicite (invariant I9). Les limites monétaires comme max_amount font partie du périmètre.

Atténuation

Une sous-délégation ne peut que restreindre son parent. Sur chaque dimension (capacités, can_delegate, expires_at, limites de montant, total_budget), l’enfant doit être égal ou plus strict. Élargir une seule dimension rend la sous-délégation invalide ; elle n’est jamais tronquée silencieusement (I5).

Approbations

Au-delà d’un seuil automatique et jusqu’à un plafond d’approbation, une action exige une approbation humaine explicite (APPROVAL_GRANTED). Sans elle, le résultat est REQUIRES_APPROVAL. Une approbation est consommée par une seule exécution (I16).

Liaison à l’instance d’action

Une approbation couvre exactement l’action qui l’a demandée, identifiée par son action_id et par son empreinte exacte (I6). Une seconde action avec la même capacité et les mêmes paramètres est une autre instance et n’obtient rien de cette approbation. Le premier article examine cette règle en détail.

Budgets

total_budget plafonne le montant cumulé dépensé par les exécutions sous une délégation et ses descendantes. En V0, des décisions concurrentes peuvent dépasser un budget partagé ; le dépassement est signalé après coup, pas empêché (voir les limites).

Expiration

expires_at est comparé à une horloge de confiance attribuée à l’ingestion (authority_time), jamais à un horodatage déclaré par la source. L’instant limite compte comme expiré (I4).

Révocation

Un DELEGATION_REVOKED autorisé invalide, à partir de sa position dans le journal, toute descendante qui dépend uniquement de la délégation révoquée. Une révocation émise par quelqu’un qui n’a pas le droit de révoquer n’a aucun effet (I7, I13).

Trois vues de l’autorité

Ce site utilise trois mots, AVAILABLE, INVOKED et RECORDED, pour indiquer à quelle question appartient une réponse. Il s’agit d’un vocabulaire éditorial, également employé dans les commentaires du code du dépôt, et non d’un standard externe. Chacun correspond à des noms publics du moteur.

Autorité disponible fondée sur l’empreinte : AVAILABLE

Une chaîne valide détenue par l’agent autoriserait-elle cette capacité avec ces paramètres (l’empreinte de l’action) à ce moment ? Toute approbation correspondante et non consommée peut compter, y compris une approbation liée à un autre action_id. Noms publics : authorityAt, ainsi que currentAuthority et execution.authorityAtDecision dans explainAction.

Autorité invoquée : INVOKED

Ancrée sur la délégation nommée par l’action elle-même (ACTION_REQUESTED.delegation_id) : cette délégation, seule, autoriserait-elle cette instance d’action précise ? Noms publics : invokedAuthorityNow et execution.invokedAuthorityAtDecision.

Validation de la chaîne enregistrée : RECORDED

La chaîne enregistrée par l’exécution (ACTION_EXECUTED.authority_chain_ref) valide-t-elle cette action à son point de décision ? Nom public : execution.recordedValidation.

Preuves et historique

Authenticité des preuves et validité de l’autorité

Deux questions distinctes. Validité : pris tels quels, les événements journalisés forment-ils une chaîne qui couvre l’action ? Authenticité : ces événements ont-ils réellement été émis par les principaux qu’ils nomment ? Authority V0 ne répond qu’à la première. Il n’a pas de signatures ; un résultat AUTHORIZED signifie que le journal contient des événements non contredits affirmant une chaîne d’octrois, et non qu’un octroi a été prouvé cryptographiquement.

Évaluation historique

Chaque évaluation est faite à une position explicite du journal (atSequence) et à un instant de confiance explicite (authorityTime). Une action exécutée est également réévaluée à son propre point de décision. Comme le journal est en ajout uniquement (I3), une action autorisée au moment où elle s’est exécutée reste autorisée à ce point, même si son autorité est ensuite révoquée ou expire.

Ce qu’Authority résout

  • La reconstruction déterministe d’une chaîne de délégation à partir d’un historique d’événements en ajout uniquement, de la racine humaine jusqu’à l’action.
  • Quatre résultats distincts, avec UNKNOWN comme valeur par défaut fail-closed lorsque les preuves manquent ou sont ambiguës (I1).
  • Des explications qui séparent les vues disponible, invoquée et enregistrée d’une action.

Ce qu’Authority ne résout pas

  • L’identité, l’authentification ou les signatures : chaque événement est ASSERTED_UNVERIFIED.
  • L’intention ou le contenu d’une action : le moteur vérifie la chaîne d’autorité formelle, pas l’opportunité de l’action.
  • La prévention des dépassements de budget concurrents, la protection contre un utilisateur privilégié de la base de données, ou toute affirmation de performance à l’échelle de production.

La liste complète figure sur la page des limites.

Pour aller plus loin