slug: vinkius-enterprise-ai-questions category: enterprise-ai tags: ["enterprise-ai", "security", "governance", "qa", "isolation", "audit"] date: 2026-09-22 hero: src: /post/hero-enterprise-qa.svg alt: "La surface de question-réponse d'entreprise de Vinkius : douze questions difficiles des équipes de sécurité, de finance et de plateforme, chacune répondue par une surface d'application spécifique. La sandbox V8, le circuit coupe-circuit, la chaîne de hachage, le lockfile de capacités, l'interrupteur de quarantaine."

Questions d'IA d'Entreprise : Douze Questions Difficiles sur Vinkius avec des Réponses dans le Code

Les entreprises ne demandent pas si les agents d'IA transformeront la manière dont le travail est accompli. Elles demandent si Vinkius survivra à la conversation qu'elles savent qui approche, celle où leur équipe de sécurité, leur équipe financière et leur équipe de plateforme exigent chacune de savoir exactement comment cette plateforme gagne la confiance pour exécuter leur trafic de production.

J'ai répondu à ces questions en salle de réunion, dans des salles de guerre de sécurité, et dans les fils silencieux d'e-mail qui suivent chaque pilote. Voici la version consolidée. Chaque réponse ci-dessous nomme le fichier source, le numéro de ligne, et le mécanisme d'application. Rien ici n'est une politique écrite dans une présentation. Chaque contrôle est un appel de fonction, une constante dans le code source, ou une clé Redis que l'exécution vérifie avant que l'agent ne voie le résultat.

Si vous êtes la personne qui doit monter devant une salle et expliquer pourquoi un principal non déterministe avec un accès aux outils mérite s'exécuter à l'intérieur de votre réseau, ceci est la référence que vous gardez ouverte pendant que vous parlez.

---

La Frontière d'Isolation

Q1: Comment savoir que nos agents d'IA ne peuvent pas s'échapper de leur sandbox et atteindre notre réseau interne ?

L'agent ne s'exécute jamais sur une machine que vous possédez. Chaque appel d'outil s'exécute dans un isolate V8 frais créé par isolated-vm, une bibliothèque qui incarne le moteur V8 en dehors de Node.js et ne fournit aucun pont vers le processus hôte sauf si nous l'injectons explicitement. L'isolate reçoit uniquement les globales polyfilled que nous choisissons d'exposer. Il n'y a pas de process, pas de require, pas de fs, pas de fetch du point de vue du guest.

Le plafond mémoire est une constante rigoureuse. Limits.ts:36 définit ISOLATE_MEMORY_LIMIT_MB = 128. Dans IsolateRunner.ts:117 le constructeur définit this.memoryLimit = options.memoryLimit ?? 128 et dans IsolateRunner.ts:143 l'isolate est créé avec new ivm.Isolate({ memoryLimit: this.memoryLimit }). Quand le guest atteint 128 Mo, V8 lève une RangeError qui termine le calcul. Il n'y a pas de dépassement.

La séquence de démarrage dans IsolateRunner.ts:132 montre exactement ce qui est connecté. Les étapes 1 à 12 injectent uniquement les primitives délégués par l'hôte que nous voulons : un pont console, un pont minuterie, un pont crypto (getRandomValues), un pont fetch (qui passe par le SSRF guard), un pont de hachage (SHA-256, SHA-384, SHA-512), un pont HMAC (pour JWT HS256), et un pont de transport MCP. Aucune socket réseau brute n'est jamais remise au guest. L'intercepteur à IsolateRunner.ts:164-183 capture les définitions d'outils depuis le bundle et les renvoie à l'hôte, mais le guest ne peut pas appeler de fonctions hôtes arbitraires.

Le snapshot dans SnapshotCache.ts:19 est validé avec SHA-256 avant d'atteindre V8. Un snapshot corrompu ou falsifié est supprimé à SnapshotCache.ts:70-71 avant d'être chargé.

Pour l'architecture complète de l'exécution derrière cette frontière d'isolation, voir AI Agents Are the New Consumers et How V8 Isolates Power the Vinkius Runtime.

Q2: Si un agent tente d'appeler nos services internes, que nous arrête vraiment ?

Chaque appel HTTP sortant depuis un isolate passe par une seule fonction : safeFetch à SsrfGuard.ts:163. Il n'y a pas d'autre issue. Le guest peut appeler fetch mais le pont à IsolateRunner.ts:161 l'envoie exclusivement vers cette fonction.

La défense SSRF a trois couches, toutes dans SsrfGuard.ts :

Première, validation de destination. SsrfGuard.ts:27 définit PRIVATE_RANGES, une liste de patterns regex correspondant à 127/8, 10/8, 172.16 to 172.31/12, 192.168/16, 169.254/16, 0/8, et leurs jumeaux IPv6 (::1, fc00, fe80). Chaque adresse résolue est testée contre cette liste avant que la connexion ne puisse se poursuivre.

Deuxième, fixation de DNS avec couplage d'IP. SsrfGuard.ts:50 définit DNS_CACHE_MAX_ENTRIES = 4_096. La durée de vie du cache est couplée à la durée de vie de la socket keep-alive d'undici sur Limits.ts:46, AGENT_KEEP_ALIVE_TIMEOUT_MS = 65_000. Une adresse validée ne peut pas survivre à la politique de connexion qui l'a justifiée. Cela empêche les attaques de rebondissement DNS où un attaquant fait pivoter l'enregistrement A entre la résolution et la connexion.

Troisième, la lookup personnalisée d'undici à SsrfGuard.ts:110-113 résout le DNS en une IP avant le handshake TLS, puis passe la même IP comme servername pour garder le SNI aligné sur l'hôte réel connecté. La connexion est fixée à l'IP résolue pour toute la durée de la socket en pool.

Q3: Qu'est-ce qui empêche un outil d'exfiltrer des données sensibles par le biais de sa réponse ?

Le nettoyage des données a lieu dans ResponseGuard.ts, et il s'exécute entièrement dans le processus hôte, jamais à l'intérieur de l'isolate V8. Le commentaire à ResponseGuard.ts:4 indique la limite de sécurité explicitement : le masquage entre les données upstream et la sortie de l'agent.

Le garde-fou est l'étape 6 du pipeline d'exécution à ToolExecutionPipeline.ts:422. Les étapes du pipeline dans l'ordre sont : (1) application de quota à ToolExecutionPipeline.ts:380, (2) exécution du handler à ToolExecutionPipeline.ts:392, (3) normalisation de la réponse à ToolExecutionPipeline.ts:396, (4) troncature FinOps à ToolExecutionPipeline.ts:401, (5) compactage à ToolExecutionPipeline.ts:408, (6) DLP à ToolExecutionPipeline.ts:422, (7) détection d'erreur d'outil à ToolExecutionPipeline.ts:426, et (8) télémétrie à ToolExecutionPipeline.ts:448.

À ResponseGuard.ts:54-57 le garde-fou divise les patterns entrants en deux catégories. Les patterns comme *.email sont extraits vers des noms de champs (ex. email) et appliqués par article sur chaque objet de l'arbre de réponse. Le même pattern que stepRedact dans le pipeline Presenter. Les patterns comme user.ssn utilisent le chemin original et sont compilés avec fast-redact pour une correspondance explicite au niveau supérieur.

La valeur de censuration est [REDACTED] à ResponseGuard.ts:108-116. Quand une erreur se produit pendant la redaction, ResponseGuard.ts:177 retourne { error: '[REDACTED]: DLP redaction failed' } afin qu'aucune donnée partielle ne fasse fuite.

Chaque redaction est comptée et attribuée à ResponseGuard.ts:122-128, ainsi le tableau de bord de Gouvernance IA montre quel connecteur a déclenché quelle redaction et combien de fois.

Q4: Un connecteur compromis ou défectueux peut-il affecter d'autres connecteurs exécutés sur le même runtime ?

Non. Chaque token de connexion reçoit son propre isolate, sa propre carte de credentials, et son propre cycle de vie. IsolateLifecycle.ts:34 s'ouvre avec l'invariant : chaque token reçoit son propre IsolateRunner avec ses propres credentials injectés. Pas de partage entre tokens.

L'injection de credentials à IsolateLifecycle.ts:96-104 fusionne les credentials du serveur décryptés avec le token de connexion de l'appelant, mais seuls les tokens préfixés vk_live_ sont injectés. IsolateLifecycle.ts:32 définit CONNECTION_TOKEN_PREFIX = 'vk_live_'.

Le chemin rapide à IsolateLifecycle.ts:124-136 restaure un isolate depuis le snapshot, mais la ré-injection à IsolateLifecycle.ts:62-64 réaffirme la carte de credentials avant de rendre le runner. Un isolate vivant survit à une seule requête. Legacy SSE le garde pour toute la session et les POSTs sans état le réutilisent tant que cette session est ouverte. Mais il peut avoir été initialisé par un chemin qui n'avait pas encore résolu le token de connexion. Le garde-fou d'empreinte digitale sur injectSecrets garantit que c'est un no-op quand la carte est déjà à jour.

Q5: Comment Vinkius impose-t-il des limites de dépense, et que se passe-t-il quand ils sont dépassés ?

Le circuit coupe-circuit à CircuitBreaker.ts:22 s'exécute comme la première vérification du pipeline. C'est un compteur de fenêtre glissante stocké dans Redis. L'objet de configuration fournit window_minutes, max_requests, et cooldown_minutes depuis la configuration du serveur.

À CircuitBreaker.ts:48-56 le compteur est incrémenté avec INCR sur une clé scope cb:window:{scopeId}:{windowKey}. La clé de fenêtre est dérivée de Math.floor(Date.now() / 1000 / windowSeconds) à CircuitBreaker.ts:50, ainsi la fenêtre avance de manière déterministe et se réinitialise automatiquement.

Quand le compte dépasse max_requests, le disjoncteur à CircuitBreaker.ts:60-62 déclenche en écrivant cb:tripped:{scopeId} avec SETEX pour la période de cooldown. Le message d'erreur est codé et intentionnel :

[SYSTEM] CRITICAL: Financial budget ceiling exceeded.
Your account's circuit breaker has tripped to protect your budget.
DO NOT RETRY this request.

C'est une erreur délibérément non-retryable. Contrairement à une limite de débit 429 que le client réessaie avec un backoff, le circuit coupe-circuit dit à l'agent d'arrêter et à l'utilisateur de vérifier son plan. Le message est injecté dans la réponse de l'outil pour que l'agent le voie dans son contexte de prompt.

Le QuotaEnforcer.ts:27 construit le circuit coupe-circuit dans son constructeur et appelle this.circuitBreaker.check(config) à QuotaEnforcer.ts:48 avant que la logique de quota ne s'exécute.

Q6: Comment gérez-vous les frais supplémentaires sans bloquer le trafic légitime ?

Le modèle de quota se ramifie par plan à QuotaEnforcer.ts:154-246 :

Abonnements de marketplace (plans d'entreprise avec un siège par connecteur) sont hard-blockés au plafond d'abonnement convenu. QuotaEnforcer.ts:163 décrémente le compteur avec DECR et retourne une erreur SUBSCRIPTION QUOTA EXCEEDED à QuotaEnforcer.ts:168.

Plan gratuit est hard-bloqué sans issue pour l'excès. QuotaEnforcer.ts:186-188 décrémente le compteur et retourne REQUEST BLOCKED: QUOTA EXCEEDED avec un lien de mise à niveau à QuotaEnforcer.ts:205.

Plan payant n'est jamais hard-bloqué pour quota. QuotaEnforcer.ts:246 laisse passer la requête. La charge est déclenchée à QuotaEnforcer.ts:236-243 : quand newCount dépasse quota.limit, le surplus est calculé comme newAmount = newCount - quota.limit, et creditSlot = Math.ceil(overAmount / 10_000). Quand le slot franchit une limite de 10K, triggerOverageCharge déclenche fire-and-forget à QuotaEnforcer.ts:242. L'appel de facturation ne bloque jamais la requête.

Le TTL de la clé de quota à QuotaEnforcer.ts:15 est QUOTA_KEY_TTL_SECONDS = 31 * 24 * 60 * 60 (31 jours), couvrant n'importe quel cycle de facturation de 30 jours. La boucle de tentative INCR à QuotaEnforcer.ts:88-100 réessaie jusqu'à 3 fois avec un backoff exponentiel [0, 50, 150] ms.

Q7: Quels arrêts d'urgence existent si un connecteur devient malveillant ou compromis ?

Trois niveaux de disjoncteur, chacun opérant à un scope différent :

Tier 1: Quarantaine par-serveur à SoarController.php:50 POST /servers/{server}/soar/kill. Définit mcp:quarantine:{id} dans Redis avec un TTL de 3600 secondes. Toutes les trois routes de transport vérifient cette clé et retournent 403 à legacySse.ts:63, mcpEndpoint.ts:257, et streamableHttp.ts:101.

Tier 2: Arrêt d'urgence par-serveur à ServerLifecycleController.php:72-100. Désactive le serveur, révoque TOUS les tokens (revoked_at = now, revoked_by = 'server_halt', is_enabled = false aux lignes 81-86), et diffuse mcp:kill-server plus mcp:invalidate par-token via Redis pub/sub à la ligne 89. Conformément à l'Article 14 de l'IA Act Européenne.

Tier 3: Arrêt global au niveau de l'organisation à Organization.php:645-666. Active les colonnes global_halt_at et global_halt_by que l'exécution vérifie à chaque requête.

Le côté runtime reçoit ces signaux à server.ts:96-103. Le canal mcp:kill-server déclenche ConnectionTracker.ts:158-194, qui termine toutes les connexions SSE, libère les isolates V8, et purgue les entrées de cache Redis.

La FAQ de la publication de gouvernance à la question du circuit coupe-circuit couvre le comportement visible par l'utilisateur. Le playbook complet de réponse aux incidents avec intégration SOAR est dans la section FAQ de cette publication.

Q8: Qu'est-ce qui empêche un agent incontrôlable d'ouvrir des milliers de sessions concurrentes ?

La couche de session impose un plafond rigoureux par token. SessionManager.ts:44 définit MAX_SESSIONS_PER_TOKEN = 50. À SessionManager.ts:171 la vérification s'exécute : if (meta.token === token && ++count >= MAX_SESSIONS_PER_TOKEN). La 51e session concurrente est rejetée.

Les sessions sont balayées toutes les 15 secondes via SESSION_SWEEP_INTERVAL_MS = 15_000 (SessionManager.ts:43). Les sessions inactives normales expirent après SESSION_IDLE_TIMEOUT_MS = 120_000 (2 minutes). Sous pression mémoire, le délai d'expiration tombe à SESSION_PRESSURE_TIMEOUT_MS = 30_000 (30 secondes).

Chaque entrée de session dans Redis reçoit REDIS_SESSION_TTL = 150 (2,5 minutes), correspondant au délai d'inactivité à SessionManager.ts:120. Le balayage à SessionManager.ts:89 impose aussi des seuils mémoire : MEMORY_WARN_THRESHOLD = 0.65 (65%) déclenche des avertissements et MEMORY_PRESSURE_THRESHOLD = 0.80 (80%) déclenche une éviction agressive à deux niveaux.

Le mappage session-à-token est stocké dans Redis à SessionManager.ts:155-163, ainsi n'importe quelle instance runtime peut résoudre ou rejeter une session. Cela signifie que l'échelle horizontale fonctionne. Vous pouvez exécuter plusieurs instances runtime et le plafond de session est toujours imposé globalement sur l'ensemble du parc.

Pour les mécanismes de coalescement de sessions au niveau de l'essaim qui gèrent 100 agents concurrents partageant des sessions, voir la publication sur les sessions de SwarmGateway.

Q9: Comment les agents ne dépassent-ils pas le délai sous charge ? Quelle est la surcharge réelle du pipeline de gouvernance ?

Le pipeline est conçu de sorte que la surcharge est proportionnelle à la taille de la réponse, pas à la latence de l'API upstream. L'exécution brute du handler à ToolExecutionPipeline.ts:392 est chronométrée séparément des étapes du pipeline.

Le chemin froid utilise des snapshots. IsolateLifecycle.ts:124-136 tente d'abord le chemin rapide : bootFromSnapshot à IsolateRunner.ts:247 crée l'isolate à partir d'un snapshot en cache avec polyfills pré-chargés, documenté comme environ 3 à 5 millisecondes. Le commentaire à IsolateLifecycle.ts:123 affirme que le cache de snapshots accélère les initialisations suivantes à environ 15 à 25 millisecondes. Seule la première initialisation par déploiement paie le chemin lent à IsolateLifecycle.ts:138, qui exécute le bundle IIFE complet à environ 50 à 100 millisecondes.

À BOOT_TIME_BUDGET_MS = 5_000 (Limits.ts:33), le délai d'initialisation est généreux par rapport aux latences observées. À DISPATCH_TIME_BUDGET_MS = 30_000 (Limits.ts:26), le plafond de distribution couvre la longueur de la latence de l'API upstream. La fonction TimeoutClassifier.ts:53 distingue les erreurs UPSTREAM_TIMEOUT, COMPUTE_TIMEOUT, et MEMORY pour qu'une API externe lente ne soit pas mise en cause sur le bundle du guest.

Le serveur de manifestes à streamableHttp.ts:66-69 sert initialize, tools/list, et prompts/list avec zéro overhead de démarrage V8 : gestionnaires raw du MCP SDK sans coût de framework. Seulement tools/call et prompts/get atteignent le pipeline complet.

Les connexions sont en pool avec keep-alive d'undici. Limits.ts:46 définit AGENT_KEEP_ALIVE_TIMEOUT_MS = 65_000, légèrement au-dessus de la fenêtre d'inactivité standard de 60 secondes de l'ALB. Limits.ts:49 définit AGENT_POOL_MAX = 100 comme plafond rigoureux des agents pool concurrents.

Q10: Comment savoir que notre token de connexion n'est pas utilisé par quelqu'un d'autre ?

Les tokens ne sont jamais stockés ou recherchés par valeur brute dans le cache du runtime. À ProxyRegistry.ts:385-406, la fonction d'invalidation accepte les tokens en texte clair et les hashes de tokens. Le runtime n'a pas de APP_KEY et ne peut pas adresser son propre cache Redis directement. L'invalidation de cache s'écoule du Laravel via pub/sub, jamais du runtime. C'est une contrainte architecturale délibérée : le runtime est purement un récepteur.

La résolution de token à ProxyRegistry.ts:200-218 résout le token de connexion de l'appelant contre l'API Laravel, et le résultat est mis en cache avec un TTL. La fonction invalidate à ProxyRegistry.ts:385 supporte la révocation par token direct et par hash HMAC, ainsi Laravel peut révoquer par ID de hash sans jamais envoyer le token brut via pub/sub.

Le ConnectionTracker.ts:19 définit IDLE_TIMEOUT_MS = 30 * 60_000 (30 minutes) pour le balayage LRU, et ConnectionTracker.ts:356-394 exécute une éviction à deux niveaux : inactif normal à 30 minutes, et pression mémoire à 75% de TASK_MEMORY (par défaut 1 Go).

Q11: Comment vérifier que la surface de capacités n'a pas changé entre les déploiements ?

Le fichier mcpfusion.lock est la source de vérité pour toute la surface comportementale d'un connecteur. CapabilityLockfile.ts:54 définit LOCKFILE_VERSION = 1 et CapabilityLockfile.ts:57 définit LOCKFILE_NAME = 'mcpfusion.lock'.

À CapabilityLockfile.ts:256-313, generateLockfile() produit un snapshot déterministe de compilation de toutes les fonctions, prompts, ressources, imports, et dépendances de module. Chaque LockfileTool à CapabilityLockfile.ts:100-111 déclare entitlements par fonction (filesystem, network, subprocess, crypto, codeEvaluation) et cognitiveGuardarounds (agentLimitMax, egressMaxBytes) à CapabilityLockfile.ts:140-143.

À CapabilityLockfile.ts:388, checkLockfile() est la clé CI. Le chemin rapide vérifie la correspondance de résumé d'intégrité. Le chemin lent à CapabilityLockfile.ts:404-484 effectue une comparaison par fonction en catégorisant chaque changement comme added, removed, changed, ou unchanged. La sortie sérialisée à CapabilityLockfile.ts:324-336 utilise des clés triées, ainsi des entrées identiques produisent toujours la même sortie, rendant le lockfile comparable dans git.

Si le lockfile change entre les déploiements sans une révision correspondante, la clé CI échoue à la compilation. Si l'exécution détecte une fonction qui n'est pas dans le lockfile, elle est rejetée avant le dispatch.

Q12: Comment garantir que les événements d'audit ne peuvent pas être falsifiés ou supprimés ?

Deux chaînes de hachage indépendantes couvrent des surfaces différentes :

La chaîne d'exécution d'outils du runtime est construite par ChainForge.ts. À ChainForge.ts:26, GENESIS_HASH = '0'.repeat(64) ancre la chaîne. Pour chaque événement d'audit :

chain_input  = raw_base64 || previous_hash || sequence_number
current_hash = SHA-256(chain_input)
signature    = Ed25519_Sign(sessionPrivateKey, chainInput)

Ceci est à ChainForge.ts:56-66. L'état de la chaîne (lastHash, lastSeq) est mis en cache de manière atomique dans Redis à StreamingDaemon.ts:309-317 via MULTI/EXEC HSET + XACK. Le daemon lui-même à StreamingDaemon.ts:31 utilise CONSUMER_GROUP = 'audit-group' et est mono-threadé par design. ChainForge.ts:12 indique qu'il est appelé exclusivement par le StreamingDaemon. Aucune concurrence, aucune condition de course.

La traçabilité d'audit de déploiement est gérée par DeployAuditLog.php:144-147. Chaque enregistrement est lié avec HMAC-SHA256 : H(prev_hmac || id || event || payload). La méthode statique verifyChain() à DeployAuditLog.php:175-214 parcourt les enregistrements ordonnés par UUID v7, recalcule le HMAC, et le compare avec hash_equals().

À DeployAuditLog.php:95-99, la méthode delete() lève RuntimeException. Les logs sont immuables, sans chemin de delete() ou update(). Cela est conforme à l'Article 26(5) et Article 73 de l'IA Act Européenne.

Les clés de session sont rotationnées toutes les 24 heures à ChainForge.ts:110-113 (rotateSessionKey). Le TTL de session est appliqué à StreamingDaemon.ts:35 avec SESSION_KEY_TTL_MS = 24 * 60 * 60 * 1000.

Q13: Que contient le coffre scellé, et comment les clés sont-elles réellement gérées ?

Le coffre stocke des paires de clés Ed25519, pas des données AES. VaultProvider.ts:10-52 définit l'interface : getMasterKey, generateSessionKey, sign, verify, et crossSignRotation.

SoftwareVaultProvider.ts:59-116 génère la clé maître avec SETNX sans risque de course sur mcp:vault:{workspaceId}. Le certificat de session à SoftwareVaultProvider.ts:138-143 signe la clé publique de la session avec la clé privée maître, la liant au workspace et au moment d'expiration.

VaultProvider.ts:23 génère une paire de clés de session avec generateSessionKey(24h). Le TTL de 24 heures correspond à la rotation ChainForge à StreamingDaemon.ts:35. La fonction sign à VaultProvider.ts:34 effectue une signature Ed25519 en utilisant la clé privée de la session.

SoftwareVaultProvider.ts:188 implémente crossSignRotation() pour la rotation de clé maître de 90 jours. Cela permet aux anciennes clés de signer de nouvelles clés publiques et vice-versa, permettant une migration sans interruption.

La connexion avec l'architecture d'audit plus large est dans la publication de gouvernance d'IA, qui couvre les douze surfaces qui consomment ces clés.

Q14: Comment détecter et arrêter un agent qui effectue des appels suspects vers des destinations externes inconnues ?

Chaque appel HTTP sortant depuis un isolate est dirigé vers safeFetch à SsrfGuard.ts:163, le seul point de sortie exposé au guest. Le pont à IsolateRunner.ts:161 envoie l'appel fetch du guest exclusivement vers cette fonction.

Le TimeoutClassifier.ts:53 classe les échecs de dispatch en UPSTREAM_TIMEOUT, COMPUTE_TIMEOUT, MEMORY, et INTERNAL_ERROR. Quand 30 pour cent ou plus du budget de dispatch a été dépensé en I/O. À TimeoutClassifier.ts:66, upstreamShareThresholdMs = Math.max(1_000, Math.floor(ctx.dispatchTimeoutMs * 0.3)). L'erreur est imputée au service upstream, pas au bundle du guest. Les 3 appels les plus lents sont exposés à MAX_LISTED_CALLS = 3 (TimeoutClassifier.ts:46).

Les patterns DLP de ResponseGuard.ts couvrent les noms de champs sensibles qui ne devraient jamais apparaître dans les réponses de sortie. Les patterns de redaction par défaut incluent des jokers pour email, password, secret, credit_card, ssn, api_key, token, iban, et plus encore. Chaque redaction est comptée et attribuée à ResponseGuard.ts:122-128, ainsi une hausse de redactions pour un connecteur spécifique déclenche un signal dans le tableau de bord de Gouvernance IA.

Q15: Que se passe-t-il avec ma connexion si le processus du runtime plante en plein milieu d'une requête ?

Les requêtes POST sont sans état par conception. À streamableHttp.ts:15, les requêtes POST sont servies sans état. Chaque requête crée un McpServer + Transport éphémère, gère la requête, et jette tout. Le commentaire à streamableHttp.ts:62 indique que le HTTP sans état signifie que n'importe quelle instance de l'exécution peut répondre à n'importe quelle requête.

Les connexions SSE sont à état mais leurs métadonnées vivent dans Redis. ConnectionTracker.ts:61-67 stocke les métadonnées de connexion SSE dans Redis (compatible ElastiCache), ainsi une panne est récupérée par une nouvelle instance lisant les mêmes métadonnées.

À server.ts:19, le runtime démarre vide. Charge la configuration de manière paresseuse à la première connexion client, pas de manière agressive au démarrage. L'abonné pub/sub à server.ts:71-90 s'abonne à mcp:invalidate, mcp:kill-server, mcp:update-quota, mcp:tools-changed, et mcp:streaming-reload au démarrage.

À server.ts:47-52, les gestionnaires de rejet non traité et d'exception non capturée enregistrent les erreurs fatales mais maintiennent le processus en vie. Le runtime est conçu pour survivre à des échecs individuels de requêtes sans tomber.

Le cache de snapshots à SnapshotCache.ts:202 exécute une purge de démarrage qui valide tous les snapshots en cache au boot, ainsi une panne d'un snapshot corrompu ne se reproduit pas au redémarrage.

---

Les Douze Surfaces Qui Répondent à Ces Questions

Les capacités techniques ci-dessus correspondent aux douze surfaces du modèle de gouvernance de Vinkius. Huit rapportent, quatre décident.

Surfaces qui rapportent (où la visibilité vit) :

1. Crypto Audit Path à ChainForge.ts:26-80 pour la chaîne de hachage du runtime, DeployAuditLog.php:144-214 pour l'intégrité du déploiement.
2. DLP Telemetry à ResponseGuard.ts:122-128 compte chaque redaction par token.
3. FinOps Telemetry à QuotaEnforcer.ts:236-243 suit l'utilisation et déclenche des frais supplémentaires à la limite de 10K.
4. Connection Logs à AuditLogger.ts:19-55 envoie des événements de connexion vers Redis via LPUSH pour la conformité SOC 2.
5. SIEM Dispatch à StreamingDaemon.ts:83-153 consomme des Redis Streams avec XREADGROUP, restaure les checkpoints, et envoie vers des destinations SIEM.
6. Snapshot Integrity à SnapshotCache.ts:95-101 vérifie SHA-256 avant que tout blob n'atteigne V8.
7. Timeout Classification à TimeoutClassifier.ts:41-80 attribue les échecs à upstream vs. compute.
8. Honeytoken Detection: Quand une credential d'appât est utilisée, le webhook du fournisseur se déclenche et le connecteur est automatiquement banni.

Surfaces qui décident (où l'application vit) :

1. Connector Policy à CapabilityLockfile.ts:100-143 gèle la surface de capacités à la compilation.
2. DLP Protection à ResponseGuard.ts:4-177 s'exécute dans le processus hôte sur chaque réponse d'outil.
3. FinOps Guard à CircuitBreaker.ts:22-80 déclenche à des plafonds budgétaires financières avec une erreur non-retryable.
4. Circuit Breaker à QuotaEnforcer.ts:154-246 se ramifie par plan, hard-bloquant marketplace et plan gratuit aux limites tout en autorisant l'excès payant.

Chaque surface est appliquée dans le code, pas dans des documents de politique. Les chiffres, limites, et références de ligne ci-dessus sont l'implémentation. Imprimez-les. Auditez-les. Déployez avec confiance.

Pour la FAQ au niveau de l'utilisateur avec des réponses plus simples, voir la section FAQ de la publication de gouvernance d'IA. Pour la gestion de sessions au niveau de l'essaim qui gère 100 agents concurrents, voir la publication sur les sessions de SwarmGateway.