# Authentification HTTP pour les agents IA : des modèles d'identifiants sûrs

Un agent IA doit pouvoir demander une action HTTP sans jamais détenir l'identifiant qui la rend possible. Cette règle compte davantage que le fait que la requête utilise un bearer token, l'authentification Basic ou un en-tête propre à un fournisseur. Si un secret entre dans le contexte de l'agent, il peut fuiter par un prompt, une trace d'outil, une commande shell générée, un fichier de dépôt ou un résumé ultérieur que personne ne voulait conserver.

Les schémas d'authentification HTTP restent importants, car chacun détermine ce qui peut être volé, rejoué, transmis par erreur et audité. La bonne conception commence par le schéma exigé par l'API, puis confine l'identifiant à un exécuteur de confiance qui envoie une requête précisément définie au nom de l'agent.

## Les agents transforment les identifiants ordinaires en données copiées

Un agent sans supervision change le niveau de risque d'un identifiant API pourtant normal, parce qu'il lit et écrit de nombreuses formes de texte. Un développeur peut conserver un token dans un gestionnaire d'identifiants local et le coller dans une seule requête. Un agent peut inspecter des variables d'environnement, écrire une sortie de débogage, composer une commande curl, créer des fichiers de configuration et rendre compte de son travail à une personne. Chacune de ces opérations crée un nouvel emplacement où un secret réutilisable peut se retrouver.

Le chemin dangereux semble souvent anodin au départ :

1. Un exécuteur de tâches place `PAYMENTS_TOKEN` dans l'environnement du processus de l'agent.
2. L'agent exécute une commande de diagnostic qui affiche son environnement ou écrit un script shell.
3. Le script atteint un dépôt, un artefact CI, l'historique du terminal ou un autre appel d'outil de l'agent.
4. Quelqu'un retrouve le token plus tard et envoie des requêtes valides jusqu'à son expiration ou sa révocation par un opérateur.

Le token n'avait pas besoin d'un attaquant sophistiqué. Il lui suffisait de devenir du texte dans un emplacement conçu pour copier du texte.

Ne confondez pas le contrôle d'accès de l'agent avec la confidentialité des identifiants. Une sandbox peut empêcher un agent d'ouvrir des fichiers hors d'un répertoire. Cela ne sert à rien si le secret apparaît déjà dans le contexte du modèle, les arguments d'une commande ou le résultat d'un outil. De même, une demande d'approbation qui demande si l'agent peut exécuter `curl` ne signifie pas grand-chose si l'agent peut fournir n'importe quel hôte, chemin, corps et en-tête d'autorisation hérité.

C'est pourquoi l'authentification HTTP des agents IA nécessite deux frontières distinctes. L'agent doit avoir l'autorisation de proposer une requête. Un composant de confiance doit garder l'identifiant et avoir le pouvoir d'envoyer la requête. Réunir ces deux frontières donne à l'agent un secret copiable et fait dépendre les contrôles ultérieurs de sa capacité à le manipuler parfaitement. C'est une hypothèse déraisonnable.

Un test simple peut vous aider : pourriez-vous coller la transcription complète de l'agent dans un outil de suivi sans révoquer l'identifiant ? Si la réponse est non, le secret a franchi la mauvaise frontière.

## Les bearer tokens sont simples à envoyer et faciles à rejouer

Un bearer token donne accès à quiconque le présente. Un agent ne doit donc jamais en recevoir un, sauf si vous acceptez qu'une fuite de transcription puisse devenir une fuite d'accès à l'API. La RFC 6750 définit l'utilisation d'un bearer token dans l'en-tête de requête `Authorization` :

```http
GET /v1/projects/alpha/releases HTTP/1.1
Host: api.example.test
Authorization: Bearer eyJhbGciOi...
Accept: application/json
```

Le serveur n'a pas besoin de prouver que l'expéditeur est l'agent prévu, l'utilisateur d'origine ou la machine d'origine. Il vérifie si le token présenté est valide et autorisé. Cette propriété simplifie les clients HTTP, mais elle rend aussi les tokens copiés utiles à toute personne qui les possède.

La RFC 6750 autorise l'envoi de bearer tokens dans le corps d'un formulaire sous certaines conditions et décrit l'utilisation de l'URI pour les cas anciens. Ne les placez pas dans les chaînes de requête. Les URL atteignent plus facilement que prévu l'historique des navigateurs, les journaux de proxy, les systèmes d'analyse, les en-têtes referrer, les tickets d'assistance et les journaux applicatifs. La norme elle-même avertit que le transport dans l'URI présente un risque élevé de divulgation. Il n'existe aucune bonne raison de faire d'un secret d'agent un élément d'une URL.

Les bearer tokens conviennent aux agents uniquement si la conception générale des identifiants limite les dégâts. Préférez des tokens destinés à une API précise, dotés de permissions limitées, d'une expiration courte et d'une identité distincte pour l'exécuteur. Un token API capable d'administrer tous les projets, de lire tous les dossiers clients et de ne jamais expirer est un identifiant maître de production sous un nom plus sympathique.

L'argument habituel pour remettre un bearer token à un agent est la rapidité : une variable d'environnement, un client HTTP, aucun composant supplémentaire. Cette approche séduit parce qu'elle fonctionne dans une démonstration. Elle échoue dès que l'agent doit être débogué, déléguer une action, fonctionner longtemps ou accéder à plusieurs services. Un token copié dans le contexte devient plus difficile à révoquer de manière sélective, car vous ne savez plus où il a circulé.

Il existe un autre piège : un token dont le nom semble restrictif peut tout de même disposer d'une autorité effective étendue. Consultez la documentation du fournisseur pour connaître le véritable modèle de portée. Certains services utilisent des portées propres aux points de terminaison. D'autres accordent des droits au niveau de l'organisation, du projet, du dépôt ou du compte. Certains tokens API héritent silencieusement de tous les privilèges de l'utilisateur qui les a créés. Le libellé du token ne prouve pas ses limites.

Un médiateur peut conserver le bearer token et construire l'en-tête uniquement après avoir validé la destination demandée. L'agent doit soumettre une intention et les données de la requête, par exemple « créer une release dans le projet alpha avec ce corps », plutôt que l'en-tête `Authorization` littéral. L'exécuteur ajoute le secret après validation et le supprime avant de renvoyer le moindre enregistrement à l'agent.

## L'authentification Basic nécessite une identité de service distincte

L'authentification Basic peut convenir à un compte de service limité via TLS, mais elle est mal adaptée pour fournir à un agent le nom d'utilisateur et le mot de passe d'une personne. La RFC 7617 définit le format transmis comme un encodage base64 de `user-id:password`, placé dans l'en-tête Authorization :

```http
Authorization: Basic YWdlbnQtcmVsZWFzZXI6czNjcjN0LXZhbHVl
```

Toute personne capable de lire cette valeur peut la décoder. Base64 modifie la représentation, mais ne protège pas la valeur. TLS protège la connexion entre le client et le serveur, mais pas l'identifiant après qu'un agent, un processus local, un journal de débogage ou un proxy a copié l'en-tête.

De nombreux fournisseurs d'API utilisent l'authentification Basic avec un token API comme mot de passe et un nom d'utilisateur fixe ou ignoré. Cela ne transforme pas le schéma en une version moins sûre de l'authentification bearer. Le risque de rejeu reste similaire, avec quelques risques pratiques supplémentaires. Un client ou un journal peut enregistrer le nom d'utilisateur décodé, l'en-tête brut ou les deux. Un développeur peut réutiliser un vrai mot de passe de compte parce que le protocole appelle le second champ un mot de passe. C'est précisément l'identifiant qu'il ne faut pas déléguer à un processus autonome.

Lorsque l'authentification Basic est incontournable, créez un compte dédié à l'exécuteur. Donnez-lui uniquement les permissions nécessaires à la famille de requêtes. N'utilisez pas un compte personnel, un compte administrateur ou des identifiants partagés entre des automatisations sans lien. Une identité de service permet la révocation et l'investigation sans bloquer une personne ni interrompre toutes les tâches en même temps.

Traitez l'encodage des caractères avec attention. La RFC 7617 décrit un problème de compatibilité concernant le jeu de caractères du nom d'utilisateur et du mot de passe, et permet aux serveurs d'annoncer UTF-8. Si un fournisseur ne prend en charge que des valeurs ASCII ordinaires, limitez les identifiants machine à cet ensemble. N'inventez pas une étape d'encodage maison dans un prompt d'agent : vous créeriez un nouvel endroit incohérent où un secret peut être transformé et journalisé.

L'exécuteur de requêtes doit construire lui-même l'en-tête Basic à partir de champs protégés. L'agent peut choisir une opération approuvée et fournir des paramètres non secrets. Il ne doit pas construire la valeur base64 et ne doit jamais voir un identifiant décodé dans un message d'erreur. Une erreur sûre indique que l'authentification a échoué pour la référence d'identifiant sélectionnée. Elle ne renvoie pas l'en-tête et n'indique pas à l'agent quelle partie du mot de passe correspondait.

## Les en-têtes personnalisés exigent de respecter précisément les règles du fournisseur

Un en-tête d'authentification personnalisé n'est sûr que dans la mesure où les règles de vérification de l'API sont documentées et où sa valeur est correctement manipulée. Parmi les exemples courants figurent `X-API-Key`, `Api-Key` ou un en-tête propre au fournisseur. Certains fournisseurs attendent une clé API statique. D'autres attendent une requête signée avec un horodatage, un nonce, un chemin canonique et un condensat du corps. Traiter tous les en-têtes personnalisés comme interchangeables est une manière de casser l'authentification et, pire encore, d'élargir accidentellement les endroits où un identifiant est envoyé.

Commencez par suivre exactement les spécifications du fournisseur. Les noms d'en-têtes ne tiennent pas compte de la casse en HTTP, mais leurs valeurs et les entrées de signature peuvent y être sensibles. Un schéma de signature peut exiger un ordre de canonicalisation précis, les octets exacts du corps et une fenêtre temporelle limitée. Si l'exécuteur analyse le JSON puis le sérialise à nouveau avant de signer, il peut produire un JSON apparemment valide, mais dont la séquence d'octets est différente. Le fournisseur rejette alors la requête, et les équipes réagissent souvent en désactivant les contrôles de signature ou en ajoutant une logique de nouvelle tentative trop large. Corrigez la gestion des octets à la source.

Ensuite, distinguez un en-tête servant à l'authentification d'un en-tête qui identifie un client. `User-Agent`, les identifiants de requête et les identifiants d'application peuvent aider un fournisseur à observer le trafic, mais ils ne prouvent généralement pas l'autorité. À l'inverse, un en-tête `X-API-Key` peut être tout aussi rejouable que `Authorization: Bearer`. N'évaluez pas sa sensibilité selon que son nom contient ou non le mot authorization.

Enfin, empêchez l'agent de faire passer des en-têtes en contrebande. L'agent ne doit pas recevoir une carte libre de tous les en-têtes sortants si un exécuteur protégé injecte aussi des identifiants. Une carte libre lui permet d'ajouter un second en-tête `Authorization`, de remplacer un type de contenu attendu, d'ajouter un en-tête d'identité non approuvé ou d'influencer un proxy en aval d'une manière que le réviseur n'a pas vue.

Utilisez un contrat de requête composé de champs nommés et typés. Par exemple :

```json
{
  "credential_ref": "release-service",
  "method": "POST",
  "url": "https://api.example.test/v1/projects/alpha/releases",
  "headers": {
    "accept": "application/json"
  },
  "body": {
    "version": "2025.06.0",
    "notes": "Fix parser crash on empty input"
  }
}
```

L'exécuteur, et non l'agent, associe `credential_ref` à l'en-tête personnalisé du fournisseur ou à sa procédure de signature. Il doit refuser les tentatives de fournir `authorization`, `cookie`, l'en-tête d'identifiant du fournisseur, `host` ou une variante en double de ces noms. Il doit également gérer lui-même `Content-Length`, car le client HTTP doit le calculer à partir des octets finaux.

Le résultat présenté à l'agent doit suivre la même discipline. Une réponse HTTP peut contenir `Set-Cookie`, des diagnostics ou des détails de la requête renvoyés par le serveur. Retournez le statut, les en-têtes de réponse sûrs sélectionnés et le corps nécessaire à la tâche. Conservez les en-têtes et les traces bruts dans un stockage d'audit protégé lorsqu'ils sont nécessaires aux opérateurs.

## Choisissez le schéma exigé par le fournisseur, puis limitez l'ampleur des dégâts

Vous choisissez rarement le schéma d'authentification d'une API tierce. Le fournisseur l'a déjà choisi. En revanche, vous pouvez choisir si l'identifiant est large ou limité, où il est stocké, quelles requêtes peuvent l'utiliser et ce qui se passe lorsque l'agent se comporte de façon étrange.

Utilisez cette comparaison pour concevoir la frontière :

| Schéma | Ce que le client envoie | Exposition principale en cas de copie | Manipulation adaptée pour l'agent |
|---|---|---|---|
| Bearer token | Un token dans `Authorization` | Rejeu direct par son détenteur | Le conserver dans l'exécuteur et limiter sa portée et sa durée de vie |
| Authentification Basic | Base64 du nom d'utilisateur et du mot de passe ou du token | Décodage suivi d'un rejeu direct | Utiliser une identité de service dédiée dans l'exécuteur |
| En-tête personnalisé statique | Un en-tête secret défini par le fournisseur | Généralement un rejeu direct | L'injecter uniquement pour les hôtes et chemins approuvés |
| En-tête personnalisé signé | Signature, horodatage et données de la requête | Le rejeu peut échouer, mais le matériel de signature reste sensible | Conserver le secret de signature et la canonicalisation dans l'exécuteur |

Les requêtes signées méritent une précision importante. Un horodatage et un nonce peuvent réduire les rejeux simples à la frontière de l'API, mais ils ne rendent pas le secret de signature sûr dans le contexte de l'agent. Un agent qui a accès au secret peut signer une nouvelle requête malveillante. Si l'implémentation de signature accepte librement la méthode, l'hôte, le chemin et le corps fournis par l'agent, elle signera fidèlement des actions que vous ne vouliez pas autoriser.

La portée doit correspondre à l'action, pas à un usage futur imaginé. Un agent chargé de publier des releases peut avoir besoin de créer une release dans un seul projet. Il n'a pas besoin de supprimer des projets, de modifier la facturation, de lire tous les artefacts ou d'inviter des utilisateurs. Si un fournisseur ne peut pas délivrer un identifiant suffisamment limité, placez un service plus restreint que vous contrôlez devant son API, ou conservez une approbation humaine pour les appels dangereux.

Ne compensez pas de mauvaises portées par une longue liste d'autorisation rédigée en langage naturel. « Utiliser le token uniquement pour les releases » est un conseil, pas un point d'application. Placez la restriction là où la requête est assemblée : origine attendue, méthode autorisée, modèle de chemin, ensemble d'en-têtes, schéma du corps et taille maximale de la réponse. Ces contraintes rendent un identifiant moins utile en dehors de sa tâche prévue.

## La médiation garde les secrets hors du contexte de l'agent

Les appels HTTP médiés fonctionnent lorsque le détenteur du secret exécute la requête au lieu de renvoyer le secret à l'agent pour qu'il l'exécute. La différence est facile à masquer, car les deux conceptions peuvent présenter à l'agent un outil nommé `http_request`. C'est le flux des données qui révèle la conception réellement mise en place.

Dans la conception dangereuse, l'outil obtient un token et le donne à l'agent, peut-être sous la forme d'une variable d'environnement, d'une expansion de paramètre ou d'un identifiant « temporaire ». L'action suivante de l'agent envoie la requête. Le token a déjà franchi la frontière vers un système conçu pour raisonner sur du texte, le transformer et le répéter.

Dans la conception médiée, l'agent envoie une requête structurée à un exécuteur. Celui-ci vérifie que la requête respecte la forme autorisée, récupère l'identifiant sélectionné dans un stockage protégé, injecte le matériel d'authentification correct, envoie la requête, consigne l'action et renvoie un résultat limité. L'agent ne reçoit jamais la valeur du secret, une forme encodée de celle-ci ou une commande shell qui la contient.

Cette différence modifie aussi la réponse aux incidents. Si vous pensez qu'une session d'agent a mal tourné, vous pouvez interrompre sa capacité à demander des actions sans faire immédiatement tourner tous les identifiants. Si un identifiant a pu s'échapper, vous devez tout de même le renouveler. La révocation d'une session et la rotation d'un identifiant résolvent des problèmes différents, et les équipes perdent du temps lorsqu'elles les traitent comme un seul bouton.

Un exécuteur pratique doit refuser par défaut plusieurs formes de requêtes :

- Les URL absolues qui pointent vers une origine non approuvée, y compris les sous-domaines qui lui ressemblent.
- Les requêtes contenant des en-têtes `Authorization`, `Cookie`, de proxy ou propres aux identifiants fournis par l'utilisateur.
- Les redirections susceptibles de transporter une requête authentifiée vers une autre origine.
- Les méthodes qui ne correspondent pas à l'usage prévu de l'identifiant, en particulier les méthodes destructrices.
- Les corps qui dépassent la taille attendue ou ne correspondent pas au format attendu par le point de terminaison.

Sallyport applique ce modèle de garde sur macOS : son coffre chiffré contient les identifiants API et SSH, tandis qu'un agent MCP demande à l'application d'effectuer les appels HTTP au lieu de recevoir les valeurs des identifiants.

Ne confondez pas la médiation avec un moteur de politique généraliste. Elle ne peut pas déterminer si « supprimer les ressources de test obsolètes » est approprié dans un compte de production donné. Elle peut garantir qu'une requête reste dans une frontière technique définie et que l'identifiant reste hors du contexte de l'agent. L'examen humain, les comptes limités et les garde-fous propres à l'application doivent encore déterminer si l'action mérite d'être approuvée.

## La frontière de la requête doit inclure les redirections, le DNS et les réponses

Approuver uniquement `https://api.example.test` est trop large, car une requête utilisant un identifiant contient davantage qu'un nom d'hôte. L'exécuteur doit contrôler chaque élément qu'un agent peut modifier et qui change la destination effective ou le sens de la requête.

Commencez par une origine exacte : schéma, nom d'hôte et port. Exigez HTTPS pour les identifiants d'API utilisés sur Internet. La RFC 9110 définit les règles concernant la cible et l'autorité d'une requête HTTP, mais le code applicatif doit tout de même appliquer ses propres règles de destination. N'approuvez pas les hôtes par simple suffixe. Un contrôle tel que « le nom d'hôte se termine par `example.test` » peut accepter `notexample.test` ; une recherche approximative par sous-chaîne est encore pire. Comparez les noms d'hôte analysés à une liste d'autorisation exacte ou à une règle de sous-domaine conçue intentionnellement.

Limitez ensuite les méthodes et les chemins. Si l'agent doit créer des releases, autorisez la famille précise de chemins `POST` dont il a besoin. N'ajoutez pas `DELETE` parce que cela pourrait servir au nettoyage. N'autorisez pas de chemins versionnés arbitraires sans déterminer si une version ultérieure de l'API expose un comportement différent. La normalisation des chemins compte également. Analysez l'URL avant la comparaison et refusez les encodages inattendus, les segments `.` et `..` ou les séparateurs répétés si votre code de correspondance ne les gère pas de manière prévisible.

Le comportement des redirections doit être traité explicitement. Les bibliothèques HTTP diffèrent et une mise à niveau peut modifier les valeurs par défaut. Pour les appels utilisant des identifiants, le choix le plus sûr consiste à refuser les redirections et à en signaler l'emplacement à l'agent. Si un fournisseur exige réellement une redirection, n'autorisez que la destination attendue et reconstruisez la requête avec les mêmes restrictions. Ne supposez jamais qu'un client supprime les identifiants de manière assez cohérente pour qu'une redirection ouverte soit inoffensive.

Le DNS crée une seconde vérification de destination. Un nom d'hôte de confiance peut correspondre à des adresses changeantes, et des systèmes internes peuvent pointer vers des réseaux sensibles. Si votre exécuteur fonctionne sur un ordinateur de développeur, des requêtes HTTP sortantes arbitraires peuvent devenir un chemin vers des services d'administration locaux ou des points de terminaison de métadonnées cloud. Restreignez les origines approuvées avant la connexion, n'acceptez pas les paramètres de proxy contrôlés par l'agent et ne laissez pas celui-ci sélectionner une interface réseau ou un résolveur.

Enfin, limitez et filtrez la réponse. Un agent n'a pas besoin de télécharger plusieurs mégaoctets pour savoir qu'une release a bien été créée. Les gros corps gaspillent du contexte et peuvent transporter dans le raisonnement de l'agent des instructions copiées depuis un service non fiable. Lorsque c'est possible, ne renvoyez que les champs nécessaires à l'action suivante. Marquez le texte distant comme une donnée dans le contrat de l'outil et ne laissez jamais le contenu de la réponse modifier les règles d'autorisation de l'exécuteur.

## L'approbation doit identifier le processus appelant et l'action concrète

Un clic d'approbation humaine n'a de valeur que s'il fournit suffisamment d'informations pour décider. « Autoriser l'accès de l'agent à l'API » est une permission globale déguisée en prompt. Cela favorise la lassitude face aux approbations, car la personne ne peut pas savoir quel processus local a fait la demande, quel identifiant il souhaite utiliser ni ce qu'il va envoyer.

Identifiez le processus appelant d'une manière utile à l'opérateur. Sur macOS, l'autorité de signature du code est souvent plus utile qu'un nom de processus modifiable. Un processus appelé `agent` peut être un outil de développement légitime ou un binaire sans rapport qui a choisi le même nom. La filiation du processus, le chemin de l'exécutable et les informations de signature apportent de meilleurs éléments, même si aucun ne remplace une demande d'action limitée.

L'approbation d'une session et celle d'une requête répondent à des compromis différents. L'approbation de session réduit les interruptions répétées pour une exécution d'agent connue. Elle convient aux opérations peu risquées et répétitives lorsque l'identifiant et la frontière de requête restent limités. L'approbation par requête convient aux opérations irréversibles ou sensibles, comme une publication externe, une modification des paramètres d'accès ou l'écriture de données qui déclencheront un autre système.

Évitez une conception qui demande à une personne d'examiner un dump HTTP brut et dense à chaque appel. Après la troisième interruption, les gens l'approuveront sans le lire. Présentez un résumé concis de l'action : l'identité de service, la méthode, la destination, le chemin, les champs significatifs du corps et tout effet secondaire documenté par l'API. Conservez les détails bruts de la requête dans l'enregistrement d'audit pour les investigations ultérieures.

Distinguez également l'autorisation de démarrer une session de celle de la maintenir active. Si un processus d'agent s'arrête, un processus de remplacement ne doit pas hériter de l'approbation simplement parce qu'il porte le même nom. Si un utilisateur révoque une session, l'exécuteur doit immédiatement cesser d'accepter ses appels. Une interface qui affiche « révoquée » alors qu'un client déjà autorisé continue d'envoyer des requêtes est pire que l'absence de fonction de révocation, car elle crée une fausse impression de sécurité.

## Les journaux d'audit doivent expliquer ce qui s'est passé après l'arrêt de l'agent

Une bonne piste d'audit permet à un opérateur de savoir qui a demandé un appel, quelle référence d'identifiant l'exécuteur a utilisée, où la requête est allée, ce que l'exécuteur a autorisé et ce que le service distant a renvoyé. Il n'est pas nécessaire d'enregistrer le secret brut pour répondre à ces questions. En fait, le faire créerait un second stockage de secrets déguisé en outil d'observabilité.

Pour chaque appel, conservez l'identité de la session ou du processus, l'horodatage, la référence de l'identifiant sélectionné, la méthode HTTP, l'origine approuvée, le chemin, une représentation protégée des données pertinentes de la requête, le statut de la réponse et la décision qui a permis ou refusé l'appel. Enregistrez la destination finale effective après toute redirection autorisée. Enregistrez aussi les échecs. Des tentatives refusées répétées visant un chemin inhabituel révèlent souvent une instruction d'agent défaillante ou une tentative de franchir la frontière.

La preuve d'altération change le niveau de confiance que vous pouvez accorder à l'enregistrement. Un journal chaîné par hachage relie chaque entrée aux précédentes, de sorte qu'une modification ou une suppression ultérieure devient détectable lors de la vérification. Cela ne prouve pas que l'exécuteur a pris une décision d'autorisation judicieuse et ne rend pas fiable un hôte compromis. Cela rend plus difficile la modification discrète de l'historique, ce qui est précisément ce dont l'analyse d'un incident a besoin.

Conservez l'audit séparément du contexte de travail ordinaire de l'agent. Celui-ci peut recevoir un résumé tel que `201 Created, release id r-4821`. Un opérateur peut avoir besoin d'un enregistrement plus riche comprenant le chemin et les métadonnées de décision. Aucune de ces parties ne doit recevoir l'en-tête d'autorisation brut sous prétexte qu'une journalisation existe.

Avec Sallyport, les journaux Sessions et Activité sont générés à partir d'un journal d'audit chiffré et chaîné par hachage, et `sp audit verify` peut vérifier cette chaîne hors ligne sans déverrouiller le coffre. C'est une conception pertinente pour les contrôles, car la vérification n'exige pas d'exposer les identifiants qui ont autorisé les appels.

## Testez les chemins d'échec avant d'accorder un accès à la production

Une frontière d'identifiants qui ne fonctionne que dans le scénario idéal n'a pas mérité l'accès à la production. Construisez une petite API de test ou utilisez un compte hors production, puis demandez à l'exécuteur de prouver qu'il refuse les situations susceptibles de divulguer ou d'utiliser incorrectement les identifiants.

Utilisez une séquence de test comme celle-ci :

1. Demandez un point de terminaison `GET` approuvé et vérifiez que l'agent reçoit le corps attendu, mais aucun en-tête contenant un identifiant.
2. Fournissez un en-tête `Authorization` depuis l'agent et vérifiez que l'exécuteur le refuse au lieu de fusionner ou de remplacer silencieusement les en-têtes.
3. Modifiez l'URL pour utiliser un hôte non approuvé puis une adresse presque identique et trompeuse, et vérifiez que les deux requêtes échouent avant tout appel réseau.
4. Renvoyez une réponse `302` inter-origines depuis l'API de test et vérifiez que l'exécuteur s'arrête au lieu de transmettre l'authentification.
5. Révoquez la session de l'agent pendant une exécution et vérifiez que les appels suivants échouent tandis que la vérification d'audit continue de fonctionner.

Inspectez les environnements de processus, les répertoires temporaires, l'historique du shell, les fichiers générés, les rapports de plantage et les journaux de test après l'exécution. Recherchez une chaîne d'identifiant de test connue. Cet exercice révèle un nombre étonnamment élevé de fuites dans les scripts intermédiaires et les modes de débogage que les tests au niveau des requêtes ne détectent jamais.

Testez également les erreurs du fournisseur. Une API peut renvoyer un corps qui répète le contenu d'un en-tête invalide, un identifiant de trace ou un conseil demandant de réessayer avec un autre point de terminaison. Vérifiez que votre filtre de résultats ne transmet pas de données ressemblant à un identifiant à l'agent et que la logique de nouvelle tentative ne peut pas transformer une requête refusée en une avalanche de tentatives. Limitez les nouvelles tentatives aux erreurs pour lesquelles la documentation de l'API les prévoit, et conservez la même méthode et la même destination.

Le premier identifiant de production doit être suffisamment limité pour qu'un test échoué soit gênant, pas catastrophique. Si votre équipe ne peut pas expliquer précisément quelles formes de requêtes elle autorise et comment révoquer une exécution d'agent active, l'identifiant est encore trop large pour un usage autonome.