Agents d’IA gouvernés : un modèle de politique, plusieurs points d’application en temps de exécution.

Un agent d’assistance reçoit une demande de remboursement. Le message contient un numéro de compte et un numéro de téléphone. Pour y faire face, l’agent a besoin d’un modèle linguistique pour lire la demande, d’une outil interne pour rechercher la commande, d’un CRM accessible via MCP afin d’ajouter une note, et éventuellement d’un deuxième agent pour examiner un remboursement anormalement important. Rien de tout cela n’est plus exotique aujourd’hui. La difficulté réside dans le fait que chaque étape de cette chaîne franchit une frontière différente de politique, et chacune de ces traversées soulève sa propre question.

• Ces données clients peuvent-elles être transmises au fournisseur de modèle sélectionné ?
• La demande reste-t-elle dans le cadre du budget alloué ?
• Ce travail peut-il utiliser ce modèle dans cette région ?
• Le serveur CRM doit-il recevoir toute la conversation ?
• L’outil de remboursement peut-il verser 2 000 dollars sans l’approbation d’un humain ?

Si le modèle préféré est indisponible, l’alternative offre-t-elle une résidence des données et une sécurité équivalentes ?

Un document de politique peut, en principe, répondre à de telles questions, et un prompt système peut rappeler à un agent certains points importants. Aucun de ces éléments ne garantit l’application cohérente des règles. C’est pourquoi la gouvernance des agents devient un problème en temps réel.

Un cadre publié pour les agents gérés décrit bien ce changement : la gouvernance définit les règles, et un point d’accès constitue l’endroit où ces règles interagissent avec le trafic en direct. Il organise les tâches en cinq activités : gouverner, décider, protéger, observer et assurer. Un point utile à noter est que les appels aux modèles, les appels aux outils, les appels MCP ainsi que les échanges entre agents présentent chacun des risques différents. Cette distinction permet une conception plus efficace que de regrouper tous les contrôles dans un seul prompt ou un seul point d’accès.

Permettre à la politique de voyager avec la demande

La représentation la plus simple consiste en une enveloppe de gouvernance qui accompagne toute interaction au sein du système. Elle contient suffisamment de contexte pour permettre une décision avant que toute limite ne soit franchie :

• l’identité et le client,
• la charge de travail et l’agent,
• le niveau de risque et la classification des données,
• les dépenses actuelles et les limites fixées,
• les fournisseurs et régions autorisés,
• les outils autorisés et les domaines d’action possibles,
• les seuils nécessitant une approbation humaine,
• la version de la politique, ainsi qu’un identifiant de suivi ou de décision.

Tous les composants n’ont pas besoin de tous les champs. Cette enveloppe existe afin que les mêmes types de questions puissent être répondues de manière cohérente, quel que soit l’endroit où se trouve l’agent.

• Pour une appel à un modèle, les informations pertinentes sont les dépenses, le fournisseur, la région, la durée de conservation et les mesures de suppression des données.
• Pour un outil de remboursement, il s’agit de l’identité de l’utilisateur, du statut de propriété de la commande, du montant et du niveau d’approbation requis.

Pour une appel MCP, il s’agit du serveur auquel on se connecte ainsi que des données qui quittent les limites de l’infrastructure.

Pour un saut d’agent à agent, il s’agit de savoir si le destinataire peut voir le contexte transmis.

Ainsi, la conception n’est pas basée sur un filtre universel. Il s’agit d’un modèle de politique unique avec plusieurs points d’application. La gouvernance en temps de exécution devient concrète à ce stade, car la question pertinente n’est pas de savoir s’il existe une politique, mais quel composant est capable d’interrompre l’interaction avant tout effet secondaire.

Un schéma simple et neutre par rapport aux fournisseurs

Aucune plateforme de gouvernance n’est nécessaire pour identifier ce schéma. Le code Python ci-dessous est délibérément neutre et non lié à aucune API de produit. Son rôle est d’exposer les points de décision.

from dataclasses import dataclass
from enum import Enum

class Decision(str, Enum):
    ALLOW = "allow"
    BLOCK = "block"
    APPROVAL = "approval"
    FALLBACK = "fallback"

@dataclass(frozen=True)
class PolicyContext:
    user_id: str
    workload: str
    risk_tier: str
    data_class: str
    spend_usd: float
    spend_limit_usd: float
    policy_version: str

def before_model_call(ctx: PolicyContext, model: str) -> Decision:
    if ctx.spend_usd >= ctx.spend_limit_usd:
        return Decision.BLOCK
    if ctx.data_class == "restricted" and model not in APPROVED_PRIVATE_MODELS:
        return Decision.FALLBACK
    return Decision.ALLOW

def before_tool_call(
    ctx: PolicyContext,
    tool: str,
    amount: float = 0,
) -> Decision:
    if tool not in TOOL_SCOPES[ctx.workload]:
        return Decision.BLOCK
    if tool == "issue_refund" and amount > 500:
        return Decision.APPROVAL
    return Decision.ALLOW

def before_mcp_call(
    ctx: PolicyContext,
    server: str,
) -> Decision:
    if server not in APPROVED_MCP_SERVERS:
        return Decision.BLOCK
    if ctx.data_class == "restricted" and server in EXTERNAL_SERVERS:
        return Decision.BLOCK
    return Decision.ALLOW

La syntaxe importe moins que la liste des cas dans lesquels le modèle n’a jamais le droit de trancher. Il peut raisonner sur ce que souhaite le client. Il ne peut pas décréter qu’un remboursement de 2 000 dollars est conforme à la politique, ni que un serveur MCP non approuvé est acceptable parce que la demande semble inoffensive. Ces résultats correspondent à des changements d’état déterministes gérés par l’environnement de exécution.

Une version en production doit également fournir des preuves pour chaque décision : la version de la politique, la portée des entrées, le résultat, le motif, l’acteur, l’heure et l’ID de suivi. Celes preuves permettent de déterminer quelle politique a réellement été appliquée, contrairement à une simple indication que un document de politique existait.

Un gateway de modèle est utile, mais ce n’est pas l’ensemble du design

Dans ce cadre, un portail LLM constitue une couche commune pour l’authentification, le choix du modèle, le tri du contexte, les politiques de dépense, la gestion des pannes et les éléments justificatifs des décisions. Un produit actuel d’un fournisseur de outils pour agents rend cela concret : il est entré en bêta publique en août 2026 et offre des limites de dépense et de taux, des solutions de secours pour les modèles, un routage vers les fournisseurs, une protection des données sensibles ainsi qu’une intégration de suivi. L’adoption par les clients utilisant des modèles ordinaires doit rester simple : il suffit de diriger l’adresse base_url du client vers le portail, de stocker les clés des fournisseurs de manière centralisée et de définir les politiques en un seul endroit.

Cela est important car, sinon, la gouvernance des modèles serait copiée dans chaque agent.

agent A → custom rate logic → OpenAI
agent B → custom PII logic  → Anthropic
agent C → custom fallback   → Gemini
agent D → no controls       → self-hosted model

Une passerelle peut regrouper la pile en une seule couche partagée.

  agents
     ↓
shared model-call policy
     ↓
approved providers / hosts

Il convient cependant de résister à une généralisation trop hâtive. Le cadre de gouvernance est plus vaste que n’importe quel produit de type gateway. Il aborde explicitement les appels aux outils, les appels MCP ainsi que les interactions entre agents, car le plus grand risque lié aux agents réside souvent dans l’action qu’ils peuvent entreprendre et non dans le texte qu’ils génèrent. Les contrôles en version bêta publique du gateway concernent principalement le trafic des modèles. Une surveillance supplémentaire reste nécessaire dans l’outil d’exploitation des agents, le temps de exécution des outils, les limites MCP ou un gateway d’actions dédié. Cette séparation est bénéfique, car un gateway de modèles ne devrait pas prétendre pouvoir autoriser une modification d’une base de données en production qu’il ne voit jamais.

La fiabilité fait partie de la gouvernance

Lorsqu’un gateway se trouve sur le chemin critique, une gouvernance floue peut provoquer à son tour des pannes. Deux approches aident à y remédier.

Tout d’abord, chaque charge de travail nécessite une stratégie explicite de fonctionnement en cas d’échec : soit ouverture en cas d’échec, soit fermeture en cas d’échec. Une demande de synthèse à faible risque qui ne parvient pas au service de politique peut fonctionner de manière progressive et fiable. Une demande concernant des données restreintes qui ne peut pas prouver que la politique de suppression ou de stockage a été appliquée ne doit pas pouvoir fonctionner en mode ouverture en cas d’échec.

Deuxièmement, un modèle de secours doit être équivalent sur le plan des politiques, et non simplement disponible. Supposons que le modèle principal ait été approuvé car il stocke les données dans une région requise conformément à une politique de conservation convenue. Un passage automatique à un fournisseur moins cher ou plus disponible qui enfreint ces conditions ne renforce pas la résilience ; cela substitue une violation des règles de conformité à l’apparence de continuité de service.

Les contrôles de dépenses suivent la même logique. Des plafonds stricts sont utiles, mais un plafond sans alerte ni mécanisme d’escalade transforme la gouvernance en une panne arbitraire. Une meilleure approche consiste à utiliser une séquence de contrôles.

usage approaches threshold
        ↓
      alert
        ↓
route / reduce context / downgrade model if allowed
        ↓
hard block when policy requires it
        ↓
auditable exception path if business-approved

Pour cette raison, le routage de modèles est plus proche de la gestion de portefeuille que d’envoyer des requêtes simples à un modèle bon marché. Le coût est important, tout comme la latence, le traitement des données, la qualité, le niveau de risque et l’disponibilité.

Le coût d’un plan de contrôle central

En regroupant les politiques en un seul endroit, on évite à chaque agent de conserver sa propre copie, mais cela concentre également les responsabilités en ce lieu. La couche de exécution se trouve désormais sur le chemin du trafic des modèles et, dans certains schémas, elle aide à autoriser les actions ; il faut donc la concevoir comme n’importe quel autre service critique.

• Les vérifications de politique doivent s’exécuter suffisamment rapidement pour ne pas dominer la latence des requêtes, et le service de politique doit lui-même disposer de redondance.
• Les données de prix pour chaque fournisseur doivent être mises à jour et stockées en mémoire cache ; les jetons de batch et de raisonnement doivent être comptés avec précision afin que les plafonds de dépenses soient fiables.

Les règles de rédaction doivent être testées pour détecter les fuites d’informations ainsi que les faux positifs.

Les modifications des politiques nécessitent une gestion des versions, un déploiement progressif et une possibilité de réversion, de la même manière que le code des applications.

Un autre coût est d’ordre organisationnel. Une équipe centrale chargée de la plateforme peut faciliter l’application de paramètres par défaut sûrs, mais des contrôles trop stricts peuvent ralentir les équipes de développement. Une approche allant de la visibilité, en passant par le contrôle, jusqu’à l’assurance atténue ce problème : observer d’abord, exécuter la nouvelle politique en mode d’avertissement ou en mode fantôme, mesurer les effets, et ne bloquer définitivement que là où le risque l’exige. Cette couche devrait éliminer les tâches répétitives sans devenir une dépendance opaque que personne ne peut contourner, déboguer ou modifier en toute sécurité.

Les garde-fous ne devraient pas prendre en charge des actions à conséquences importantes

Les mécanismes de protection existent en deux types. Les règles basées sur des modèles conviennent aux secrets et identifiants structurés. Les détecteurs basés sur des modèles gèrent des catégories plus floues telles que les données personnelles non structurées, les tentatives de déblocage ou les problèmes de fiabilité. Aucun de ces systèmes n’est parfait, et les vérifications basées sur des modèles étant probabilistes, elles peuvent entraîner à la fois des faux positifs et des faux négatifs.

Une règle de production fiable stipule que la détection du contenu peut réduire le risque, mais elle ne doit jamais être le seul mécanisme de contrôle entre un agent et les effets secondaires potentiels.

• Un plafond de remboursement est mieux défini en code qu’à l’aide d’un classificateur.
• Toute mise en œuvre de production doit inclure une vérification d’autorisation.
• Une action à haut risque peut nécessiter l’approbation humaine.
• Les identifiants doivent être encadrés de manière à ce qu’un agent ne puisse pas dépasser les limites requises par sa tâche, même si un mécanisme de protection manque quelque chose.

Le cadre définit cette frontière de la même manière : les actions conséquentes dépendent de limites déterministes ou de l’approbation humaine, et non pas uniquement de la détection du contenu. Il s’agit du fossé entre la détection d’une intention dangereuse et le contrôle des capacités dangereuses. Les directives d’OWASP concernant une autonomie excessive aboutissent indépendamment au même constat, recommandant une fonctionnalité et des permissions minimales pour les outils, l’autorisation étant appliquée dans les systèmes ultérieurs plutôt que laissée au jugement du modèle lui-même. Ces deux niveaux sont nécessaires.

Observation et garantie

Le suivi devient bien plus utile une fois que les décisions de politique font partie du suivi.

• Une demande de modèle bloquée indique quelle politique de dépense a été activée.
• Un événement de censure montre quelle version de politique a été appliquée sans révéler la valeur sensible.
• L’approbation d’un outil est liée à l’action qu’il a autorisée.

Un mécanisme de secours indique pourquoi le système principal a échoué et pourquoi le remplaçant a été jugé acceptable.

Les évaluations peuvent alors aller au-delà de la simple question de l’exactitude du modèle. Elles permettent de vérifier si un modèle plus petit conserve sa qualité après un changement de routage, si la suppression de contexte réduit les coûts sans nuire aux résultats, si une politique de censure génère trop de faux positifs, et si un nouveau mécanisme de secours reste équivalent sur le plan des politiques.

Tout cela forme un cycle en cinq étapes. Govern définit les responsabilités, les risques et les politiques ; Decide gère les routages, les escalades et les basculements ; Protect assure le respect des règles à chaque étape ; Observe mesure le comportement et les résultats des politiques ; Assure préserve l’historique et teste les modifications. Le déploiement d’une règle ne termine pas le travail. Le travail est terminé lorsque l’on peut indiquer quelle règle a été appliquée, quelle décision elle a prise, ce qui s’est passé par la suite, et si le système continue de fonctionner correctement après les changements.

Que cela signifie pour l’architecture des agents

Les agents en production ont besoin d’une architecture de contrôle en temps réel, quel que soit le portail choisi. Un portail de modèle centralisé constitue un endroit idéal pour gérer les dépenses, le choix des fournisseurs, la censure, les limites de vitesse et les solutions de secours, tout en permettant une flexibilité des modèles sans avoir à modifier chaque application. Un agent régulé a néanmoins besoin des couches environnantes suivantes :

• l’autorisation et des limites fixes pour les actions des outils,
• des décisions de confiance concernant les serveurs MCP ainsi que des règles définissant quels données peuvent être transférées,
• un contexte minimalisé et une identité vérifiée entre les agents collaborant,
• une approbation ou une limitation pour tout ce qui peut avoir des conséquences graves,
• une traçabilité complète de la politique derrière chaque décision.

En ce qui concerne la demande de remboursement, le modèle peut toujours raisonner et l’agent peut toujours agir. L’architecture cesse simplement de demander au modèle d’intégrer l’ensemble du programme de gouvernance dans son prompt. Chaque limite importante voit sa question répondue avant même que l’on ne la franchisse :

• Qui pose la question ?
• Quels données sont transférées, et où ?
• Quel volume de travail est autorisé ?
• Quels modèles et outils sont permis ?
• Quel est le plan en cas de défaillance du chemin préféré ?
• Est une validation humaine nécessaire ?
• Quelle version de la politique a pris cette décision ?

C’est ce qui distingue l’existence de politiques d’IA de celle d’agents gérés.