ADR-0007 — La famille de cles sk_ est retiree, pas reparee

Statut

Accepté · 2026-09-05

Piliers : security-identity, ai-platform, integrations, platform-ops, billing

Contexte

lib/security/api-keys.ts exposait un ApiKeyManager qui frappait trois formats de credential — sk_user_, sk_org_, sk_proj_ — et les gardait dans un Map au niveau du module. C'est tout le stockage qu'il y avait : aucune table, aucune colonne, aucun hash en base.

Sur Vercel, un Map de module vit dans une instance de fonction. Il ne survit pas a un cold start et n'est pas partage entre instances. La consequence n'est pas « les cles expirent trop vite » : c'est que la cle rendue a l'utilisateur par POST /api/keys n'etait deja plus valide au moment ou il la collait, sauf a retomber par hasard sur l'instance chaude qui venait de la frapper. Le systeme n'a donc jamais fonctionne, pas une seule fois, depuis le jour ou il a ete ecrit.

Ce qui en dependait :

Trois credentials fonctionnels existent a cote, chacun avec son resolveur et son hash en base : bst_ (lib/security/api-token.ts, ApiToken.tokenHash), bei_ (lib/security/intelligence-api-key.ts, IntelligenceApiKey.keyHash) et le bearer MCP par store (app/api/mcp/[storeId]/auth). Aucun ne passait par le Map.

Décision

On supprime la famille sk_ et tout ce qui la sert, plutot que de lui donner une table. Les credentials programmables supportes sont bst_, bei_ et le bearer MCP par store.

La seule surface qui gagne du comportement est PATCH/DELETE /api/registry/skills/[slug], qui passe a withSessionAuth : le controle d'auteur qu'elle portait n'avait jamais pu s'executer.

Alternatives écartées

Conséquences

Ce que ca coute :

• Aucune API REST tierce ne peut piloter le chat aujourd'hui. C'etait deja le cas — la difference est que ca ne se pretend plus.
• Le compte de handlers d'API passe de 371 a 366, et docs:claims le verifie.
• reserveCreditsForChannel perd un appelant sur cinq. Les quatre portes restantes sont enumerees dans src/test/ai-use-every-door.test.ts, et cette liste vient de gagner un contre-controle derive : reintroduire un canal facture sans l'y inscrire passe au rouge.
• La colonne Store.apiKey reste en base, vide, jusqu'a une migration operateur. Les trois champs apiKey des types clients (Store, Organization, User) et le champ « API key » de l'org-switcher, eux, sont supprimes : ils affichaient un secret que rien n'ecrivait.
• FeatureGate (src/modules/billing/feature-gating.ts) perd son dernier appelant de production : withApiAuth etait le seul, a l'etape 4 de sa chaine (new FeatureGate(subscription) puis canAccess). Le module et ses 12 tests restent, sans consommateur — suivi dans backlog/billing/0355. Suite (2026-09-06) : ce fichier n'existe plus, il a ete supprime. Chacun de ses exports a ete verifie symbole par symbole — zero appelant de production pour les huit — donc la decision de cet ADR est allee jusqu'au bout au lieu de laisser un vocabulaire de gating que personne n'applique. La verite du gating par plan vit desormais dans src/services/billing/entitlement.ts et src/types/billing-plans.ts, et src/test/billing-gating-single-source.test.ts empeche la recidive.
• withApiAuth disparait de trois gardes derivees (api-authorization-coverage, tenant-query-param-coverage, ai-use-every-door). Reduire une liste d'autorisateurs est l'edit qu'un relecteur doit regarder en premier : c'est pourquoi la troisieme a gagne un contre-controle derive dans la meme PR.

Le signal qui indiquerait qu'il faut revisiter : une demande client reelle d'API REST de chat. La reponse sera alors backlog/security-identity/0353 et le prefixe bst_, jamais un nouveau sk_.

Comment c'est appliqué

Trois gardes derivees, pas une convention :

Les deux premieres sont derivees du contenu de src/lib/security/, pas d'une liste tenue a la main : elles suivent un renommage.