Gouverner les agents OpenAI : autorité, outils et preuve d'audit
Un agent qui appelle des outils décide lui-même lesquels appeler. C'est ce qui le rend utile — et c'est pourquoi un garde-fou qu'il peut choisir d'ignorer n'en est pas un. La décision d'autorité s'appelle depuis votre code, pas depuis le prompt.
Les agents construits sur les modèles d'OpenAI raisonnent puis agissent par appels d'outils : chercher, lire, écrire, envoyer, exécuter. C'est un modèle puissant, parce que l'agent choisit lui-même la séquence — et c'est précisément ce choix qui pose le problème de gouvernance.
Un outil que le modèle peut décider de ne pas appeler n'est pas un garde-fou. Exposer une fonction « vérifier la conformité » et espérer que le modèle y pense, c'est déplacer une décision de conformité dans une consigne de prompt — l'endroit le moins fiable du système. La couche d'autorité doit être appelée par votre code, de façon déterministe, avant l'action sensible.
Le scénario d'intégration
Deux voies. La première, recommandée : un appel HTTP déterministe dans l'implémentation de vos outils sensibles. La seconde, complémentaire : brancher notre serveur MCP pour donner à l'agent les capacités de lecture réglementaire — cartographie de juridictions, feuille de route de conformité — pendant que la décision reste, elle, dans votre code.
- 1
Générez le profil de votre organisation
L'évaluation gratuite (commencer ici) établit vos juridictions, votre secteur et vos catégories de données. Les décisions sont rendues contre ce profil — pas contre des règles génériques.
- 2
Placez l'appel dans l'implémentation de l'outil
Pas dans la description de l'outil, pas dans le prompt système : dans le corps de la fonction. La première ligne de votre
exportCustomerRecord()demande l'autorisation ; le reste ne s'exécute que sur ALLOW.curl -X POST https://structureclerk.ca/api/v1/authority/decide \ -H 'Authorization: Bearer $CLE_API' \ -H 'Content-Type: application/json' \ -d '{"agent":{"id":"support-agent","autonomy_level":3},"action":{"type":"export.customer_record","data_categories":["personal"]},"context":{"jurisdictions":["CA_QC"],"sector":"tech"}}' - 3
Traitez les quatre verbes explicitement
ALLOW exécute. APPROVE remonte une demande de validation à l'interface. DENY refuse et rend la raison au modèle, qui peut l'expliquer à l'utilisateur. ESCALATE notifie et met en attente. Conservez l'identifiant de preuve avec votre trace d'exécution.
- 4
Donnez au modèle de quoi expliquer
La raison rendue est un identifiant stable —
human_only_decision, par exemple — que votre code traduit en phrase pour l'utilisateur. L'agent n'invente pas une justification — il rapporte une décision.
Le contrat, dans votre code
// Le garde-fou est dans VOTRE code, pas dans le prompt.
const decision = await fetch(
"https://structureclerk.ca/api/v1/authority/decide",
{ method: "POST",
headers: { "Content-Type": "application/json",
Authorization: `Bearer ${process.env.SC_API_KEY}` },
body: JSON.stringify({
agent: { id: "support-agent", autonomy_level: 3 },
action: { type: "export.customer_record",
data_categories: ["personal"] },
context: { jurisdictions: ["CA_QC"], sector: "tech" },
}) }
).then(r => r.json());
if (decision.decision === "DENY") return refuse(decision.reason);
if (decision.decision !== "ALLOW") return requestApproval(decision);
// evidence_id conservé avec la trace d'exécution
await performExport();La décision est consultative — StructureClerk décide, votre infrastructure applique. Ici, « votre infrastructure », c'est littéralement le if ci-dessus : c'est vous qui appliquez, et c'est ce qui garde la couche hors de votre chemin critique en cas d'indisponibilité.
| Décision | Ce que fait votre code |
|---|---|
| ALLOW | Exécute l'action, conserve l'identifiant de preuve |
| APPROVE | Remonte une demande de validation à l'interface |
| DENY | Refuse, rend la raison au modèle pour explication |
| ESCALATE | Notifie le responsable, met l'action en attente |
La lecture réglementaire par MCP
Au-delà de la décision, notre serveur MCP expose 5 outils que l'agent peut consulter librement — cartographie de juridictions, vérification de conformité, feuille de route, évaluation algorithmique, et la décision elle-même. Ces lectures sont sûres à laisser au choix du modèle : elles informent, elles n'autorisent rien.
Chaque décision laisse une preuve signée Ed25519, vérifiable par quiconque sur notre page de vérification, sans compte. C'est la réponse à « prouvez que votre agent avait le droit » — une chaîne que votre interlocuteur contrôle sans vous.
+Pourquoi ne pas exposer la décision comme un outil que le modèle appelle ?
Parce qu'un outil que le modèle peut choisir de ne pas appeler n'est pas un garde-fou : le jour où il l'oublie, l'action se fait sans décision et sans preuve. La lecture réglementaire peut être un outil ; l'autorisation doit être dans le chemin d'exécution de l'action.
+Comment auditer les actions d'un agent OpenAI ?
Chaque décision produit une preuve signée Ed25519, horodatée et chaînée, portant la règle appliquée et la raison. Conservez l'identifiant avec votre trace d'exécution : vous obtenez une piste d'audit vérifiable publiquement, indépendante de vos propres journaux.
+Que se passe-t-il si l'appel de décision échoue ?
C'est à votre code d'en décider, et c'est un vrai choix d'architecture : échouer fermé (ne pas exécuter l'action sensible) est le comportement prudent pour les actions irréversibles ; échouer ouvert peut se défendre pour des actions à faible risque. La couche étant hors du chemin critique, les deux options vous restent.
+Le moteur voit-il les données ou les prompts ?
Non. La requête décrit l'action en métadonnées : type, catégories de données, juridictions, secteur, niveau d'autonomie. Ni le contenu, ni le prompt, ni les données clients ne transitent — la décision n'en a pas besoin.
Commencez par le profil
C'est l'évaluation qui personnalise les décisions rendues à vos agents. Elle est gratuite, et ne demande que l'adresse de votre site.