Laisser l’IA agir en sécurité : un seul journal d’audit, pas cinq

Mal répondre à une question coûte une minute. Mal exécuter une action envoie l’e-mail, déplace l’affaire, crédite la facture. Entre l’IA générative et l’IA agentique, l’écart est celui qui sépare l’inutile du dangereux — et l’essentiel du travail qui permet de le combler sans danger se joue en dessous du modèle.

Cyril est conçu pour que des agents agissent en votre nom. Cela ne tient que si chaque action passe un contrôle d’autorisations, attend la validation d’une personne et laisse une trace de ce qu’elle a fait.

Le problème des actions réparties sur cinq outils

Dans une pile assemblée à la main, un agent qui agit doit agir à travers des intégrations. Il crée le projet dans un outil, envoie l’e-mail par un deuxième, met à jour l’affaire dans un troisième. Chacun a son propre modèle d’autorisations, sa propre piste d’audit — ou aucune — et aucune notion partagée d’« annulation ».

Alors le jour où quelque chose tourne mal — et avec des agents, quelque chose tournera mal — il vous reste à reconstituer les faits à partir de cinq journaux partiels qui ne partagent ni identifiant, ni horloge, ni vocabulaire. Impossible de répondre à la seule question qui compte : qu’a fait l’agent, sous quelle autorité, et comment revenir en arrière ?

Ce n’est pas un problème de sûreté du modèle. C’est un problème d’architecture, et aucune invite de garde-fou ne le corrige.

Un seul modèle d’autorisations

Chez Cyril, un agent est un appelant, pas un super-administrateur. Il agit à l’intérieur du même RBAC que celui qui gouverne les personnes : cantonné à un org_id, borné par le rôle de la personne qui a fait la demande — pas plus. Avant toute exécution, chaque étape de son plan est vérifiée sur le serveur au regard des autorisations de cette personne, et une étape qui les dépasse est refusée.

C’est important, parce que cela rend l’autorité d’un agent lisible. « Que peut faire cet agent ? » appelle une réponse de même forme que « que peut faire cette personne ? » — et cela se règle au même endroit.

Une trace de chaque exécution

Chaque exécution d’agent est enregistrée : le plan, qui l’a validé et ce que chaque étape a fait. « Qu’a fait l’assistant sur le compte Phoenix la semaine dernière ? » se répond en lisant les exécutions, et non par une reconstitution judiciaire à travers plusieurs systèmes.

Quand les actions et leurs traces vivent sur un même graphe, cet enregistrement n’est pas une pièce rapportée. C’est une lecture naturelle des mêmes données.

Corriger une étape erronée

Il n’existe pas encore d’annulation en un clic pour une exécution d’agent. Un élément créé ou modifié par un agent peut être corrigé ou supprimé comme n’importe quel autre, et certaines étapes, comme une relance déjà envoyée, ne peuvent pas du tout être rappelées. C’est pourquoi le plan attend votre validation avant toute exécution.

La validation humaine par défaut

Certaines actions doivent simplement se faire ; d’autres doivent attendre une personne. Dans Cyril, Ask Cyril présente l’ensemble de son plan et attend votre validation avant d’exécuter la moindre étape, et vous pouvez plutôt l’annuler. La validation porte sur le plan dans son ensemble ; vous ne pouvez pas encore la régler action par action.

Ce que cela change pour vous

• Laissez un agent dérouler un flux en plusieurs étapes à travers les modules, et voyez exactement ce qu’il a fait, dans une seule trace d’exécution.
• Donnez-lui une autorité réelle sans lui donner une autorité illimitée — chaque étape est vérifiée au regard des autorisations de la personne qui a fait la demande.
• Validez l’ensemble du plan avant toute exécution, au lieu de découvrir ce qu’il a fait après coup.

La fiabilité d’une IA qui agit ne tient pas d’abord à l’invite. Elle tient à la capacité de la plateforme en dessous à répondre de ce que l’agent a fait. Cyril est bâti pour pouvoir le faire, toujours.