Passer au contenu principal
Une clé est apparue dans un commit public, un log CI, une capture d’écran, ou une brèche fournisseur. Le compte à rebours tourne : quiconque détient cette chaîne sk-orca-… peut dépenser votre solde et piloter vos agents jusqu’à ce que vous la coupiez. Cette page est le runbook d’incident — coupez la credential d’abord, puis auditez ce qu’elle a fait — pour les clients gérant leurs propres clés dans la console. Les mécaniques du cycle de vie (désactiver vs. supprimer, états de clé, rôles) vivent dans Gérer les clés ; cette page est la séquence sous attaque et, surtout, ce qu’il faut vérifier dans la piste d’audit une fois l’hémorragie arrêtée.
Arrêtez la dépense avant d’enquêter. Une clé à portée limitée avec un plafond credit_limit_usd et une liste allow_ips borne les dégâts, mais une clé fuitée sans plafonds peut brûler du solde aussi longtemps qu’elle reste vivante. Révoquez d’abord ; investigation médico-légale ensuite.

​
1. Révoquer la clé API fuitée (faites ceci en premier)

Vous avez deux mouvements de coupure, tous deux dans l’écran Clés de la console (/console/token). Les deux requièrent le rôle Developer ou supérieur — l’action s’exécute sur votre session / token d’accès, jamais sur une clé de relais.

Désactiver — pause réversible

Basculez le statut de la clé sur Désactivé. Chaque requête qu’elle effectue est rejetée immédiatement, mais la clé, ses limites, ses attachements de politique et son historique d’usage restent tous intacts. Utilisez ceci quand vous avez besoin que la config et les logs soient préservés pendant que vous creusez.

Supprimer — révocation permanente

Choisissez Supprimer sur la clé. La credential ne peut plus jamais autoriser une requête et n’est pas récupérable. Utilisez ceci une fois la fuite confirmée et après avoir capturé ce dont vous avez besoin de la piste.
Un motif commun : désactivez instantanément dès l’instant où vous soupçonnez une exposition (confinement à latence nulle, rien de perdu), exécutez l’audit en §3–§4, puis supprimez une fois le rayon d’explosion scopé. Quoi que vous fassiez, émettez une nouvelle clé pour le remplacement — ne réactivez jamais une credential qui a été vue dans la nature. Le transfert sans interruption est dans Rotation des clés.
Désactiver ou supprimer prend effet à la requête suivante — il n’y a aucun redéploiement et aucun délai de propagation.

​
2. Tant que vous y êtes, resserrez le remplacement

Une fuite est le moment de corriger la portée qui l’a laissée faire mal. La clé de remplacement devrait porter l’identité la plus étroite dont la charge de travail a réellement besoin, pour que la prochaine fuite soit un non-événement :
Une allow-list d’IP signifie qu’une clé fuitée est inutile depuis toute adresse autre que la vôtre. Les requêtes depuis des IPs non listées sont rejetées à la couche d’authentification avant qu’elles ne coûtent quoi que ce soit.
Un plafond de dépense (0 = illimité) borne le pire cas. Une clé fuitée avec un plafond hebdomadaire serré ne peut pas vider le solde de votre espace de travail.
Les limites de modèles empêchent un voleur de basculer votre clé bon marché vers votre modèle le plus cher.
Une expiration (-1 = jamais) signifie qu’une clé qui échappe à votre attention cesse quand même d’autoriser d’elle-même.
Voir la Checklist de moindre agence pour la posture complète une-clé-par-agent.

​
3. Auditer les logs de requêtes — qu’a appelé la clé ?

Avec la credential coupée, scopez les dégâts. Chaque appel de relais que cette clé a fait est enregistré dans les logs de requêtes de votre espace de travail, et chaque ligne porte les champs dont vous avez besoin pour reconstruire l’incident :
ChampCe qu’il vous dit
token_name / token_idQuelle clé — confirmez que vous regardez la fuitée.
ipL’adresse source de chaque appel. Une rafale depuis une IP que vous ne reconnaissez pas est le smoking gun.
modèle + usageQuels modèles ont été touchés et ce qu’ils ont coûté — votre exposition de dépense.
Filtrez la vue de logs sur la clé fuitée et triez par temps. Deux questions répondent le plus vite au « à quel point c’est grave » :
  1. Y a-t-il du trafic depuis une IP qui n’est pas la vôtre ? C’est un usage abusif confirmé, pas une fausse alerte.
  2. La dépense ou le motif d’appels a-t-il piqué autour de la fenêtre de fuite ? Un saut soudain est l’empreinte de l’attaquant.
Si la clé portait une liste allow_ips, les appels depuis l’extérieur n’ont jamais autorisé en premier lieu — donc l’absence de lignes à IP étrangère est elle-même un bon bilan de santé. C’est exactement pourquoi épingler la source (§2) transforme une fuite en un non-événement.

​
4. Lire la piste de politique — qu’a-t-elle tenté de faire ?

Les logs de requêtes vous disent ce que la clé a appelé ; les plans de politique vous disent ce qu’elle a tenté de faire dire ou faire au modèle, et si vos guardrails et firewall l’ont attrapé. Les deux sont à portée d’espace de travail. Les correspondances de guardrail sont lisibles par tout membre de l’espace de travail ; la vue Events / Runs du firewall requiert le rôle Developer ou supérieur (les politiques et réglages firewall restent ouverts à chaque membre).

Correspondances de guardrail

Chaque fois que le trafic de la clé a heurté une règle de guardrail, un enregistrement de correspondance a atterri à GET /api/guardrail/match — portant le type de règle, l’action (block / mask / flag), le stage, et le détail fautif. Filtrez sur la fenêtre de la clé fuitée pour voir quel contenu elle a poussé (PII, secrets, tentatives de jailbreak).

Événements firewall

Chaque appel d’outil que la clé a émis est un événement firewall — allow, audit, deny, sanitize, ou held. Une série d’événements deny est un agent qui a tenté quelque chose qu’il n’avait pas le droit de faire. Agrégez-les par exécution dans la vue Events / Runs.
Quelques spécificités qu’il vaut la peine de connaître pendant que vous lisez la piste :
  • Les correspondances de guardrail journalisent la sous-chaîne correspondante seulement si « Log raw content » était activé pour ce guardrail (c’est désactivé par défaut) — donc une ligne de correspondance peut montrer la règle et l’action sans le texte brut. Le type / l’action / le stage sont toujours là.
  • mark-fp sur une correspondance (POST /api/guardrail/match/:id/mark-fp, Admin) vous permet de signaler un hit comme un faux positif pour qu’il cesse de fausser votre vue d’incident — ne l’utilisez pas pour enterrer un usage abusif réel.
  • Les denies du firewall sont pré-outil. Un événement deny signifie que l’appel d’outil de l’attaquant a été bloqué avant d’atteindre l’outil — le firewall a déjà contenu cette action. L’événement est votre preuve qu’il a essayé.
Recoupez les trois pistes sur la même fenêtre temporelle : une IP étrangère dans les logs de requêtes, un pic de correspondances de guardrail, et un cluster d’événements deny du firewall peignent ensemble le tableau complet — ce que l’attaquant avait, ce qu’il a tenté, et ce qui a été arrêté.

​
5. Après l’incident

Re-vérifiez la liste de Clés : la clé fuitée devrait afficher Disabled ou avoir entièrement disparu. Si vous l’avez seulement désactivée, planifiez la suppression une fois l’audit terminé — voir Gérer les clés.
Déplacez le trafic vers la nouvelle clé à portée plus serrée avant de retirer l’ancienne pour qu’il n’y ait jamais de fenêtre sans clé fonctionnelle. Transfert complet : Rotation des clés.
Si la clé fuitée n’avait aucun allow_ips, aucun credit_limit_usd, et des model_limits larges, c’est ça le vrai constat. Donnez à chaque agent sa propre clé à portée étroite — la Checklist de moindre agence et Portée & clés parcourent toute la posture.

​
6. Connexe

Gérer les clés

Désactiver vs. supprimer, états de clé, et les barrières de rôle derrière chaque action.

Rotation des clés

Le transfert sans interruption d’une clé compromise vers une propre.

Allow-list d'IP

Épinglez une clé à vos adresses source pour qu’une fuite ne puisse pas être utilisée ailleurs.

Exfiltration de données

La menace qu’une clé fuitée alimente le plus souvent, et comment la surface d’egress du firewall la borne.
Toute la séquence est courte à dessein : révoquer, puis auditer. Plus la portée de chaque clé est étroite au départ, plus petit est l’audit que vous avez à mener — et plus vite une credential fuitée passe d’urgence à note de bas de page.