Passer au contenu principal
Une credential que vous pouvez lire sur un écran est une credential que vous pouvez fuiter. Une fois que vous avez copié une nouvelle clé, vous n’avez presque jamais besoin de son plaintext à nouveau — vous avez besoin de la reconnaître : quelle clé est-ce, dans quel environnement, est-ce celle qu’utilise l’agent défaillant. La console d’OrcaRouter répond à cela sans jamais ré-imprimer un secret fonctionnel : chaque clé est rendue sous une forme masquée qui garde juste assez de caractères pour l’identifier et cache le reste. Cette page couvre à quoi ressemble la forme masquée, quand le plaintext est et n’est pas montré, et comment masquer en toute sécurité les valeurs de clé API dans vos propres logs et outils.

​
1. Pourquoi masquer les valeurs de clé API à l’affichage

La clé complète est une credential au porteur : quiconque la lit peut appeler la passerelle en votre nom, jusqu’aux limites de cette clé. Les vues de console sont copiées dans des captures d’écran, des partages d’écran, des tickets de support et des rapports de bug en permanence — alors montrer le secret vivant dans une liste de clés transformerait chacune de ces choses en une fuite de credential. Le masquage résout cela en séparant deux besoins qui sont habituellement confondus :
  • Identification — quelle clé est-ce ? Répondu par une empreinte masquée et stable que vous pouvez lire d’un coup d’œil.
  • Usage — quel est le secret ? Répondu exactement une fois à la création, et derrière une révélation délibérée gardée par rôle ensuite.
La console satisfait le premier besoin partout et garde le second, de sorte que la surface par défaut — la liste de clés que vous fixez toute la journée — ne porte jamais un secret utilisable.
Une clé masquée n’est pas une credential fonctionnelle. Elle ne peut pas authentifier une requête. Seul le plaintext complet (sk-orca-…) que vous avez copié à la création, ou re-révélé via l’endpoint gardé, peut appeler la passerelle.

​
2. À quoi ressemble la forme masquée

La console montre le préfixe de marque de la clé, puis une série fixe d’astérisques, puis les quatre derniers caractères — assez pour distinguer deux clés, pas assez pour reconstruire l’une ou l’autre.
Vous avez crééLa console montre
sk-orca-9f3aK2…long…7Qm4sk-orca-9f3****7Qm4
Le premier segment garde le préfixe sk-orca- et quelques caractères de tête ; les quatre derniers caractères sont la queue que vous reconnaîtrez en recoupant une ligne de log ou une erreur. Tout ce qui se trouve entre les deux est réduit à un masque fixe — la série d’astérisques est une constante, donc sa largeur ne révèle jamais la vraie longueur de la clé.
Associez la queue masquée à l’étiquette environment et au nom de la clé lorsque vous devez trouver vite une clé spécifique — la queue de quatre caractères plus un tag prod / staging suffit presque toujours à choisir la bonne dans une liste sans jamais révéler le plaintext.

​
3. Quand le plaintext est montré — et quand il ne l’est pas

Il y a exactement un moment où la clé complète est à vous pour la copier, et un seul chemin gardé pour la récupérer à nouveau.
Lorsque vous frappez une clé, la console affiche le plaintext sk-orca-… complet une fois. Copiez-le alors dans votre gestionnaire de secrets. Chaque vue ultérieure de cette clé — la liste, le panneau de détail, les résultats de recherche — ne montre que la forme masquée.
Vous pouvez re-révéler le plaintext d’une clé ordinaire à la demande, mais c’est une action délibérée derrière le rôle Developer+ — pas quelque chose que la liste par défaut expose jamais. Re-révéler une clé à portée de passerelle (is_firewall_gateway) requiert le rôle Admin (ou Owner), parce que ce token peut lire les credentials des serveurs MCP enregistrés.
Lister les clés, ouvrir le détail d’une clé, rechercher, et chaque lecture de l’objet token renvoient la forme masquée. Le plaintext n’est jamais inclus dans une réponse de liste ou de recherche.
Parce que la re-révélation est gardée et qu’une clé à portée de passerelle a besoin d’Admin pour être lue à nouveau, traitez la copie au moment de la création comme votre unique capture fiable. Sauvegardez-la dans votre gestionnaire de secrets immédiatement. Si vous perdez le plaintext d’une clé ordinaire vous pouvez le re-révéler (Developer+) ; si vous ne pouvez pas le révéler et ne pouvez pas le récupérer, faites la rotation vers une nouvelle clé plutôt que de contourner une clé que vous ne pouvez plus lire.

​
4. Un exemple concret : identifier la clé fuitée

Disons qu’une alerte se déclenche — une clé fait des appels depuis une IP inattendue — et que la ligne de log porte la queue masquée …7Qm4. Vous n’avez pas besoin du plaintext pour agir :
  1. Ouvrez la liste Clés de la console (/console/token). Chaque ligne montre son empreinte masquée — sk-orca-9f3****7Qm4 et son étiquette environment.
  2. Faites correspondre la queue …7Qm4 (et le tag prod) à la ligne fautive. La forme masquée est précisément l’identifiant dont vous avez besoin ici — aucun secret n’est exposé dans la liste, l’alerte, ou votre capture d’écran de celle-ci.
  3. Désactivez cette clé pour la mettre en pause, ou supprimez-la pour la révoquer pour de bon — les deux sont des actions sûres pour le masquage qui n’impriment jamais le plaintext. Voir Gérer les clés et Réponse à une clé fuitée.
Tout le triage tourne sur l’empreinte masquée. Le plaintext reste dans votre gestionnaire de secrets où il appartient.

​
5. Masquer dans vos propres logs et outils

La passerelle masque ses propres surfaces ; vous contrôlez votre côté. Le même principe s’applique partout où une clé pourrait atterrir dans votre stack :
  • Ne journalisez jamais l’en-tête Authorization ni la valeur sk-orca-… brute. Si vous devez enregistrer quelle clé a fait un appel, journalisez la même forme que la console utilise — le préfixe et les quatre derniers caractères — pas le secret complet.
  • Stockez le plaintext uniquement dans un gestionnaire de secrets, jamais dans le contrôle de version, les logs CI, ou un fichier de config commité dans un dépôt. La clé est masquée dans la console précisément pour que vos propres systèmes soient le seul endroit où le secret vivant réside.
  • Scopez les clés étroitement pour que même une credential fuitée ait un rayon d’explosion borné — un modèle, une plage d’IP, un plafond de dépense. Voir la Checklist de moindre agence.
Le masquage réduit l’exposition à l’affichage ; il ne réduit pas le pouvoir d’une clé qui fuite vraiment. Une empreinte masquée dans un log est sûre, mais la clé vivante dans un gestionnaire de secrets s’authentifie quand même pleinement — c’est pourquoi une portée étroite et une rotation rapide comptent tout autant que le masquage.

​
6. Comment cela s’inscrit dans le reste de l’hygiène des clés

Le masquage est une couche d’une posture de défense en profondeur pour les credentials :

Gérer les clés

Créer, désactiver et révoquer des clés — le cycle de vie derrière chaque ligne masquée de la liste.

L'objet token

Chaque champ qu’une clé porte, y compris les limites qui bornent le rayon d’explosion d’une clé fuitée.

Rotation des clés

Le transfert sans interruption vers une nouvelle clé quand vous ne pouvez pas récupérer ni faire confiance à une ancienne.

Réponse à une clé fuitée

Que faire dès l’instant où vous soupçonnez une credential exposée.
Pour la vue d’ensemble de la façon dont les clés, politiques et espaces de travail s’imbriquent pour donner à chaque agent l’identité la plus étroite, voir Portée & clés. La règle est simple : la console vous montre assez pour reconnaître une clé et jamais assez pour en fuiter une. Gardez le plaintext dans votre gestionnaire de secrets, appuyez-vous sur l’empreinte masquée partout ailleurs, et faites la rotation dès l’instant où l’identité d’une clé est mise en doute.