Agents et registre

Le module Agents est le point d'ancrage du cycle de vie de chaque agent d'IA que vous gouvernez avec le KLA Control Plane, la couche de sécurité, d'audit et de gouvernance à l'exécution dont vous instrumentez vos agents existants au lieu de les replateformer. Il associe un Agent Registry (l'inventaire de chaque agent, de son propriétaire et de ses versions) à un pipeline de livraison gouverné : vous rédigez une modification, la validez, publiez une Release immuable, la déployez, puis revenez en arrière si nécessaire. Le module Agents couvre tout le parcours, de « cet agent existe » à « c'est exactement cette version qui tourne en production ».

Qui l'utilise

• Les développeurs et intégrateurs enregistrent les agents, définissent leurs manifestes, exécutent des Simulations et livrent des Releases via le même flux que celui qu'ils utilisent pour le code.
• Les opérateurs de plateforme gèrent les Rollouts entre environnements, encadrent les promotions et déclenchent un Rollback dès qu'un comportement régresse.
• Les responsables conformité et risques s'appuient sur l'Agent Registry comme réponse de référence aux questions « quels agents existent, qui en est propriétaire, que peuvent-ils faire et qu'est-ce qui a changé ». Chaque Release est versionnée et attribuable.

Capacités clés

• Agent Registry. Recherchez et filtrez chaque agent enregistré par modèle, équipe propriétaire, état de release ou hash de manifeste. Chaque entrée porte la propriété, la Release active et l'historique complet des versions.
• Releases. Une Release est un instantané immuable et versionné de la configuration d'un agent : modèle, instructions système, paramètres et liaisons d'outils. Une Release ne change jamais après publication ; toute nouvelle modification produit toujours une nouvelle Release avec un nouveau hash. C'est ce qui fait de « ce qui tournait à telle date » une question précise et démontrable.
• Rollouts et Rollback. Un Rollout promeut une Release vers un environnement cible. Un Rollback ramène instantanément l'environnement à une Release publiée précédemment. Les deux sont des actions de première classe, auditées, sans aucune modification à chaud de la configuration en cours d'exécution.
• Simulations. Avant la publication, exécutez une Simulation dans un bac à sable : rejouez des prompts représentatifs sur la Release candidate et examinez les sorties, les appels d'outils, le coût et les décisions de politique que chaque action déclencherait, le tout sans aucun effet sur la production.
• Application des liaisons d'outils. Chaque agent déclare les outils qu'il est autorisé à appeler. À l'exécution, KLA applique ces liaisons en s'appuyant sur le Tool Catalog (l'inventaire gouverné des outils approuvés et de leurs permissions). Si un agent tente d'utiliser un outil qui n'est pas lié dans sa Release active, l'action est bloquée : une exécution selon le principe du moindre privilège par défaut.

Manifeste d'agent

Les agents sont définis de façon déclarative sous forme de manifestes JSON. Un nouveau manifeste produit une nouvelle Release avec un nouveau hash à la publication.

{
  "id": "agt_9f81a7",
  "name": "support-classifier",
  "model": "gpt-4o",
  "temperature": 0.0,
  "tools": ["escalate_ticket", "read_knowledge_base"],
  "env": "production"
}

Le tableau tools constitue l'ensemble des liaisons. À l'exécution, KLA vérifie chaque appel d'outil par rapport au Tool Catalog et à cet ensemble déclaré ; tout appel à un outil non déclaré est rejeté avant son exécution.

Cycle de vie d'une Release

flowchart LR
  A["Rédiger la modification"] --> B{"Valider"}
  B -->|échec| A
  B -->|succès| C["Publier la Release"]
  C --> D["Déployer vers l'environnement"]
  D --> E{"En bonne santé ?"}
  E -->|oui| F["Release active"]
  E -->|non| G["Rollback"]
  G --> F

Comment cela s'articule

Le module Agents se situe au centre des quatre piliers, Govern, Operate, Assure, Prove :

• Policy Builder rédige les politiques évaluées par rapport à chaque action d'agent. Exécutez ces politiques sur une Release candidate dans une Simulation avant de publier.
• Decision Desk reçoit une Escalation chaque fois qu'une action gouvernée renvoie une décision require_approval, ce qui suspend l'exécution jusqu'à ce qu'un relecteur tranche.
• Lineage Explorer enregistre chaque action sous forme de Lineage Record, chacun estampillé du hash exact de la Release qui l'a produit, de sorte qu'une trace renvoie toujours à une configuration connue et immuable.
• Evidence Room scelle cette traçabilité dans un Sealed Evidence Bundle, offrant aux auditeurs une preuve cryptographique de la Release qui a tourné, de ce qu'elle était autorisée à faire et de ce qu'elle a réellement fait.