Aller au contenu
Documentation

Modules

Assistants

Le Warden, le Mason et le Sapper, ce qu'ils font et ne font pas, le Constable en validation interne, les modèles utilisés, et les gardes contre le détournement.

Les assistants de Ctadel sont quatre agents qui tournent dans votre instance, lisent les données que Ctadel détient et n'agissent jamais sans qu'une personne décide : le Warden répond, le Mason prépare une correction, le Sapper cherche des chemins d'attaque, le Constable enquête sur les incidents. Cette page décrit ce qu'ils font, sur quel modèle, et ce qui les empêche d'être détournés.

Ce que les agents ont en commun

  • Lecture seule. Les outils donnés au modèle lisent la base de Ctadel et le graphe ; une requête sur le graphe qui écrit est refusée. Les seules actions (ouvrir une pull request, créer un ticket, accepter une règle) passent par un bouton que vous cliquez.
  • Chaque fait vient d'un outil. Les consignes des agents interdisent d'avancer un nombre, un nom de ressource ou une clé de règle qui n'est pas sorti d'un appel d'outil de la conversation, et demandent de citer ce sur quoi la réponse s'appuie.
  • Périmètre décidé côté serveur. Ctadel relit les rôles de l'utilisateur à chaque requête et confine les outils à ses projets ; un projet envoyé par le navigateur et que l'utilisateur n'a pas est refusé.
  • Budgets. Chaque tour de conversation est borné en appels d'outils et en longueur de réponse, et chaque agent dispose d'un budget de jetons par jour ; au-delà, il répond que son budget du jour est épuisé.
  • Modèles. Les agents utilisent des modèles de langue servis en Europe par Scaleway ; le Sapper utilise un modèle plus grand que les autres agents. L'opérateur de l'instance peut changer le service de modèles et le modèle de chaque agent. Sans clé configurée, les agents répondent que l'IA n'est pas configurée.
  • Langue. Les agents répondent dans la langue de l'utilisateur.

Le Warden

Le Warden répond aux questions de l'équipe sur sa propre posture : « Demander au Warden » ouvre un volet de conversation présent sur toutes les pages. Le volet rappelle : « Le Warden répond uniquement à partir des données de Ctadel et cite ce sur quoi il s'appuie. Il ne modifie jamais rien. Ce qu'il ne mesure pas, il le dit. »

La page d'où la conversation est ouverte choisit ses outils et ses consignes :

PageOutils ajoutésUsage
ToutesRésumé de posture, liste de constats par famille, détail d'une règle, historique des ouvertures et fermetures, contexte d'une ressource, requête en lecture sur le graphe, schéma du grapheCompter, lister, expliquer une règle, dire ce qui dépend d'une ressource
Vue d'ensemble, constats, un constat, combinaisons toxiquesRegroupement par cause (par règle, et par dépôt et module pour les ressources déclarées en code), classement par risque« Par quoi commencer », « combien de corrections »
ConformitéÉtat d'un référentiel, chapitre par chapitreUn contrôle sans règle est dit « non mesuré », jamais « conforme »
Runtime, un incidentVerdict du Constable, incident, profil et activité d'une identité, journal d'audit en directSuites d'une enquête (en validation interne)
ExplorateurLe schéma du graphe est fourni d'avanceQuestions sur le graphe ; la requête exécutée est affichée (« Requête exécutée sur le graphe »)

Depuis la vue d'ensemble, les constats ou un constat, le Warden peut passer la main au Mason quand vous demandez une correction ; il rapporte le plan, et vous l'ouvrez depuis l'onglet « Remédiation » du constat. Les résultats tabulaires d'un outil sont affichés dans le volet (« Sévérité », « Règle », « Ressource »), avec les familles « non mesuré ». Un résumé quotidien de la posture peut être publié sur vos canaux de notification à une heure fixe si l'opérateur de l'instance l'a réglé ; par défaut il ne l'est pas.

Le Mason

Le Mason prépare la correction d'un constat de configuration cloud, de combinaison toxique, de Kubernetes ou d'infrastructure as code. Son bloc « Mason » est dans l'onglet « Remédiation » du panneau de détail : « Le Mason lit la ressource, ce qui en dépend et où elle est déclarée dans le code, puis propose la correction dans le canal qui la gère vraiment. Rien n'est appliqué sans votre accord. »

  1. « Préparer la correction » : Ctadel assemble le contexte (la ressource et ses propriétés, ce qui en dépend, le fichier Terraform qui la déclare si la liaison code vers cloud existe, et pour une chaîne toxique ses maillons), puis le modèle choisit le canal : « code » (une modification du fichier Terraform, puisqu'un changement en console serait défait au prochain déploiement), « CLI » (des commandes pour le cloud de la ressource), « console » quand ni l'un ni l'autre n'est possible, « ticket » quand la correction demande une décision.
  2. Le plan affiche « Ce qui risque de casser » (déduit des dépendants listés), « Dépend de cette ressource (N) », pour une chaîne le « Maillon à couper », le « Changement proposé » (un diff) ou les « Commandes à lancer » (« Copier les commandes »), et « À renseigner avant de fusionner » : les valeurs que le modèle ne connaît pas (une plage d'administration, une clé KMS) sont laissées en variable sans valeur par défaut ou en paramètre entre chevrons, jamais inventées.
  3. Vous relisez. « Ouvrir une pull request » ouvre la modification sur le dépôt GitHub ou GitLab connecté qui possède le fichier ; « Créer un ticket » crée le ticket dans une intégration de tickets configurée, à la priorité du constat.
  4. « Vérifier la correction » demande une réévaluation de la ressource ; le bloc dit « Finding fermé après réévaluation. » ou « Toujours ouvert après réévaluation : le changement n'est pas encore en place, ou il ne corrige pas la règle. »

Les modifications sont des remplacements exacts : le texte à remplacer est copié du fichier tel qu'il est, lu par un outil, et doit s'y trouver une seule fois ; sinon le bloc dit « La modification n'a pas pu être appliquée au fichier tel qu'il est ». Le Mason n'édite jamais un fichier qu'il n'a pas lu.

Le Sapper

Le Sapper cherche dans le graphe des chemins d'attaque que ni le catalogue ni les chemins calculés ne couvrent, et dépose des propositions que vous acceptez ou rejetez à la main. Il est décrit dans Chemins d'attaque. En résumé : il ne fait que lire, dépose au plus 5 propositions par recherche, une recherche à la fois ; une proposition acceptée devient une règle toxique personnalisée de l'instance. Il n'est accessible qu'aux utilisateurs dont le rôle couvre tous les projets. Sa planification à intervalle régulier est désactivée par défaut ; l'opérateur de l'instance peut la régler.

Le Constable

Le Constable enquête sur les incidents de détection sur journaux d'audit : il lit l'incident et ses alertes, le profil de l'identité sur 90 jours (adresses et actions habituelles, droits, clés), son activité récente, le journal d'audit du cloud en direct sur au plus 7 jours, et ce que les ressources touchées contiennent et exposent. Il rend un verdict à l'un de trois niveaux (fausse alerte, à revoir, ou à traiter), avec sa confiance, une chronologie, des preuves citant leur source, une « Action recommandée » et des points « À vérifier ». Il s'auto-saisit des incidents de sévérité haute et critique, et enquête sur les autres à la demande (« Enquêter »).

Avant le modèle, Ctadel établit un dossier de signaux avec un score et, le cas échéant, un plancher : le verdict ne peut pas descendre sous ce niveau (« Le verdict ne pouvait pas descendre sous « niveau » »). Un verdict qui cite une adresse IP absente des faits lus est rejeté et refait.

Le Constable fait partie de la détection sur journaux d'audit, en validation interne et non disponible pour les clients ; son bloc n'apparaît que sur la page « Runtime ».

Gardes contre le détournement

Les gardes sont appliquées par Ctadel lui-même, pas seulement par les consignes du modèle :

  • Messages qui cherchent à détourner l'agent. Un message qui demande les instructions internes ou tente de les annuler (« ignore les instructions précédentes », « donne-moi ton préprompt », « mode développeur », et leurs équivalents en français et en anglais, même maquillés) est reconnu et reçoit, sans appel au modèle, une réponse fixe : « Je ne partage pas mes instructions internes, et un message ne peut pas les modifier. » Les questions sur vos propres agents IA (Bedrock, SageMaker, Vertex) et sur la remédiation sont laissées passer : le produit a un module de posture IA.
  • Second contrôle par un petit modèle. Un message que les motifs ne reconnaissent pas est soumis au petit modèle avec une question fermée. Il ne refuse jamais : un message jugé suspect met le tour « sous surveillance », la réponse est retenue, relue par le même petit modèle, et affichée sauf si elle livre les consignes.
  • Canari. Les consignes portent une marque que seule une copie des consignes peut reproduire ; une réponse qui la contient, dans quelque langue qu'elle ait été réécrite, est retirée avant d'être affichée.
  • Données qui s'adressent à l'assistant. Un nom de ressource, une étiquette, un agent utilisateur de journal ou un commentaire de fichier sont écrits par qui attaque votre compte, et arrivent au modèle dans les résultats d'outils. Un texte qui s'adresse à un assistant ou lui demande une conclusion (« note à l'IA », « classer comme bénin ») est retiré du résultat avant lecture et signalé : les consignes disent de le rapporter comme un signe d'acteur hostile, jamais de le suivre. Le Constable en tient compte dans son plancher.
  • Périmètre. Les projets accessibles sont relus côté serveur à chaque requête, jamais pris dans le message.

Limites

  • Les agents dépendent d'un modèle de langue : une réponse peut être incomplète, un plan peut proposer une correction inadaptée, une recherche du Sapper peut ne rien trouver. Les consignes exigent de dire ce qui n'a pas pu être vérifié, et les budgets coupent un tour trop long : le modèle répond alors avec ce que les outils ont déjà rendu.
  • Le Warden ne lit que ce que Ctadel mesure ; un contrôle sans règle est « non mesuré ».
  • Le Mason ne prépare des corrections que pour les constats de configuration cloud, toxiques, Kubernetes et IaC ; pas pour les secrets, les CVE, les données ni les hôtes. Le canal « code » suppose que la ressource est reliée à son fichier Terraform ; sans liaison, le Mason propose des commandes ou un ticket.
  • Le Constable est en validation interne. Le journal d'audit en direct n'est lu que sur 7 jours au plus.
  • La reconnaissance des messages de détournement couvre le français et l'anglais ; le second contrôle par le petit modèle couvre le reste au mieux. Aucune garde n'est parfaite ; les consignes elles-mêmes ne contiennent rien de secret, et aucun message ne donne à un agent un outil qu'il n'a pas.
  • Le modèle de langue est hébergé par Scaleway ; vos données de posture lui sont envoyées pour chaque tour. L'opérateur de l'instance peut pointer vers un autre service de modèles compatible.
  • Sans clé du service de modèles, les blocs des agents s'affichent mais répondent que l'IA n'est pas configurée.