Changement de paradigme
Un agent n'est pas un utilisateur : qu'est-ce qui change quand le logiciel agit seul ?
Dans cette page, un agent désigne un logiciel auquel on a donné des identifiants et le droit d'agir : il s'authentifie seul, appelle des API, écrit dans vos systèmes, parfois déclenche d'autres agents. Peu importe le cadre qui le fait tourner, ce qui compte est qu'il détient une identité et un périmètre, comme un compte de service, sauf qu'il agit à la vitesse de la machine. La distinction avec un utilisateur n'est donc pas sémantique : elle détermine quels contrôles réduisent le risque et lesquels ajoutent seulement de la friction.
01
Le modèle utilisateur : demander, recevoir, décider
Un utilisateur humain interagit de manière séquentielle. Il pose une question, reçoit une réponse, décide de la suite. Chaque action est précédée d'une intention. Les contrôles conçus pour ce modèle, politiques d'accès conditionnelles, revues d'approbation, alertes sur les comportements inhabituels, supposent un acteur qui s'arrête, lit et choisit. Ce modèle fonctionne pour des humains. Il ne tient pas face à un agent.
02
Le modèle agent : s'authentifier, appeler, écrire
Un agent s'authentifie une fois, puis agit en continu selon les instructions de son orchestrateur. Il n'y a pas de pause entre la décision et l'exécution. Il enchaîne les appels d'API, écrit dans plusieurs bases, déclenche des notifications, crée des ressources, avec les droits du compte qu'il utilise, qu'ils correspondent à la tâche ou non. Un agent sur-privilégié qui déraille, qu'il soit compromis, mal configuré ou en train d'exécuter une instruction ambiguë, agit à la vitesse de la machine sur tout ce que son identité couvre.
03
L'écriture et la lecture ne se rattrapent pas de la même façon
L'écriture engage l'intégrité et la disponibilité : une écriture fautive laisse une trace et se restaure le plus souvent. La lecture engage la confidentialité : une donnée sortie ne revient pas. Les deux comptent dans le périmètre d'impact, ce qui impose de cartographier le périmètre dans les deux sens, et pas seulement du côté des droits d'écriture.
Vous traitez déjà cette question pour vos collaborateurs : c'est du moindre privilège appliqué à des identités non humaines, des logiciels qui s'authentifient et agissent sans intervention.
Analyse comparative
Filtres de contenu ou gestion des accès : où se situe la vraie protection ?
Les garde-fous, filtres de prompt et validation des sorties, contrôlent ce que l'agent dit ou reçoit. C'est utile, mais insuffisant : si un token fuite, l'attaquant contourne complètement le modèle et attaque directement vos API. Cloudflare fournit ces filtres dans AI Gateway, avec des politiques de prévention des fuites de données. Retenez la répartition : le filtrage de contenu évite les dérives de langage, le contrôle d'accès limite la casse.
Quatre scénarios, deux couches de défense
Les modes de défaillance ne sont pas théoriques : un token fuité, une politique jamais resserrée, une dépendance qui embarque plus que prévu.
| Scénario de défaillance | Ce que fait un filtre de contenu | Ce que fait un périmètre restreint |
|---|---|---|
| Injection de prompt malveillante | Bloque l'instruction ou la réponse si le motif est détecté. | Sans effet sur l'instruction, mais empêche l'agent d'exécuter une action hors périmètre. |
| Fuite du token d'accès | Inutile : l'attaquant contourne le modèle. | Révocation immédiate de ce seul token, sans couper les autres agents. |
| Dépendance qui embarque plus d'accès qu'annoncé | Inutile : aucun texte n'est analysé. | Hors d'atteinte : les liaisons sont déclarées, l'accès non prévu est rejeté. |
| Ordre ambigu d'écriture en base | Alerte seulement si l'intention est explicite dans le prompt. | Écriture refusée si la base n'est pas dans les destinations autorisées. |
Là où la comparaison diverge
- Peu importe comment un agent est compromis, instruction malveillante, injection dans son contexte, token fuité ou erreur de configuration : ses droits définissent ce qu'il peut réellement atteindre.
- Un agent dont le périmètre est strictement délimité n'écrit pas dans une base qu'il n'est pas autorisé à toucher, même s'il reçoit l'instruction de le faire.
- La question utile n'est pas de savoir si toute attaque peut être empêchée, mais ce à quoi ressemble le pire cas si un agent est compromis aujourd'hui, avec le modèle d'identité que vous avez aujourd'hui.
L'injection de prompt et le filtrage des sorties relèvent de la couche contenu et se gouvernent séparément de l'identité et du périmètre. Cette page traite l'identité et le périmètre.
Périmètre technique
Qu'est-ce que vous pouvez réellement contrôler sur Cloudflare ?
Sept couches de contrôle, chacune sur une dimension différente de l'exposition d'un agent en production : qui il est, ce qu'il peut appeler, où il peut aller, ce qu'il envoie à un modèle, où il s'exécute, et ce que ses serveurs MCP exposent.
Access : identité de service et moindre privilège
Cloudflare Access attribue à chaque agent un token de service dédié, une paire identifiant client et secret client, distincte de toute identité humaine. La politique associée définit les applications et les ressources que cet agent atteint : si un agent n'a besoin que d'un endpoint, son token ne donne accès qu'à celui-là. Le moindre privilège devient une politique appliquée et auditée.
Cas concretChaque token se révoque individuellement, immédiatement, sans toucher aux autres agents.
mTLS : authentification machine à machine
Le TLS mutuel exige que chaque partie présente un certificat valide. L'agent prouve son identité par une clé cryptographique qui lui est propre, pas par une clé d'API partagée, et il vérifie de son côté le certificat du service qu'il appelle.
Cas concretAucune des deux extrémités ne peut être usurpée sans la clé privée : c'est la voie que laisse ouverte un compte de service partagé.
API Shield : les appels de vos agents vers vos propres API
API Shield gouverne les API que vous exposez. Quand un agent appelle une API interne placée derrière Cloudflare, API Shield découvre cet endpoint à partir du trafic réel, valide chaque requête contre le schéma attendu et bloque en périphérie ce qui ne correspond pas, avant que l'appel n'atteigne le service amont. La posture d'authentification, le mTLS et la validation des jetons JWT s'appliquent sur le même chemin. Le contrôle des appels vers des tiers est un autre levier, il relève de Gateway.
Cas concretC'est la couverture du trafic vers votre propre patrimoine, là où atterrissent la plupart des écritures.
Gateway : destinations autorisées uniquement
Cloudflare Gateway filtre en DNS, en réseau et en HTTP les destinations qu'un agent peut joindre. Seules celles que vous autorisez passent. C'est ce qui ferme les chemins d'exfiltration que le cloisonnement applicatif laisse ouverts. Attention au point d'entrée : Gateway ne voit que le trafic qui passe par lui, et un agent déployé dans Workers n'y passe pas par défaut.
Cas concretUn agent compromis ne joint pas un point de collecte qui n'est pas sur la liste.
AI Gateway : chaque appel de modèle, journalisé
Les appels routés via AI Gateway sont journalisés avec le prompt, la réponse, le fournisseur, l'horodatage, le statut, la consommation de tokens, le coût, la durée et l'agent utilisateur du client. L'identité, elle, n'y figure pas par défaut : l'attribution par agent s'obtient en passant cette identité en métadonnée personnalisée sur l'appel, une ligne à ajouter dans la requête et l'étape que la plupart des déploiements sautent.
Cas concretUne fois posée, les journaux partent vers votre SIEM via Logpush et un appel suspect se rejoue tel quel.
Workers : exécution isolée
Chaque instance tourne dans un isolat V8 distinct. Le code d'un isolat n'accède pas à la mémoire hors de cet isolat, même dans le même processus, et les liaisons déclarées définissent explicitement les ressources accessibles à chaque Worker : bases de données, files de messages, espaces de stockage. Cloudflare documente ouvertement le cas résiduel, les attaques par canal auxiliaire de la famille Spectre concernant toute plateforme multi-locataire, et y répond par une défense en couches.
Cas concretCe qui n'est pas déclaré n'existe pas pour cet agent, et un agent compromis n'hérite pas des liaisons d'un autre.
Sécurité des serveurs MCP : ce que vous exposez, et à qui
Un serveur MCP déclare des outils, des ressources et des capacités que les agents connectés peuvent invoquer. La spécification est explicite : les invocations d'outils sont de l'exécution de code arbitraire et demandent la prudence correspondante. Cloudflare One propose deux contrôles. Access sécurise directement un serveur MCP, qu'il tourne sur un nom d'hôte que vous contrôlez ou qu'il soit hébergé par un éditeur acceptant Access comme fournisseur d'identité OIDC. Et un portail de serveurs MCP regroupe plusieurs serveurs derrière un point d'entrée unique, où l'administrateur choisit les outils et les modèles de prompt exposés, applique sa propre politique et trace chaque invocation.
Cas concretC'est le moindre privilège au niveau de l'outil, c'est-à-dire au niveau où MCP travaille réellement.
L'authentification dépend du montage : un agent qui atteint un serveur placé derrière Access présente son propre token de service, tandis qu'un serveur qui gère son propre flux OAuth autorise l'agent par OAuth, comme le prévoit le protocole. Le même socle protège aussi les API que vos agents appellent contre le reste du trafic, et ce qu'un agent peut faire sortir est aussi une question de données, traitée dans ce qu'un agent peut exfiltrer. Si vous construisez aussi les agents, voyez notre développement d'applications agentiques.
Conformité et régulation
Quelles obligations suivent un agent qui agit seul ?
Une action automatisée reste imputable à l'organisation qui a déployé l'agent. L'agent n'est pas une entité juridique distincte : s'il écrit dans une base, appelle une API externe ou traite des données personnelles, votre organisation répond de cette action.
| Référentiel | Exigence clé | Impact opérationnel pour l'agent |
|---|---|---|
| Directive NIS2 | Documentation des actifs et journalisation des accès critiques | Attribution stricte : chaque journal doit établir quelle identité d'agent a agi, sur quoi et quand. Un compte de service partagé rend les deux impossibles. Voir les obligations de contrôle d'accès et de journalisation. |
| AI Act, règlement (UE) 2024/1689 | Article 12 : enregistrement automatique des événements pour les systèmes classés à haut risque | Traçabilité du fonctionnement de l'agent sur toute sa durée de vie. La classification dépend de l'usage et non de la technologie : emploi, évaluation de solvabilité, infrastructures critiques sont les cas à examiner de près. |
| RGPD | Respect de la finalité et traçabilité des accès aux données personnelles | La finalité vaut pour le traitement, pas pour l'outil : un agent ne réutilise pas un accès au motif qu'il le possède. Isoler les accès selon le traitement autorisé, et pouvoir établir quelle identité a lu quoi. |
Ces éléments constituent un éclairage technique et non un conseil juridique. Les obligations varient selon le secteur, la juridiction et la classification du système.
Contrôle qualité
Que vérifier avant de laisser un agent passer en production ?
Cinq questions, posées avant chaque déploiement plutôt qu'après le premier incident. Aucune ne demande d'outil pour être tranchée, et les réponses sont le point de départ d'une revue de gouvernance.
01
L'agent dispose-t-il de sa propre identité de service ?
Chaque agent en production a son propre token de service Access ou son propre certificat mTLS. Un agent qui emprunte les identifiants d'une personne hérite de son périmètre entier, et quand cette personne change de rôle ou quitte l'entreprise, l'accès de l'agent survit souvent au départ, faute de lien entre les deux.
02
Son périmètre est-il documenté, appliqué, et vérifié dans les deux sens ?
Le périmètre se restreint en lecture comme en écriture, par les politiques Access, les règles Gateway, les liaisons Workers et la portée des serveurs MCP. Ce qu'il faut chercher, c'est l'écart entre les droits accordés et les droits réellement utilisés en production.
03
Chaque appel de modèle est-il journalisé et rejouable ?
AI Gateway doit recevoir l'identité de l'agent en métadonnée personnalisée, sans quoi vous avez le contenu de l'appel mais pas son auteur. Les journaux Access couvrent les authentifications, les journaux Gateway les destinations réseau.
04
Les serveurs MCP auxquels il se connecte sont-ils inventoriés ?
Chaque outil accessible est documenté, restreint par agent et placé derrière un portail de contrôle. Un agent connecté à un serveur non inventorié hérite d'un périmètre inconnu.
05
Existe-t-il une procédure de révocation testée ?
Access révoque un token immédiatement, mais quelqu'un doit déclencher l'opération, et savoir avant que le token est compromis. Définir le chemin, nommer le responsable, tester avant d'en avoir besoin.
Metryx évalue votre configuration Cloudflare réelle contre un référentiel structuré, DNS, TLS, WAF et règles, c'est-à-dire le socle sur lequel vos contrôles d'agents sont déployés. Il n'inspecte pas de lui-même le périmètre de vos agents : lancez un audit de configuration Cloudflare pour obtenir ce socle mesuré, puis apportez l'inventaire des agents à la revue.
Vous ne savez pas ce que couvre réellement votre configuration Cloudflare ?
Metryx audite votre configuration Cloudflare, DNS, TLS, mode du WAF et règles, et rattache chaque écart à un correctif. Il mesure le socle sur lequel vos agents s'exécutent ; la gouvernance de leur identité et de leur périmètre s'opère en service managé par-dessus.
Lancer un audit express- Accès gratuit, sans engagement
- Token Cloudflare en lecture seule
- Aucune configuration requise
- Rapport téléchargeable à partager en interne
- Autant d'audits que vous voulez, sur autant de zones que vous voulez
Point de départ
Par où commencer, selon votre situation ?
Le bon point d'entrée dépend du modèle d'identité que vous exploitez déjà. Trois situations, trois premiers pas différents.
01
Des agents en preuve de concept, avec les identifiants d'un humain
La situation la plus courante, et celle qui ne devrait pas survivre au passage en production. Premier pas, la séparation des identités : chaque agent obtient son token de service avant de toucher des données de production. Un audit de configuration Cloudflare en lecture seule établit la cartographie de départ, sans modification ni interruption.
02
Des agents en production sur un compte de service partagé
La configuration la plus risquée : une compromission expose tous les agents du compte, avec leurs droits d'écriture et leur périmètre d'appel cumulés, et révoquer un seul agent affecte tous les autres. Premier pas, le cloisonnement par agent, avant toute autre amélioration. Le token étant une variable d'environnement, la migration ne demande aucune modification applicative.
03
Des agents avec leur propre identité, mais sans revue de périmètre
Le travail technique est fait. Mais si le périmètre n'a jamais été confronté à l'usage réel, il peut rester bien plus large que la tâche ne l'exige. Premier pas, une revue structurée : croiser ce que chaque agent peut atteindre avec ce qu'il a besoin d'atteindre, puis resserrer les politiques.
Méthodologie
Comment déployer la gouvernance des agents sans bloquer les équipes de développement ?
La gouvernance ne doit pas devenir un frein à la livraison. La séquence ci-dessous laisse tourner les agents en place pendant que le périmètre se resserre sous eux.
Phase 1
Inventaire des agents
Nous cartographions l'existant sans rien modifier : quels agents tournent, avec quelles identités, quels droits, quels serveurs MCP connectés, quels appels de modèles. Cette phase révèle presque toujours des agents que personne n'avait enregistrés : une preuve de concept qui fonctionne reste en production, sans que quiconque ait décidé de l'y laisser.
Phase 2
Séparation des identités
Attribution d'un token Access ou d'un certificat mTLS dédié à chaque agent. Cloisonnement des comptes de service sans impact applicatif : le token est une variable d'environnement, l'agent n'a pas besoin de savoir qu'elle a changé.
Phase 3
Moindre privilège appliqué
Nous resserrons les accès sur ce que le trafic montre réellement : nous fermons les endpoints jamais sollicités, filtrons les destinations autorisées, réduisons les outils MCP exposés. Ce qu'un agent n'a jamais appelé en production, il ne l'atteint plus. C'est ici que le périmètre d'impact se réduit.
Phase 4
Gouvernance continue
Nous branchons le contrôle sur la chaîne de livraison : tout nouvel agent passe une vérification avant la production, et une revue régulière traque la dérive. Un agent démarre au strict nécessaire, et ses accès ne s'élargissent que sur un besoin documenté.
La gouvernance devient alors une pratique d'exploitation et non un projet : c'est la différence entre une politique écrite et une posture réelle.
Le service managé
Comment Brixio gouverne les agents IA au quotidien ?
Les agents tournent en continu. Un token compromis à 02h00 un samedi demande donc la même réponse qu'à 10h00 un mardi. Notre couverture s'appuie sur quatre hubs, et c'est un ingénieur qui répond, pas un accusé de réception.
Couverture 24/7 follow-the-sun
- Événements d'identité, dérives d'accès et alertes AI Gateway suivis sans interruption
- Un ingénieur prend la réponse, avec le même chemin d'escalade quelle que soit l'heure
- Quatre hubs, Luxembourg · Paris · Dubaï · Singapour, pas une seule équipe régionale
Une équipe certifiée et agréée Cloudflare
- Brixio est partenaire agréé Cloudflare, Authorized Cloudflare Service Delivery Partner, autorisation détenue au niveau de la société
- Les ingénieurs qui délivrent la prestation détiennent des certifications Cloudflare individuelles, sur Zero Trust, AI Gateway et Workers
- Traitement des données certifié ISO 27001:2022
- Un interlocuteur nommé, qui connaît votre architecture d'agents
Cadence de gouvernance et SLA
- SLA de réponse définis par niveau de gravité sur les incidents d'identité et d'accès
- Seuils d'escalade convenus à la mise en service
- Revues de gouvernance à cadence régulière : quels agents sont en production, si leurs accès ont dérivé, si un nouvel agent est passé hors du chemin de revue
Intégré au reste du socle
- L'identité des agents vit sur le même plan de contrôle Zero Trust que vos accès humains
- Les appels de modèles partent vers votre SIEM avec leur identité
- L'exposition MCP est revue à chaque nouveau serveur ou intégration
Chaque action d'agent converge sur un plan de politique unique : authentifiée par agent, restreinte aux destinations déclarées, journalisée avec son identité, exploitée 24/7 par Brixio sur Brixio One.
Le socle de sécurité sur lequel cela s'appuie
Cloudflare
Authorized Service Delivery Partner (ASDP)
ISO 27001:2022
traitement des données certifié
450+
projets livrés en environnements régulés
4 hubs
Luxembourg · Paris · Dubaï · Singapour, follow-the-sun
Cela s'inscrit dans notre pratique sécurité de l'IA et sur le même plan de contrôle Zero Trust que le ZTNA et la détection du Shadow AI. Contactez-nous pour le cadrer sur votre environnement.
La frontière
Ce que la gouvernance des agents sur Cloudflare ne couvre pas.
Être précis sur la frontière fait partie du service. La gouvernance contrôle ce qu'un agent peut atteindre ; ces quatre sujets vivent ailleurs, et chacun a sa destination.
La qualité et les hallucinations des modèles
Nous contrôlons ce que l'agent peut atteindre, pas la pertinence métier de ses réponses. C'est une question d'évaluation de modèles, et confondre les deux conduit à prendre une revue de périmètre pour un audit de comportement.
La gouvernance interne des données
La définition des politiques sur les données qu'un agent peut utiliser, les sorties qu'il peut transmettre et la durée de conservation de ses journaux relève d'une fonction dotée d'une autorité organisationnelle. Nous fournissons les preuves, votre instance décide.
Le contenu des modèles tiers
Vous pouvez journaliser ce que vous envoyez et ce que vous recevez. Vous ne pouvez pas auditer les poids, les données d'entraînement ni les contrôles d'accès de l'éditeur : c'est une question de chaîne d'approvisionnement et d'évaluation fournisseur.
Le filtrage de l'injection de prompt
La sécurité du contenu relève des garde-fous, distincts du contrôle d'identité et de périmètre. Le sujet compte, ce n'est pas celui de cette page.
Chaque exclusion a sa destination : le versant construction est le développement d'applications agentiques, les outils adoptés sans validation relèvent de la détection du Shadow AI, et le parapluie au-dessus de l'ensemble est la sécurité de l'IA avec Cloudflare.