Passerelle d'actions pour agent IA ou proxy MITM : les points de contrôle

Une passerelle d'actions pour agent IA et un proxy man-in-the-middle peuvent tous deux se placer entre un agent et un service externe. Cette ressemblance superficielle entraîne de mauvaises décisions d'architecture. Dans un cas, un modèle exécute une action authentifiée au nom de l'agent tout en conservant l'identifiant. Dans l'autre, il transmet ou intercepte un trafic que l'agent a déjà décidé de créer.

Cette différence détermine l'endroit où vous pouvez dire non, ce que l'agent peut dérober, ce que signifie une approbation et si votre audit décrit une opération volontaire ou un flux de paquets reconstitué. Si l'exigence est « l'agent ne doit jamais posséder les identifiants de production », un proxy est généralement la mauvaise frontière principale. Il peut malgré tout avoir un rôle, mais il ne peut pas réparer un secret déjà présent dans le processus client.

Une passerelle exécute des actions nommées, un proxy gère des connexions

Une passerelle d'actions pour agent IA reçoit une demande d'opération externe, sélectionne un identifiant stocké, exécute l'opération et renvoie le résultat. L'agent demande l'exécution d'un travail, mais ne reçoit ni jeton bearer, ni mot de passe, ni clé privée qui lui permettrait de recommencer ailleurs.

Un proxy direct reçoit une connexion réseau d'un client et la transmet vers une destination. Le client reste propriétaire de la requête. En HTTP classique, le proxy peut lire la méthode, l'URL, les en-têtes et le corps, puisque le client lui envoie du HTTP. En HTTPS, le cas courant est un tunnel CONNECT : le proxy établit une connexion TCP vers la cible et relaie les octets chiffrés dans les deux directions.

Un proxy MITM modifie le fonctionnement HTTPS. Il termine la connexion TLS du client, inspecte ou modifie le message HTTP déchiffré, puis crée une connexion TLS distincte vers le serveur en amont. Le client doit faire confiance à une autorité de certification contrôlée par le proxy, car celui-ci lui présente un certificat pour l'hôte de destination.

Ces modèles répondent à des questions différentes :

• Un proxy demande où le trafic peut aller et, avec l'interception, ce qu'il contient.
• Une passerelle d'actions demande si elle va effectuer une opération authentifiée précise.
• Un proxy peut ajouter ou retirer des éléments d'une requête appartenant au client.
• Une passerelle peut conserver l'identifiant et construire elle-même la requête authentifiée.

Ce dernier point n'est pas une question de formulation. Il détermine si un agent compromis peut emporter un identifiant et appeler le service depuis une autre machine, à un autre moment et par un autre chemin.

Prenons le cas d'un agent chargé de créer un déploiement. Dans une architecture avec proxy, l'agent prépare généralement POST /deployments, choisit le corps JSON et envoie la requête. Le proxy peut l'autoriser, la refuser, l'enregistrer ou injecter un en-tête Authorization. Dans une architecture avec exécuteur, l'agent appelle une action comme create_deployment avec des arguments. La passerelle résout la destination et le secret configurés, effectue l'appel HTTP et renvoie le statut ainsi que le corps de réponse que l'action l'autorise à retourner.

L'exécuteur doit toutefois être conçu avec soin. Une action générique mal définie comme « envoyer une requête HTTP arbitraire » peut recréer une grande partie du modèle du proxy. La frontière des identifiants reste néanmoins différente : la passerelle possède l'identifiant, l'agent ne l'a pas.

TLS transforme l'inspection en problème d'autorité de certification

Le trafic HTTPS n'est pas visible par un simple proxy direct parce qu'il passe par lui. Cette erreur est assez fréquente pour que des équipes construisent des contrôles sur une hypothèse qui échoue dès qu'un client utilise CONNECT.

La RFC 9110 décrit CONNECT comme une demande d'établissement d'un tunnel vers un hôte et un port cibles. Une fois le tunnel établi, le proxy relaie les octets. La négociation TLS se déroule à l'intérieur du tunnel entre le client et le serveur d'origine. Un proxy peut enregistrer l'hôte cible, le port, les horaires, le volume d'octets et le résultat de la connexion, mais il ne peut pas lire POST /v1/... ni une clé API placée dans un en-tête chiffré.

Pour inspecter HTTPS, un proxy d'interception doit devenir le point d'arrivée TLS du client. TLS 1.3, défini dans la RFC 8446, exige que le client valide la chaîne de certificats et le nom d'hôte. Un proxy ne peut satisfaire cette validation que si le client fait confiance à une autorité de certification capable d'émettre des certificats pour les sites interceptés.

Cette exigence entraîne un véritable travail opérationnel :

1. Installer et protéger une autorité de certification privée sur chaque machine ou environnement d'exécution utilisé par un agent.
2. Faire en sorte que les environnements d'exécution des langages, gestionnaires de paquets, outils en ligne de commande, conteneurs et clients intégrés lui fassent confiance.
3. Gérer les clients qui épinglent des certificats publics ou utilisent leur propre magasin de certificats.
4. Protéger les corps de requête et les identifiants déchiffrés après leur réception par le proxy.
5. Expliquer pourquoi un processus conçu pour refuser les émetteurs de certificats inconnus fait désormais confiance à votre autorité d'interception.

Cela peut convenir dans un environnement d'entreprise administré. Ce n'est pas un simple détail d'implémentation. Un proxy qui déchiffre tout le trafic d'un agent devient le détenteur très convoité de chaque secret, corps de requête et réponse qui le traverse.

Un exécuteur qui détient les identifiants n'a pas besoin d'usurper le certificat de chaque destination pour observer une opération. Il agit comme client HTTP de l'opération dont il a la charge. Il crée une connexion TLS normale vers la destination, valide le certificat public de celle-ci comme doit le faire tout client, puis ajoute l'identifiant stocké au moment de l'exécution.

Cela ne supprime pas les questions liées à TLS. La passerelle doit valider correctement les certificats et protéger son magasin de secrets. En revanche, elle n'a pas besoin de distribuer une autorité d'interception privée au processus de l'agent uniquement pour obtenir de la visibilité sur une action.

Un test simple est utile : si votre document d'architecture indique que le proxy inspectera les requêtes HTTPS, demandez où le client fait confiance à l'autorité d'interception. Si personne ne peut répondre clairement, le proxy ne verra que des tunnels, ou le système échouera lorsqu'un outil validera correctement les certificats.

La détention des identifiants modifie les dommages qu'un agent compromis peut causer

La véritable frontière de sécurité n'est pas « l'agent a envoyé une requête réseau par notre intermédiaire ». La question est de savoir si l'agent peut obtenir une autorité réutilisable.

Les jetons bearer le montrent clairement. Un serveur API accepte généralement un jeton bearer provenant de tout processus capable de l'atteindre. Si un agent reçoit cette chaîne, il peut l'écrire dans un fichier, la placer dans la sortie d'un outil, la transmettre à un autre point de terminaison ou l'utiliser après la fin de la session d'approbation. Masquer les journaux après coup ne sert à rien. L'identifiant a déjà quitté la frontière prévue.

Un proxy peut réduire l'exposition s'il injecte lui-même le jeton. Mais cette architecture mérite toujours un examen attentif. L'agent contrôle la requête qui atteint le proxy. À moins que celui-ci comprenne la sémantique de l'API et l'applique de manière fiable, l'agent peut utiliser le jeton injecté pour tout point de terminaison, toute méthode ou tout contenu autorisé par ce jeton.

Par exemple, une règle de proxy disant « injecter ce jeton pour api.example.internal » donne au processus demandeur l'autorité effective du jeton sur tout cet hôte. L'agent ne voit jamais la chaîne du jeton, mais il peut demander au proxy d'effectuer des appels destructeurs. Cela peut convenir à un compte de service strictement limité. Ce n'est pas le même contrôle que d'autoriser une action de déploiement nommée tout en refusant les points de terminaison administratifs sans rapport.

Une passerelle d'actions peut associer un identifiant au chemin d'action qui l'utilise. L'agent fournit des arguments, pas du matériel d'autorisation. La passerelle peut montrer à une personne l'identité de l'identifiant et l'opération prévue avant de créer la requête réseau. Elle peut aussi refuser une requête qui ne correspond pas au canal configuré sans tenter de connexion.

La distinction essentielle oppose la non-divulgation du secret au confinement de l'autorité.

La non-divulgation signifie que l'agent ne voit jamais les identifiants bruts. Un proxy qui injecte des en-têtes peut fournir cette propriété.

Le confinement de l'autorité signifie que l'agent ne peut pas transformer une intégration autorisée en transport authentifié à usage général. Cela demande des définitions d'actions, une gestion des destinations, une validation des arguments et des contrôles appliqués avant l'effet de bord. Un proxy générique ne fournit pas automatiquement ces garanties.

SSH rend le problème encore plus évident. L'authentification par clé publique SSH prouve qu'un client possède la clé privée pendant l'échange de protocole. Si l'agent possède cette clé privée, il peut s'authentifier partout où elle est acceptée. Si l'agent ne dispose que d'une commande SSH acheminée par une passerelle, la passerelle ou son assistant doit effectuer l'authentification sans exporter la clé.

La RFC 4253 décrit le protocole de transport SSH et l'architecture d'authentification qui l'accompagne. La conséquence pratique est simple : il est impossible d'« injecter une clé privée SSH dans un en-tête » d'une requête client. Soit le processus détient le pouvoir de signature, soit un autre processus effectue la connexion authentifiée pour lui.

L'autorisation doit intervenir avant l'effet de bord externe

Un point de contrôle n'a de valeur que s'il agit avant l'événement que vous voulez contrôler. Enregistrer une requête après son acceptation par le serveur en amont vous donne une preuve. Cela ne vous donne pas de droit de veto.

Les proxys MITM proposent souvent des systèmes de règles et d'approbation fondés sur les attributs de la requête : hôte, URL, méthode, en-têtes, corps, identité du client ou catégorie de destination. Ces contrôles peuvent être solides lorsque le proxy voit le trafic déchiffré et comprend le protocole de l'application. Ils deviennent aussi un problème de règles. Quelqu'un doit décider si /projects/123/members est sans danger, si un contenu JSON transforme une simple mise à jour en attribution de privilèges et si une requête encodée contourne une comparaison de chaînes.

J'ai vu des équipes commencer avec trois règles de proxy et finir par maintenir un langage non documenté d'exceptions. Le problème n'est pas que les règles soient mauvaises par nature. C'est de prétendre que le format arbitraire des requêtes d'un agent offre une surface de politique stable et peu ambiguë.

Une passerelle d'actions peut utiliser un vocabulaire plus restreint. La décision d'autorisation peut porter sur le processus appelant, l'identifiant configuré, l'action demandée et les arguments fournis. Une personne n'a pas besoin d'examiner une commande curl opaque pour deviner quel secret stocké sera attaché en aval.

Sallyport suit cette voie avec une échelle de décision fixe plutôt qu'un langage de règles. Son coffre verrouillé refuse toute action. Par défaut, un nouveau processus d'agent doit obtenir une autorisation de session, qui identifie l'autorité de signature du code du processus. Certains identifiants peuvent aussi exiger une approbation à chaque utilisation. Ces contrôles sont volontairement grossiers, mais ils interviennent avant que l'application n'effectue l'action HTTP ou SSH.

Cette approche a une limite qu'il faut reconnaître : un modèle d'approbation fixe ne peut pas exprimer toutes les règles conditionnelles d'une organisation. Si vous avez besoin d'une règle comme « autoriser les écritures uniquement pendant une fenêtre de maintenance lorsqu'un champ de ticket possède une valeur donnée », il vous faut un système capable d'évaluer et de maintenir cette règle. Ne présentez pas une simple passerelle d'actions comme un moteur de règles généraliste.

L'avantage d'un ensemble de contrôles réduit est que l'opérateur peut le prévoir. Le coffre est verrouillé ou déverrouillé. Une exécution de processus est approuvée ou non. Un identifiant demande une approbation à chaque utilisation ou n'en demande pas. En pratique, les contrôles de sécurité échouent lorsque personne ne peut expliquer pourquoi un appel est passé.

La visibilité des requêtes et l'autorité sur les actions sont deux propriétés distinctes

Les équipes demandent souvent une « visibilité complète » alors qu'elles ont en réalité besoin de deux choses différentes : savoir quel agent a lancé le travail et disposer d'un enregistrement de chaque action externe. La visibilité au niveau des paquets peut aider au débogage, mais elle remplace mal un enregistrement d'action.

Un journal de proxy peut contenir l'adresse source, la destination, les détails TLS, les champs HTTP si l'interception a réussi et les octets bruts. C'est un matériau d'analyse utile. Il crée aussi un problème d'identité complexe. Une connexion ne permet de savoir quel processus s'est connecté que si l'environnement fournit et conserve cette identité. Une requête indique ce qui est arrivé au proxy, pas nécessairement l'instruction du modèle ou la session d'agent qui l'a provoquée.

Une passerelle d'actions commence par la frontière de l'opération. Elle peut enregistrer l'exécution de l'agent qui a demandé l'opération et l'appel individuel qu'elle a exécuté. Ces enregistrements répondent à des questions différentes :

• Quel processus d'agent autorisé avait une session active ?
• Quelle action externe cette session a-t-elle demandée ?
• Quel identifiant ou canal l'exécuteur a-t-il utilisé ?
• Quel résultat a été renvoyé, ou pourquoi l'appel a-t-il échoué ?

Ne confondez pas piste d'audit et système de contrôle d'accès. Un journal détaillé n'empêchera pas un agent de supprimer des données si vous lui avez accordé cette action. Il peut rendre les modifications ultérieures détectables et réduire la dépendance à la base de données du service lors de l'analyse d'un incident.

Sallyport construit ses journaux Sessions et Activity à partir d'un journal d'audit chiffré et chaîné par hachage. La commande sp audit verify vérifie cette chaîne hors ligne sur le texte chiffré et n'a pas besoin d'une clé de coffre. Cette conception sépare la vérification de la capacité à déchiffrer les secrets, ce qui convient à un enquêteur qui doit valider l'historique sans obtenir l'accès aux identifiants.

Une procédure de vérification concrète doit produire un résultat reconnaissable. Par exemple :

$ sp audit verify
Verifying audit chain...
Entries checked: 184
Chain status: valid

Le nombre exact variera. L'important est qu'un enregistrement modifié, manquant ou réordonné fasse échouer la vérification au lieu de produire discrètement un historique plus court. Si vous devez vous protéger contre une suppression totale, conservez une copie des données d'audit chiffrées en dehors de la machine qui les a produites. Une chaîne de hachage détecte les altérations des enregistrements conservés ; elle ne peut pas prouver l'existence de fichiers qu'un attaquant a détruits avec la machine.

HTTP et SSH exposent des limites de médiation différentes

HTTP semble simple parce qu'il possède des en-têtes, des URL et des verbes. Cette apparence peut inciter les équipes à traiter chaque intégration comme un problème d'injection d'en-tête.

Pour une API HTTP utilisant des jetons bearer, l'exécuteur peut conserver un enregistrement indiquant comment s'authentifier et où l'identifiant s'applique. Lorsqu'un agent demande une opération, l'exécuteur ajoute lui-même l'en-tête bearer. Pour un schéma à en-tête personnalisé, il ajoute l'en-tête configuré sans en renvoyer la valeur à l'agent. L'authentification basic suit la même règle de détention, même si l'exécuteur doit traiter le nom d'utilisateur et le mot de passe comme des secrets plutôt que comme du simple texte de configuration.

L'élément important est la séparation des entrées. L'agent peut fournir des données de requête comme celles-ci :

{
  "method": "POST",
  "path": "/repos/acme/widget/deployments",
  "body": {
    "environment": "staging",
    "revision": "7d3c1a"
  }
}

L'agent ne devrait pas fournir ceci :

{
  "authorization": "Bearer token-value-goes-here"
}

Cette séparation évite un échec courant : le schéma d'un outil expose un champ secret, le modèle y place une valeur, puis cette valeur apparaît dans les traces, le défilement du terminal, les jeux de test ou le texte copié d'une conversation. Traiter un jeton comme un argument d'outil est une erreur de conception, même si l'interface le masque après l'appel.

La médiation HTTP a elle aussi besoin de frontières. Si la passerelle accepte des URL arbitraires, l'agent peut cibler des services internes, des points de terminaison de métadonnées cloud ou des hôtes sans rapport par un chemin doté d'identifiants. Si elle accepte des en-têtes arbitraires, l'agent peut tenter une désynchronisation de requêtes ou modifier la logique d'authentification. Si elle accepte des corps arbitraires, la passerelle doit admettre que l'API devient elle-même le langage de la politique.

SSH présente d'autres limites. Une action peut devoir exécuter une commande distante, copier un fichier ou interroger un hôte. La passerelle a besoin d'une destination et d'une clé privée qu'elle conserve. Un assistant sans état peut créer la connexion SSH et renvoyer la sortie standard, la sortie d'erreur et le code de sortie sans placer la clé dans l'environnement de l'agent.

La frontière des commandes compte. Une demande telle que :

host: build-host
command: git rev-parse HEAD

offre une surface d'examen plus étroite qu'un agent exécutant un shell local ayant accès à ~/.ssh, à des paramètres de proxy arbitraires et à une ligne de commande sans restriction. Il s'agit tout de même d'une commande distante authentifiée. Si l'identifiant peut exécuter rm -rf à distance, la passerelle ne la rendra pas sûre en modifiant le transport. Limitez les permissions du compte distant et choisissez des identifiants adaptés aux tâches réellement effectuées.

Un proxy peut transporter SSH dans un tunnel TCP, mais il ne peut pas inspecter la commande SSH en se contentant d'acheminer le port 22. Pour inspecter le contenu du protocole SSH, il devrait agir comme point d'arrivée SSH et établir une autre connexion SSH vers l'amont, avec toutes les obligations de confiance envers l'hôte, d'authentification, d'enregistrement et de compatibilité que cela implique. Appeler cela un proxy ne réduit pas le travail d'ingénierie.

Un proxy reste utile lorsqu'il contrôle la bonne couche

L'argument contre l'utilisation d'un proxy MITM comme passerelle d'actions pour agent n'est pas un argument contre les proxys. Les proxys résolvent efficacement plusieurs problèmes lorsqu'ils opèrent à la couche dont vous avez réellement besoin.

Utilisez un proxy direct ou une passerelle de sortie lorsque vous devez limiter les réseaux ou noms d'hôte accessibles à un environnement d'exécution, imposer un chemin connu, contrôler les accès sortants d'outils ordinaires ou recueillir des métadonnées de connexion. Ces contrôles peuvent empêcher un agent d'appeler un hôte non approuvé, même s'il ne comprend pas votre modèle d'actions.

Utilisez un proxy MITM lorsque vous contrôlez les clients, pouvez gérer une autorité de confiance, devez diagnostiquer ou imposer un comportement à de nombreux clients HTTP classiques et acceptez la responsabilité du trafic déchiffré. Les environnements de test de sécurité et les flottes d'appareils administrés remplissent souvent ces conditions.

Utilisez une passerelle d'actions lorsque l'exigence concerne l'identité et l'autorité d'un agent autonome : l'agent doit demander une action externe, ne doit pas détenir l'identifiant et doit laisser une trace vérifiable de l'action effectuée par un exécuteur.

De nombreux déploiements sérieux combinent ces approches. L'environnement d'exécution de l'agent reçoit un accès sortant limité et ne peut donc pas effectuer d'appels directs arbitraires. La passerelle d'actions reçoit l'accès réseau restreint nécessaire pour atteindre les services externes approuvés. Elle détient les identifiants et gère les approbations. La couche réseau bloque les chemins de sortie.

Ne placez pas tous les contrôles dans le proxy simplement parce qu'il se trouve déjà sur le chemin réseau. Ce choix force souvent l'autorisation au niveau de l'application dans des motifs d'URL et confie la gestion des secrets à un service d'interception conçu pour relayer le trafic. Il est populaire parce que les schémas de déploiement paraissent nets. La frontière opérationnelle, elle, se dégrade.

Une architecture de proxy plausible échoue au moment du transfert

Prenons un agent de programmation exécuté dans un environnement de développement. Il doit interroger un outil de suivi des tickets, créer un déploiement et examiner un hôte de compilation via SSH. Une équipe installe un proxy HTTPS et configure des variables d'environnement comme celles-ci :

HTTPS_PROXY=http://proxy.internal:8080
HTTP_PROXY=http://proxy.internal:8080

Le proxy injecte un jeton API pour l'outil de suivi. L'équipe considère le jeton comme protégé puisque l'agent ne le lit jamais dans un fichier de configuration.

L'agent envoie alors une requête vers un point de terminaison administratif du même hôte. Le proxy voit un nom d'hôte autorisé et injecte le même jeton. Si la règle ne comprend pas la sémantique des points de terminaison, elle vient de donner à l'agent toute l'autorité du jeton par une interface indirecte.

L'équipe tente de corriger le problème avec des listes blanches de chemins. Elle doit bientôt ajouter des exceptions pour la pagination, les points de terminaison de téléversement de pièces jointes, les redirections, d'autres versions de l'API et un flux comprenant une écriture suivie d'une lecture. Le proxy transporte maintenant une politique applicative qui change chaque fois que l'API du service évolue.

Pendant ce temps, un outil n'utilise pas HTTPS_PROXY. Un autre emploie un magasin de certificats privé et échoue lors de l'interception TLS. Un troisième est un conteneur avec un autre ensemble d'autorités de certification. Quelqu'un ajoute une exception pour que le travail continue. Cette exception crée exactement le chemin qu'un agent manipulé par une injection de prompt ou une dépendance compromise choisira plus tard.

SSH arrive en dernier et révèle le décalage. Le proxy ne peut pas injecter la clé privée SSH dans un tunnel. L'équipe monte temporairement la clé dans l'environnement de l'agent ou lance un processus d'agent pouvant accéder à un agent SSH local. À ce stade, le système a perdu la propriété qu'il cherchait à préserver.

Une architecture d'exécution d'actions modifie ce transfert. L'agent appelle un outil MCP par une connexion locale stdio. L'exécuteur détient l'identifiant API ou la clé SSH, établit la connexion externe et renvoie le résultat. MCP transporte la demande de l'outil ; il n'accorde pas à l'agent un accès libre aux secrets. La spécification Model Context Protocol définit la frontière d'interaction avec l'outil, mais la détention des identifiants reste de la responsabilité de l'implémentation.

Cette architecture ne supprime pas les injections de prompt. Une instruction malveillante peut toujours convaincre un agent de demander une action dangereuse qu'il est autorisé à demander. Elle limite le problème à l'autorité exposée par la passerelle, fournit à l'opérateur un point d'approbation ou de refus et évite que chaque appel d'outil réussi devienne une occasion d'exfiltrer un secret réutilisable.

Choisissez l'architecture en fonction de l'autorité que vous refusez de céder

Commencez par la phrase que vous devez rendre vraie. Si elle est « le processus ne peut atteindre que des destinations approuvées », placez un contrôle réseau sur le chemin. Si elle est « le processus ne doit jamais posséder cette clé API ou cette clé privée SSH », faites exécuter l'action authentifiée par un autre processus. Si elle est « une personne doit approuver chaque utilisation de cet identifiant », vérifiez que l'approbation intervient avant que l'exécuteur n'appelle le service distant.

Testez ensuite cette affirmation contre les contournements. L'agent peut-il lire une variable d'environnement contenant un jeton ? Peut-il accéder à un fichier d'identifiants, à un agent SSH local, à une session de navigateur, à un service de métadonnées cloud ou à un réseau sortant sans restriction ? Peut-il demander à un outil HTTP générique d'appeler un autre chemin avec le même identifiant injecté ? Une interception TLS défaillante pousse-t-elle un opérateur à désactiver la validation des certificats ou à créer un chemin direct ?

Un examen rapide et utile comporte quatre questions :

1. Quel processus détient chaque secret en mémoire ?
2. Quel processus crée la connexion authentifiée ?
3. Où une personne peut-elle refuser l'appel avant que le service distant ne le voie ?
4. Quel enregistrement relie une exécution donnée de l'agent à l'opération terminée ?

Si la réponse aux deux premières questions est « l'agent », aucune règle de proxy ne change le risque fondamental. Si la réponse est « le proxy », demandez-vous si vous êtes prêt à exploiter une interception TLS et une politique applicative. Si la réponse est « un exécuteur qui détient les identifiants », vérifiez qu'il offre une surface d'actions étroite et que l'agent ne peut pas le contourner.

Sallyport est conçu pour cette dernière architecture sur macOS : son interface sp mcp permet aux agents compatibles MCP de demander des actions HTTP et SSH tandis que l'application conserve les secrets et exécute ces actions. Ce n'est pas un proxy MITM et il ne faut pas le présenter comme tel.

La première tâche d'implémentation est généralement peu spectaculaire : retirer les identifiants directs de l'environnement d'exécution de l'agent. Tant que ce n'est pas fait, les approbations et les journaux de trafic ne sont que des garde-fous autour d'un processus qui transporte encore les clés.