Comment ton IA utilise ta clé Stripe sans jamais la voir

Voici le compromis inconfortable que fait chaque produit « agent IA » : pour accomplir un vrai travail, l'agent a besoin de tes identifiants. Pour facturer un client, il a besoin de ta clé Stripe. Pour déployer, il a besoin de ton token cloud. La réponse habituelle consiste à confier ces secrets au modèle et à espérer que rien ne fuite.

On ne voulait pas espérer. Alors lodos est conçu pour que la fuite soit structurellement impossible, et le build échoue si quelqu'un brise un jour cette garantie.

Le problème quand tu donnes un secret à un modèle

Dès qu'un secret en clair entre dans le contexte d'un modèle de langage, tu en as perdu le contrôle. Il peut réapparaître dans la transcription, dans un appel d'outil, dans un log, dans un résumé que le modèle écrit plus tard, ou dans une réponse à une question de suivi habilement formulée. L'injection de prompt, une instruction malveillante cachée dans une page web, un e-mail ou un document que l'agent lit, transforme ce risque latent en un véritable canal d'exfiltration.

La conclusion honnête, c'est que le modèle ne devrait jamais voir le secret, point. Tout le reste n'est que de la rustine posée sur un défaut de conception.

Référencé, injecté, audité

lodos gère chaque identifiant en trois étapes.

1. Référencé

Ton IA ne travaille jamais avec une valeur. Elle travaille avec un placeholder :

{{secrets.stripe.sk_live}}

Cette référence est tout ce que le modèle voit, en chat, dans un workflow, dans une tâche. Il peut raisonner sur l'utilisation de la clé Stripe sans jamais la détenir.

2. Injecté

Quand un job a réellement besoin de l'identifiant, lodos le déchiffre localement et le passe à un sous-processus isolé sous forme de variable d'environnement, hors de la vue du modèle, et il disparaît dès que le job se termine.

# The agent asked to run this; lodos resolved the reference and
# injected the real value into the subprocess environment only.
STRIPE_API_KEY={{secrets.stripe.sk_live}} ./charge-customer.sh

Le modèle voit la ligne de gauche. Le sous-processus reçoit la valeur de droite. Les deux ne se rencontrent jamais à l'intérieur de la transcription.

3. Audité

Chaque accès s'ajoute à une chaîne HMAC infalsifiable. Le journal enregistre qu'un secret a été utilisé, jamais quelle valeur. Les chemins de champs sont opaques, et toute tentative de modifier l'historique casse la chaîne.

Pourquoi on ne se contente pas de faire confiance à une politique

Il serait facile d'écrire « l'IA est configurée pour ne pas révéler les secrets » et de passer à autre chose. Pour nous, ça ne vaut rien sans application concrète, alors on a intégré la garantie au processus de release.

Un scan d'invariants au moment du build s'exécute à chaque release et fait échouer le build si l'un de ces points est un jour violé :

• Il n'existe aucun outil, nulle part, qui renvoie la valeur d'un secret en clair.
• Il n'existe aucun fournisseur d'API de modèle brut, seulement Claude Code embarqué avec ton propre login.
• Il n'y a aucun eval, Function, vm ou child_process sur un chemin de rendu.
• Les outils inconnus échouent fermés (fail closed), ils ne sont jamais autorisés en silence.
• L'agent s'exécute avec bash explicitement interdit.
• Aucune autorisation unique ne peut réunir la « trifecta mortelle » de données privées + contenu non fiable + exfiltration.
• Les workflows sont uniquement déclaratifs, il n'existe aucun chemin de code à exécuter.

Si un futur commit ajoute un outil qui remet un secret au modèle, la release ne sort tout simplement pas.

Ce qu'on a refusé, et ce qu'on a livré à la place

Le mur a imposé de meilleurs designs, pas moins de fonctionnalités :

Ce qu'on a refusé	Ce qu'on a livré à la place
Une API de modèle brute que l'IA appelle directement	Claude Code embarqué avec ton propre login
Laisser l'IA exécuter des commandes hôte (bash)	Injection au runtime dans un sous-processus, aveugle aux secrets
eval() dans les workflows	YAML déclaratif, aucun chemin de code à exécuter
Des decks générés par image (egress cloud)	Des decks texte hors ligne, zéro réseau

Refuser de fuir n'a pas retiré de capacité. Ça l'a recentrée.

À retenir

Tu peux confier à un agent IA un vrai travail avec identifiants sans lui donner tes identifiants. Le secret reste chiffré sur ta machine, n'entre dans un sous-processus qu'au moment précis de son usage, et ne traverse jamais le contexte du modèle.

C'est toute l'idée derrière lodos : ton IA voit ton travail, pas tes secrets. Lis l'architecture de sécurité complète, ou télécharge lodos et donne une mission à ton agent plutôt qu'une clé.