diff --git a/common/PROTOCOL-INFRA.md b/common/PROTOCOL-INFRA.md
index 2a54823..6e3341f 100644
--- a/common/PROTOCOL-INFRA.md
+++ b/common/PROTOCOL-INFRA.md
@@ -431,3 +431,28 @@ Le MCP natif de Baserow (image officielle, non patchable) ne couvre que les lign
 ## FIX -- baserow-schema-mcp : flux SSE bloque via le reverse-proxy DSM, resolu en HTTP 1.0 backend (2026-08-17, resolu)
 
 Une fois la regle DSM `baserow-schema.bolbol.tn` -> 3101 creee (cert Let's Encrypt auto-provisionne OK, TLS OK), le endpoint `/mcp/<token>/sse` restait silencieusement bloque (0 octet recu avant timeout), reproduit avec plusieurs clients. **Resolu par Nabil : choisir HTTP 1.0 (pas 1.1) comme version backend dans le formulaire DSM du reverse-proxy.** Reteste apres coup avec succes sur curl (ALPN h2 par defaut) ET httpx pur HTTP/1.1 -- pas de regression cote client malgre le libelle "HTTP 1.0" trompeur (mode de proxying DSM->backend moins strict sur le chunked/keep-alive, pas une vraie retrogradation cote client). A appliquer directement sur toute future regle DSM devant un service SSE/MCP si le meme blocage silencieux apparait. Detail : common/baserow-schema-mcp.md.
+
+## RÈGLE -- Interdiction absolue d'utiliser Nabil-Key (bfk-0cd1fb...) dans les agents Hermes et services NAS, clés virtuelles dédiées obligatoires (2026-09-04)
+
+1. **Périmètre et cause racine** :
+   - La clé `Nabil-Key` (`bfk-0cd1fba7d440ca2eefd30b28a7349b7d28422dcbc49e982d`) est STRICTEMENT réservée à l'usage personnel direct de Nabil et dispose d'un forfait plafonné à 8 $/mois (sur OpenCode Go).
+   - Toute utilisation de cette clé par un agent automatique ou un conteneur draine le quota personnel de Nabil et bloque l'inférence.
+   - **INTERDICTION ABSOLUE** de configurer ou d'injecter cette clé dans les conteneurs Hermes (`model.api_key`, `auxiliary.*.api_key`), les services NAS, les scripts de veille ou les cron jobs.
+
+2. **Clés virtuelles dédiées par instance** :
+   Chaque instance Hermes et chaque consommateur doit impérativement utiliser sa propre clé virtuelle isolée :
+   - `hermes-agent-perso` : `vk-hermes-perso` (`sk-bf-bb062ad2-438d-4176-9f85-b703168b6df0`)
+   - `hermes-agent-nyora` : `vk-hermes-nyora` (`sk-bf-7b194df6-9169-42b7-87cf-4545585b4d7c`)
+   - `hermes-agent-tt` : variable d'environnement `OPENCODE_GO_API_KEY` (avec `api_key: ''` dans `config.yaml`)
+   - `context-hub` : sa propre clé dédiée (`bfk-e5832b...`)
+   - `nyora-convert-api` : `vk-nyora-notes-tt` (`sk-bf-2685...`)
+
+3. **Piège de patch partiel (Ticket infra-2026-09-014)** :
+   - Lors d'une migration ou d'un changement de clé dans Hermes, veiller à auditer **TOUS** les blocs de configuration : `model.api_key` ET les sous-blocs `auxiliary.vision.api_key`, `auxiliary.embeddings.api_key`, etc.
+   - Un remplacement restreint à `model.api_key` laisse la vision ou les tâches annexes débiter l'ancienne clé silencieusement.
+
+4. **Routage Bifrost VPS via bifrost-proxy** :
+   - Les requêtes OpenCode Go doivent transiter par `bifrost-proxy:3086`, qui assure l'injection du header requis `x-bf-eh-x-opencode-session` vers Bifrost VPS (`bifrost.vps.bolbol.tn:8080`).
+
+Détail complet : `common/piege-virtual-key-nabil-key-bifrost-hermes-20260904.md`.
+