Arrêtez une clé d'IA divulguée avant qu'elle ne dépense.

Créez une clé de remplacement chez le fournisseur, supprimez-y la clé divulguée, déployez la clé de remplacement, puis examinez chez le fournisseur l'usage de l'ancienne clé pendant toute la période où elle a pu être utilisée. Supprimer la clé chez le fournisseur est ce qui l'arrête ; rien de ce que fait une application ou une passerelle ne peut rappeler une clé volée. Donnez ensuite à la clé de remplacement une limite de dépenses chez le fournisseur et gardez-la hors du code, des applications clientes et des environnements partagés.

Vos applications détiennent des clés de passerelle INFRO au lieu de vos clés de fournisseur. Chaque clé de passerelle peut être désactivée (403 key_disabled), limitée à 32 réseaux au plus (403 ip_not_allowed), restreinte à des modèles et fournisseurs approuvés, et dotée d'une limite de dépenses quotidienne, hebdomadaire, mensuelle ou à vie (402 key_budget). Chaque vérification s'exécute avant l'appel à votre fournisseur, sur toutes les offres, et aucune ne demande de déploiement. Une clé de passerelle divulguée est un problème borné que vous pouvez désactiver ; une clé de fournisseur divulguée atteint tout le compte fournisseur.

Oui. Les budgets s'appliquent par organisation (un objectif mensuel qui alerte et un plafond strict qui alerte ou bloque), par projet et par membre (mensuel), et par clé de passerelle (quotidien, hebdomadaire, mensuel, ou une limite à vie qui ne se réinitialise jamais). À partir de l'offre Team, les plafonds par client final limitent chacun de vos propres clients par jour, par semaine ou par mois, avec des exceptions pour des clients précis. Chaque plafond applicable est vérifié avant l'appel à votre fournisseur, en comptant le pire cas des requêtes déjà en cours, et une requête refusée est un 402 qui nomme le plafond. Les plafonds comptent l'estimation d'INFRO du coût fournisseur, pas la facture de votre fournisseur : gardez donc aussi une limite de dépenses chez le fournisseur.

Oui : vous connectez une fois vos propres clés de fournisseur et INFRO les utilise pour servir vos requêtes. Chacune est chiffrée en AES-256-GCM avec une clé détenue comme secret du Worker hors de la base de données, l'organisation et la connexion y étant liées : une copie de la base seule n'ouvre rien. Aucun écran de console, endpoint ou export ne renvoie un identifiant enregistré ; la console en montre les quatre derniers caractères. Les clés de passerelle ne sont stockées que sous forme de condensat SHA-256.

Oui. INFRO ne gouverne que le trafic qui passe par lui. Une clé de fournisseur prise n'importe où, y compris dans INFRO, peut être utilisée directement auprès du fournisseur, en dehors de toutes les limites d'INFRO. Connectez des clés limitées à leur propre projet ou espace de travail, avec une limite de dépenses définie chez le fournisseur : cette limite tient même si nous échouons. Avec l'offre Business, le rapprochement avec l'accès à l'usage activé signale l'usage d'une clé connectée qui n'est pas passé par INFRO.

OpenCode a déclaré le 17 octobre 2026 qu'une violation liée à une attaque de distillation à grande échelle avait touché 1,4 % de ses utilisateurs de Console, ceux ayant des fournisseurs d'IA externes liés, et que des clés de fournisseur enregistrées dans un espace de travail avaient pu être exposées. Railway a déclaré le 21 octobre 2026 qu'une partie non autorisée avait pu accéder à des variables d'environnement chiffrées de clients et en déchiffrer certaines, lors d'attaques visant à compromettre des fournisseurs d'inférence d'IA. Dans les deux cas, le conseil est le même : remplacer la clé, supprimer l'ancienne chez le fournisseur et examiner son usage. INFRO propose une analyse de chacune, rédigée uniquement à partir des déclarations des entreprises elles-mêmes.

Avec l'offre Business, les garde-fous vérifient les prompts et les réponses pour les formats OpenAI, Anthropic, Clé API Google, ID de clé d'accès AWS, Jeton GitHub, Jeton Slack, Clé Stripe live et Clé INFRO, les JWT et les clés privées PEM, et bloquent la requête, remplacent l'occurrence par [SECRET] ou la signalent avant que votre fournisseur ne la voie. La détection fonctionne par motifs : elle manque les formats qu'elle ne connaît pas, comme les clés d'accès secrètes AWS et les mots de passe.

Pas via INFRO. Ils appellent /v1/messages et /v1/responses d'INFRO avec une clé de passerelle : chaque développeur ou agent peut ainsi avoir sa propre clé avec une limite de dépenses, une expiration et une liste de réseaux autorisés facultative, et la révoquer ne touche l'accès de personne d'autre. Un agent peut toujours lire toute clé laissée dans le même shell : retirez donc les clés brutes de fournisseur des environnements de développeurs.

Le LLMjacking est l'utilisation d'identifiants cloud ou d'API d'IA volés pour appeler des modèles de langage hébergés aux frais de la victime, soit pour l'usage de l'attaquant, soit pour revendre l'accès. La défense est celle de tout identifiant qui peut dépenser de l'argent : garder les clés de fournisseur hors du code et des applications clientes, donner à chaque clé une limite de dépenses, surveiller l'usage par clé, et pouvoir désactiver une clé sans déploiement.

Toutes les offres incluent la désactivation d'une clé, réseaux autorisés, limites de modèles et de fournisseurs, limites de dépenses, rotation et expiration, connexion à deux facteurs et passkeys et le journal d'audit. Les alertes de dépenses vont par e-mail sur toutes les offres, et vers Slack et des webhooks signés à partir de l'offre Startup. Garde-fous, SSO et SCIM, rapprochement des coûts avec détection des contournements et la passerelle MCP sont inclus dans l'offre Business.