Toutes les capacités du runtime gouverné, et ce que nous améliorons. Ce journal reflète la version publique actuelle — regroupé par domaine, chaque entrée renvoie à une capacité disponible aujourd'hui, sans historique de versions inventé.
Regroupé par domaine · Livré vs Amélioré · liens vers la plateforme
Runtime de gouvernance
Les portes que franchit chaque exécution.
Créez un agent et chaque exécution suit la même chaîne de gouvernance fail-closed : identité, budget, garde-fous, registre, control tower, exécution, filtre de sortie, audit. Le refus est la règle par défaut.
Policy-as-CodeLivré
Des règles de politique testables : simulation et tests de référence
Rédigez des règles évaluées par ordre de priorité, l'effet le plus restrictif l'emportant (deny > require_approval > allow), prévisualisez une décision et sa trace règle par règle avant la mise en production, et soumettez chaque changement à une suite de tests de référence.
Les actions comme objets gouvernés de premier ordre
Chaque action suit le parcours dry-run → propose → approve/deny → execute → compensate, avec un registre d'invocations immuable et un dossier de preuves. Les actions à haut risque atterrissent dans une boîte d'approbation humaine ; les clés de rollback déclarées rendent la compensation possible.
Des niveaux d'autonomie explicites, avec un plancher de risque
Réglez l'autonomie de chaque agent, de suggest_only à autonomous. La supervision ne peut que durcir une décision, jamais abaisser le plancher d'approbation propre à l'action — et le break-glass administrateur force l'exécution avec un motif obligatoire et audité.
Chaque agent porte sa propre identité, ses outils autorisés, ses modèles autorisés, ses données autorisées et son canal de déploiement. Le runtime refuse d'exécuter un agent absent, en brouillon, non publié, issu d'un autre tenant, expiré, en pause ou non autorisé.
Serveurs et outils Model Context Protocol gouvernés
Les serveurs MCP s'enregistrent en pending et ne peuvent pas être invoqués avant approbation ; les bloquer agit comme un coupe-circuit immédiat. Les invocations gouvernées analysent l'entrée par DLP, appliquent une liste d'outils autorisés par serveur et consignent chaque appel avec des E/S expurgées.
Une vue agrégée, par tenant, des agents, des exécutions, des dépenses, des outils et des contrôles actifs — avec mise en pause et désactivation d'outil en un clic, réellement appliquées par le runtime (un agent en pause est rejeté avec 409 AGENT_PAUSED).
Chaque résultat gouverné est consigné pour qu'un tiers puisse le vérifier. Le registre d'audit est chaîné par hachage, les résultats émettent des reçus signés, et un graphe de provenance relie toute la chaîne, de l'humain au résultat.
Trust LedgerLivré
Un audit chaîné par hachage, à altération détectable
Chaque événement d'audit est chaîné par hachage : toute insertion, modification ou suppression devient détectable, avec un endpoint verify qui prouve l'intégrité sur une plage et renvoie le numéro de séquence rompu si la chaîne a été altérée.
Des reçus de résultat signés, vérifiables hors ligne
Chaque résultat gouverné — une exécution d'agent, l'exécution d'une action, une décision d'approbation — émet un reçu compact à signature détachée qu'un tiers peut valider hors ligne ; la clé de signature est fournie par l'exploitant et le comportement est fail-closed en production.
Un graphe de lignage interrogeable relie la chaîne Human → Agent → Skill → Prompt → Policy → Model → Tool → Artifact → Outcome → Approval, et chaque donnée affichée renvoie à son document source, sa page et sa case.
Construisez des agents qui méritent leur passage en production.
Créez des agents gouvernés en langage naturel ou en code, puis faites-les progresser dans un véritable cycle de vie — brouillon, test, revue, publication — avec un seuil de fiabilité qui décide de ce qui part en production.
Agent StudioLivré
Studio no-code avec le cycle de vie complet de l'agent
Créez des agents avec compétences, connaissances, garde-fous et politique de modèles, puis parcourez le cycle de vie draft → test → review → approve → publish → deploy → pause → retire, avec versionnage des prompts et des instructions et un banc d'évaluation intégré.
Un seuil de fiabilité qui conditionne la publication en production
Un score de 0–100 combine le taux de réussite, le taux de réussite aux évaluations et les incidents sur une fenêtre glissante. Le référentiel refuse de publier un agent qui dispose d'assez de signal et se situe sous le seuil (409 RELIABILITY_TOO_LOW) ; les nouveaux agents se publient librement et, si la notation est indisponible, la publication n'est pas bloquée.
Modélisez types d'objets, relations et métriques vérifiées avec des permissions au niveau objet, propriété et action, plus le versionnage, la promotion, le rollback et la migration de l'ontologie pour faire évoluer le modèle en toute sûreté.
Faites circuler le travail dans le runtime gouverné.
Orchestrez un travail en plusieurs étapes et laissez les événements déclencher des actions gouvernées — sans jamais sortir des contrôles.
AutomatisationLivré
Workflows et règles événement-condition-action
Composez des workflows en plusieurs étapes et des automatisations événement-condition-action qui proposent des actions gouvernées, s'exécutent sur une planification ou une file d'attente et transitent par le Real-Time Hub — chaque étape passant toujours les mêmes contrôles.
Vous ne pouvez pas gouverner ce que vous ne mesurez pas. La notation de qualité par exécution, les portes d'évaluation, un laboratoire de simulation et un débogueur à trace complète transforment la qualité des agents en un chiffre que vous pouvez suivre et imposer comme condition.
ObservabilitéLivré
Notation de qualité par exécution et portes d'évaluation à la publication
Chaque exécution gouvernée est notée sur la qualité — fidélité, couverture des citations, sûreté — et sa trace est capturée pour rejeu ; les suites d'évaluation de référence font office de portes de publication qui bloquent une régression avant la mise en production. Les exécutions en direct renvoient quality { overall: 100 }.
Le débogueur reconstitue l'exécution entière — prompt → context → model → tools → approval → output — chaque étape estampillée de son coût, de sa latence et de son verdict, et chaque saut renvoyant au Trust Ledger.
Testez prompts et modèles en A/B sur du trafic réel et comparez les résultats avant de promouvoir un changement : un candidat fait ainsi ses preuves avant de toucher aux exécutions de production.
Fixez un budget au runtime et rattachez chaque dollar au travail qu'il a payé.
Gouvernance des coûtsLivré
Plafonds de dépense glissants, avec alertes et plafonds stricts
Définissez des budgets à l'échelle du locataire ou de l'agent, avec un seuil d'alerte et un plafond strict facultatif. La dépense est calculée en direct sur une fenêtre glissante de 30 jours, et une exécution est bloquée dès que la dépense projetée dépasserait un plafond strict — en émettant des événements BudgetExceeded.
Gouvernez les modèles qu'un agent a le droit d'utiliser et routez les exécutions via un courtier de calcul : le choix du modèle devient une décision de politique, avec l'usage, l'adoption et le ROI consolidés aux côtés du coût.
Livrez une solution gouvernée une seule fois, déployez-la partout.
Regroupez la solution gouvernée d'un tenant dans un artefact versionné, signé et portable que vous pouvez vérifier et redéployer — d'un tenant à l'autre comme en environnement isolé (air-gapped).
Solution PacksLivré
Des Solution Packs signés et vérifiables
Un pack regroupe des types d'ontologie, des politiques, des actions et les métadonnées des agents ; son contenu est canonicalisé, haché et signé en HMAC. verifyPack vérifie à la fois le hachage du contenu et la signature : toute altération casse hashOk, et tout secret erroné casse signatureOk.
Import avec aperçu des différences et vérification préalable
L'import d'un pack affiche les différences section par section — ajouté, modifié, inchangé — par rapport à vos définitions en production, puis vérifie avant d'appliquer et refuse un pack invalide (409). Le transfert passe par l'artefact, jamais par une écriture directe d'un tenant à l'autre.
Il s'agit du journal des capacités du runtime gouverné actuel, et non d'un historique de versions daté. Vous souhaitez être informé au fil des nouvelles capacités ?S'abonner aux nouveautés
Envie d'aller plus loin ?
Découvrez comment le runtime gouverné s'articule, ou voyez-le tourner sur votre propre travail.