La pile à 10 couches était déjà la plus profonde de la catégorie
Quand nous avons livré notre pile de gouvernance le mois dernier, c’était déjà la plus complète de la catégorie d’automatisation IA. Dix couches couvrant l’identité, la protection des données, la supervision humaine, la conformité et l’observabilité. Aucun concurrent n’avait quoi que ce soit d’approchant.
Mais une pile à 10 couches a une lacune. Vous pouvez contrôler qui exécute un workflow. Vous pouvez contrôler quelles données le workflow accède. Vous pouvez exiger une approbation humaine avant que le workflow ne s’exécute. Ce que vous ne pouviez pas contrôler, c’étaient les outils spécifiques qu’un agent invoque pendant l’exécution.
La lacune : la gouvernance au niveau des outils
Considérez un workflow qui utilise des serveurs MCP pour Slack, Gmail et Salesforce. Le workflow est approuvé pour s’exécuter. L’agent a les bonnes permissions. Mais cet agent devrait-il pouvoir envoyer un email via Gmail sans approbation explicite ? Devrait-il mettre à jour un enregistrement Salesforce de manière autonome ?
n8n a reconnu cette lacune et ajouté l’intervention humaine au niveau de l’appel d’outil individuel. Leur implémentation permet aux utilisateurs individuels d’approuver les appels d’outils pendant l’exécution. Mais c’est contrôlé par l’utilisateur, pas par l’administrateur. Il n’y a pas de couche de politique organisationnelle.
Nous avons adopté une approche différente.
Portes d’approbation des outils : la 11e couche
Les portes d’approbation des outils donnent aux administrateurs un contrôle granulaire sur les outils nécessitant une approbation humaine avant l’exécution. Ce n’est pas une pause au niveau du workflow. C’est une porte au niveau de l’outil.
Voici comment cela fonctionne :
- L’administrateur configure les outils nécessitant une approbation dans les paramètres ACL MCP. Tout outil du catalogue de serveurs MCP du compte peut être signalé.
- Pendant l’exécution du workflow, quand l’agent tente d’invoquer un outil signalé, l’exécution se met en pause.
- Une demande d’approbation est créée montrant le nom de l’outil, les paramètres d’entrée que l’agent veut envoyer et le contexte d’identité de l’agent.
- Un approbateur examine et décide — approuver pour continuer, refuser pour ignorer, ou laisser le timeout auto-refuser.
- L’exécution reprend avec la décision enregistrée dans la piste d’audit.
La différence clé avec l’approche de n8n : les politiques d’approbation sont définies par les administrateurs, pas par les utilisateurs individuels. L’approbateur peut être configuré comme le sponsor de l’agent, tout utilisateur avec un rôle minimum, ou des utilisateurs nommés spécifiques. Les paramètres de timeout et de notification sont une politique organisationnelle, pas une préférence par utilisateur.
La pile complète à 10 couches
Voici ce que fait chaque couche :
| # | Couche | Ce qu’elle gouverne |
|---|---|---|
| 1 | Contrôle d’accès basé sur les rôles | Qui peut faire quoi (6 rôles, 24 permissions, périmètre départemental) |
| 2 | Identité de l’agent | Permissions par agent, limites de taux et propagation du contexte d’audit |
| 3 | Journalisation d’audit | 280+ types d’actions avec preuves immuables et exportables |
| 4 | Détection de PII + tokenisation | Détection automatique et tokenisation réversible des données sensibles |
| 5 | Autonomie graduée | 4 niveaux de confiance (manuel à full auto) avec escalade pilotée par les politiques |
| 6 | Portes d’approbation des outils | Approbation par outil contrôlée par l’admin avant exécution |
| 7 | Contrôles de résidence des données | Préréglages de conformité HIPAA, GDPR, PCI-DSS, SOX, FedRAMP |
| 8 | Chiffrement par clé enveloppe | AES-256-GCM avec dérivation de clé HKDF-SHA256 pour BYOK |
| 9 | Tableau de bord de conformité + SOC 2 | 21 politiques, 17 contrôles TSC, export de preuves, intégration Vanta |
| 10 | Moteur de conformité EU AI Act | Cartographie de 10 articles (Art. 9-17, 52), classification de risque, génération de preuves |
| 10 | Évaluation de préparation à la gouvernance | Scoring en libre-service sur toutes les couches de gouvernance avec recommandations |
Chaque couche fonctionne indépendamment mais s’intègre aux autres. L’identité de l’agent (couche 2) se propage à travers les portes d’approbation des outils (couche 6) pour que les approbateurs voient exactement quel agent demande l’accès à l’outil. La journalisation d’audit (couche 3) enregistre chaque décision d’approbation. Le tableau de bord de conformité (couche 9) suit la conformité des approbations d’outils dans toute l’organisation.
Pourquoi la profondeur compte plus que la largeur
Microsoft, OpenAI et Anthropic investissent tous dans la gouvernance. Le Microsoft Agent Framework ajoute l’assignation basique de rôles. OpenAI Frontier a l’identité par agent. Anthropic offre des contrôles admin entreprise.
Ce sont des premiers pas importants. Mais la profondeur de gouvernance se mesure en couches, pas en fonctionnalités. Une plateforme avec le contrôle d’accès basé sur les rôles mais sans détection de PII a une lacune de gouvernance. Une plateforme avec la journalisation d’audit mais sans contrôles au niveau des outils a une lacune de gouvernance. Une plateforme avec des préréglages de conformité mais sans cartographie EU AI Act a une lacune de gouvernance.
10 couches signifie 10 points de défaillance potentiels couverts. Non pas parce que nous avons choisi 10 comme nombre, mais parce que les déploiements IA en entreprise ont au moins 10 exigences de gouvernance distinctes.
Et ensuite
La course à la gouvernance s’accélère. Chaque plateforme majeure livre des fonctionnalités de gouvernance. La question n’est plus s’il faut gouverner les agents IA, mais à quelle profondeur.
Nous continuerons à ajouter des couches au fur et à mesure que de nouvelles exigences de gouvernance émergent. La pile est conçue pour grandir.
Explorez la pile de gouvernance | Essayez l’évaluation de préparation à la gouvernance