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 superficie de preguntas y respuestas empresariales de Vinkius: doce preguntas difíciles de los equipos de seguridad, finanzas y plataforma, cada una respondida por una superficie de aplicación específica. El sandbox V8, el interruptor de circuito, la cadena hash, el lockfile de capacidades, el interruptor de cuarentena."

Preguntas de IA Empresarial : Doce Preguntas Difíciles sobre Vinkius con Respuestas en Código

Las empresas no preguntan si los agentes de IA transformarán cómo se hace el trabajo. Preguntan si Vinkius sobrevivirá a la conversación que saben que se avecina, la de la reunión en la que su equipo de seguridad, su equipo financiero y su equipo de plataforma exigen cada uno saber exactamente cómo esta plataforma gana la confianza para ejecutar su tráfico de producción.

He respondido estas preguntas en juntas directivas, en salas de guerra de seguridad, y en los hilos silenciosos de correo que siguen a cada piloto. Esta es la versión consolidada. Cada respuesta a continuación nombra el archivo fuente, el número de línea, y el mecanismo de aplicación. Nada aquí es política escrita en una presentación. Cada control es una llamada de función, una constante en el código fuente, o una clave Redis que el runtime verifica antes de que el agente vea algún resultado.

Si usted es la persona que debe subir ante una sala y explicar por qué un principal no determinista con acceso a herramientas merece ejecutarse dentro de su red, esta es la referencia que mantiene abierta mientras habla.

---

El Límite de Aislamiento

Q1: ¿Cómo sabemos que nuestros agentes de IA no pueden escapar de su sandbox y alcanzar nuestra red interna?

El agente nunca se ejecuta en una máquina que usted posea. Cada llamada de herramienta se ejecuta en un isolate V8 fresco creado por isolated-vm, una biblioteca que incrusta el motor V8 fuera de Node.js y no proporciona ningún puente hacia el proceso host a menos que nosotros inyectemos uno explícitamente. El isolate recibe solo los globales polyfilled que elegimos exponer. No hay process, no hay require, no hay fs, no hay fetch desde la perspectiva del guest.

El límite de memoria es una constante rígida. Limits.ts:36 define ISOLATE_MEMORY_LIMIT_MB = 128. En IsolateRunner.ts:117 el constructor establece this.memoryLimit = options.memoryLimit ?? 128 y en IsolateRunner.ts:143 el isolate se crea con new ivm.Isolate({ memoryLimit: this.memoryLimit }). Cuando el guest alcanza 128 MB, V8 lanza una RangeError que termina el cálculo. No hay forma de excederlo.

La secuencia de arranque en IsolateRunner.ts:132 muestra exactamente qué se conecta. Los pasos 1 a 12 inyectan solo los primitivos delegados por el host que pretendemos: un puente de consola, un puente de temporizadores, un puente cripto (getRandomValues), un puente de fetch (que pasa por el SSRF guard), un puente de resumen (SHA-256, SHA-384, SHA-512), un puente HMAC (para JWT HS256), y un puente de transporte MCP. Nunca se entrega un socket de red bruto al guest. El interceptor en IsolateRunner.ts:164-183 captura definiciones de herramientas del bundle y los envía de vuelta al host, pero el guest no puede llamar funciones arbitrarias del host.

El snapshot en SnapshotCache.ts:19 es validado con SHA-256 antes de llegar a V8. Un snapshot corrompido o manipulado es eliminado en SnapshotCache.ts:70-71 antes de ser cargado.

Para la arquitectura completa del runtime detrás de este límite de aislamiento, ver AI Agents Are the New Consumers y How V8 Isolates Power the Vinkius Runtime.

Q2: Si un agente intenta llamar a nuestros servicios internos, ¿qué realmente lo detiene?

Toda llamada HTTP saliente desde un isolate pasa por una sola función: safeFetch en SsrfGuard.ts:163. No hay otra salida. El guest puede llamar a fetch pero el puente en IsolateRunner.ts:161 lo dirige exclusivamente a esta función.

La defensa SSRF tiene tres capas, todas en SsrfGuard.ts:

Primero, validación de destino. SsrfGuard.ts:27 define PRIVATE_RANGES, una lista de patrones regex que coinciden con 127/8, 10/8, 172.16 to 172.31/12, 192.168/16, 169.254/16, 0/8, y sus gemelos IPv6 (::1, fc00, fe80). Cada dirección resuelta se prueba contra esta lista antes de que la conexión pueda proceder.

Segundo, fijación de DNS con acoplamiento de IP. SsrfGuard.ts:50 establece DNS_CACHE_MAX_ENTRIES = 4_096. El tiempo de vida del caché está acoplado a la vida del socket keep-alive de undici en Limits.ts:46, AGENT_KEEP_ALIVE_TIMEOUT_MS = 65_000. Una dirección aprobada no puede sobrevivir a la política de conexión que justificó su fijación. Esto previene ataques de rebinding DNS donde un atacante rota el registro A entre la resolución y la conexión.

Tercero, la búsqueda personalizada de undici en SsrfGuard.ts:110-113 resuelve DNS a una IP antes del handshake TLS, luego pasa esa misma IP como servername para mantener el SNI alineado con el host real al que se conecta. La conexión se fija a la IP resuelta por toda la vida del socket en pool.

Q3: ¿Qué impide que una herramienta exfiltrar datos sensibles a través de su respuesta?

La limpieza de datos ocurre en ResponseGuard.ts, y se ejecuta completamente en el proceso host, nunca dentro del isolate V8. El comentario en ResponseGuard.ts:4 afirma el límite de seguridad explícitamente: redacción entre datos upstream y salida del agente.

El guardián es la etapa 6 del pipeline de ejecución en ToolExecutionPipeline.ts:422. Las etapas del pipeline en orden son: (1) aplicación de cuota en ToolExecutionPipeline.ts:380, (2) ejecución del handler en ToolExecutionPipeline.ts:392, (3) normalización de la respuesta en ToolExecutionPipeline.ts:396, (4) truncamiento FinOps en ToolExecutionPipeline.ts:401, (5) compactación en ToolExecutionPipeline.ts:408, (6) DLP en ToolExecutionPipeline.ts:422, (7) detección de error de herramienta en ToolExecutionPipeline.ts:426, y (8) telemetría en ToolExecutionPipeline.ts:448.

En ResponseGuard.ts:54-57 el guardián divide los patrones entrantes en dos categorías. Patrones como *.email se extraen a nombres de campos (ej. email) y se aplican por artículo en cada objeto del árbol de respuesta. El mismo patrón que stepRedact en el pipeline Presenter. Patrones como user.ssn usan la ruta original y se compilan con fast-redact para coincidencia explícita a nivel superior.

El valor de censura es [REDACTED] en ResponseGuard.ts:108-116. Cuando ocurre un error durante la redacción, ResponseGuard.ts:177 retorna { error: '[REDACTED]: DLP redaction failed' } para que no filtre ningún dato parcial.

Cada redacción se cuenta y atribuye en ResponseGuard.ts:122-128, así el panel de Gobernanza de IA muestra qué conector activó qué redacción y cuántas veces.

Q4: ¿Un conector comprometido o defectuoso puede afectar otros conectores que se ejecutan en el mismo runtime?

No. Cada token de conexión recibe su propio isolate, su propio mapa de credenciales, y su propio ciclo de vida. IsolateLifecycle.ts:34 abre con el invariante: cada token recibe su propio IsolateRunner con sus propias credenciales inyectadas. Nada compartido entre tokens.

La inyección de credenciales en IsolateLifecycle.ts:96-104 fusiona las credenciales del servidor descifradas con el token de conexión del llamador, pero solo los tokens con prefijo vk_live_ se inyectan. IsolateLifecycle.ts:32 define CONNECTION_TOKEN_PREFIX = 'vk_live_'.

El camino rápido en IsolateLifecycle.ts:124-136 restaura un isolate desde el snapshot, pero la re-inyección en IsolateLifecycle.ts:62-64 reafirma el mapa de credencias antes de devolver el runner. Un isolate activo sobrevive a una sola solicitud. Legacy SSE lo mantiene durante toda la sesión y los POSTs stateless lo reutilizan mientras esa sesión está abierta. Pero puede haber sido inicializado por una ruta que aún no había resuelto el token de conexión. El guarda de huella digital en injectSecrets garantiza que esto es un no-op cuando el mapa ya está actualizado.

Q5: ¿Cómo Vinkius impone límites de gasto, y qué sucede cuando se exceden?

El circuito interrumpido en CircuitBreaker.ts:22 se ejecuta como la primera verificación del pipeline. Es un contador de ventana deslizante almacenado en Redis. El objeto de configuración proporciona window_minutes, max_requests, y cooldown_minutes desde la configuración del servidor.

En CircuitBreaker.ts:48-56 el contador se incrementa con INCR en una clave con ámbito cb:window:{scopeId}:{windowKey}. La clave de ventana se deriva de Math.floor(Date.now() / 1000 / windowSeconds) en CircuitBreaker.ts:50, así la ventana avanza de manera determinista y se reinicia automáticamente.

Cuando el conteo excede max_requests, el interruptor en CircuitBreaker.ts:60-62 se activa escribiendo cb:tripped:{scopeId} con SETEX por el período de cooldown. El mensaje de error está codificado e intencional:

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

Este es un error deliberadamente no reintentable. A diferencia de un límite de velocidad 429, que un cliente reintenta con backoff, el circuito interrumpido dice al agente que se detenga y al usuario que verifique su plan. El mensaje se inyecta en la respuesta de la herramienta para que el agente lo vea en su contexto de prompt.

El QuotaEnforcer.ts:27 construye el circuito interrumpido en su constructor y llama this.circuitBreaker.check(config) en QuotaEnforcer.ts:48 antes de que se ejecute cualquier lógica de cuota.

Q6: ¿Cómo manejan los cargos extra sin bloquear tráfico legítimo?

El modelo de cuota se ramifica por plan en QuotaEnforcer.ts:154-246:

Suscripciones de marketplace (planes empresariales con un asiento por conector) se bloquean estrictamente en el límite de suscripción acordado. QuotaEnforcer.ts:163 decrementa el contador con DECR y retorna un error SUBSCRIPTION QUOTA EXCEEDED en QuotaEnforcer.ts:168.

Plan gratuito se bloquea estrictamente sin ruta de exceso. QuotaEnforcer.ts:186-188 decrementa el contador y retorna REQUEST BLOCKED: QUOTA EXCEEDED con un enlace de actualización en QuotaEnforcer.ts:205.

Plan pagado nunca se bloquea estrictamente por cuota. QuotaEnforcer.ts:246 deja pasar la solicitud. El cargo extra se activa en QuotaEnforcer.ts:236-243: cuando newCount excede quota.limit, el exceso se calcula como newAmount = newCount - quota.limit, y creditSlot = Math.ceil(overAmount / 10_000). Cuando el slot cruza un límite de 10K, triggerOverageCharge se dispara fire-and-forget en QuotaEnforcer.ts:242. La llamada de facturación nunca bloquea la solicitud.

El TTL de la clave de cuota en QuotaEnforcer.ts:15 es QUOTA_KEY_TTL_SECONDS = 31 * 24 * 60 * 60 (31 días), que cubre cualquier ciclo de facturación de 30 días. El bucle de reintento INCR en QuotaEnforcer.ts:88-100 reintenta hasta 3 veces con backoff exponencial [0, 50, 150] ms.

Q7: ¿Qué paradas de emergencia existen si un conector se vuelve malicioso o comprometido?

Tres niveles de interruptor de parada, cada uno operando en un ámbito diferente:

Tier 1: Cuarentena por-servidor en SoarController.php:50 POST /servers/{server}/soar/kill. Establece mcp:quarantine:{id} en Redis con un TTL de 3600 segundos. Las tres rutas de transporte verifican esta clave y retornan 403 en legacySse.ts:63, mcpEndpoint.ts:257, y streamableHttp.ts:101.

Tier 2: Parada de emergencia por-servidor en ServerLifecycleController.php:72-100. Desactiva el servidor, revoca TODOS los tokens (revoked_at = now, revoked_by = 'server_halt', is_enabled = false en las líneas 81-86), y transmite mcp:kill-server más mcp:invalidate por-token vía Redis pub/sub en la línea 89. Conforme al Artículo 14 de la IA Act Europea.

Tier 3: Parada global a nivel de organización en Organization.php:645-666. Activa las columnas global_halt_at y global_halt_by que el runtime verifica en cada solicitud.

El lado runtime recibe estas señales en server.ts:96-103. El canal mcp:kill-server desencadena ConnectionTracker.ts:158-194, que termina todas las conexiones SSE, libera los isolates V8, y purga las entradas de caché Redis.

La FAQ de la publicación de gobernanza en la pregunta del circuito interrumpido cubre el comportamiento visible para el usuario. El playbook completo de respuesta a incidentes con integración SOAR está en la sección FAQ de esa publicación.

Q8: ¿Qué impide que un agente descontrolado abra miles de sesiones concurrentes?

La capa de sesión impone un límite rígido por token. SessionManager.ts:44 define MAX_SESSIONS_PER_TOKEN = 50. En SessionManager.ts:171 la verificación se ejecuta: if (meta.token === token && ++count >= MAX_SESSIONS_PER_TOKEN). La sesión 51 concurrente es rechazada.

Las sesiones se barren cada 15 segundos mediante SESSION_SWEEP_INTERVAL_MS = 15_000 (SessionManager.ts:43). Las sesiones inactivas normales expiran después de SESSION_IDLE_TIMEOUT_MS = 120_000 (2 minutos). Bajo presión de memoria, el tiempo de espera se reduce a SESSION_PRESSURE_TIMEOUT_MS = 30_000 (30 segundos).

Cada entrada de sesión en Redis recibe REDIS_SESSION_TTL = 150 (2.5 minutos), coincidiendo con el tiempo de espera inactivo en SessionManager.ts:120. El barrido en SessionManager.ts:89 también impone umbrales de memoria: MEMORY_WARN_THRESHOLD = 0.65 (65%) inicia avisos y MEMORY_PRESSURE_THRESHOLD = 0.80 (80%) activa la eliminación agresiva de dos niveles.

El mapeo de sesión-a-token se almacena en Redis en SessionManager.ts:155-163, así cualquier instancia runtime puede resolver o rechazar una sesión. Esto significa que la escala horizontal funciona. Puede ejecutar múltiples instancias runtime y el límite de sesión sigue siendo impuesto globalmente en toda la flota.

Para las mecánicas de coalescimiento de sesiones a nivel de enjambre que manejan 100 agentes concurrentes compartiendo sesiones, ver la publicación sobre sesiones de SwarmGateway.

Q9: ¿Cómo evitan los agentes agotar el tiempo bajo carga? ¿Cuál es la sobrecarga real del pipeline de gobernanza?

El pipeline está diseñado de modo que la sobrecarga es proporcional al tamaño de la respuesta, no a la latencia de la API upstream. La ejecución bruta del handler en ToolExecutionPipeline.ts:392 se cronometra por separado de las etapas del pipeline.

El camino frío usa snapshots. IsolateLifecycle.ts:124-136 intenta primero el camino rápido: bootFromSnapshot en IsolateRunner.ts:247 crea el isolate desde un snapshot en caché con polyfills pre-cargados, documentado como aproximadamente 3 a 5 milisegundos. El comentario en IsolateLifecycle.ts:123 afirma que el cache de snapshots acelera arranques posteriores a aproximadamente 15 a 25 milisegundos. Solo el primer arranque por despliegue paga el camino lento en IsolateLifecycle.ts:138, que ejecuta el bundle IIFE completo a aproximadamente 50 a 100 milisegundos.

En BOOT_TIME_BUDGET_MS = 5_000 (Limits.ts:33), el tiempo de espera de arranque es generoso respecto a las latencias observadas. En DISPATCH_TIME_BUDGET_MS = 30_000 (Limits.ts:26), el techo de despacho cubre la cola de la latencia de la API upstream. La función TimeoutClassifier.ts:53 distingue entre errores UPSTREAM_TIMEOUT, COMPUTE_TIMEOUT, y MEMORY para que una API externa lenta no sea culpada del bundle del guest.

El servidor de manifiestos en streamableHttp.ts:66-69 sirve initialize, tools/list, y prompts/list con cero overhead de arranque V8: gestores raw del MCP SDK sin costo de framework. Solo tools/call y prompts/get alcanzan el pipeline completo.

Las conexiones se ponen en pool con keep-alive de undici. Limits.ts:46 establece AGENT_KEEP_ALIVE_TIMEOUT_MS = 65_000, ligeramente por encima de la ventana inactiva estándar de 60 segundos del ALB. Limits.ts:49 establece AGENT_POOL_MAX = 100 como el límite rígido de agentes pool concurrentes.

Q10: ¿Cómo sabemos que nuestro token de conexión no lo está usando otra persona?

Los tokens nunca se almacenan ni buscan por valor bruto en la caché del runtime. En ProxyRegistry.ts:385-406, la función de invalidación acepta tokens en texto plano y hashes de tokens. El runtime no tiene APP_KEY y no puede dirigir su propia caché Redis directamente. La invalidación de caché fluye del Laravel vía pub/sub, nunca desde el runtime. Esta es una restricción arquitectónica deliberada: el runtime es puramente un receptor.

La resolución de token en ProxyRegistry.ts:200-218 resuelve el token de conexión del llamador contra la API Laravel, y el resultado se cachea con TTL. La función invalidate en ProxyRegistry.ts:385 admite revocación tanto de token directo como de hash HMAC, así Laravel puede revocar por ID de hash sin enviar nunca el token bruto por pub/sub.

El ConnectionTracker.ts:19 establece IDLE_TIMEOUT_MS = 30 * 60_000 (30 minutos) para el barrido LRU, y ConnectionTracker.ts:356-394 ejecuta eliminación de dos niveles: inactivo normal a 30 minutos, y presión de memoria al 75% de TASK_MEMORY (1 GB por defecto).

Q11: ¿Cómo verificamos que la superficie de capacidades no ha cambiado entre despliegues?

El archivo mcpfusion.lock es la fuente de verdad para toda la superficie conductual de un conector. CapabilityLockfile.ts:54 define LOCKFILE_VERSION = 1 y CapabilityLockfile.ts:57 define LOCKFILE_NAME = 'mcpfusion.lock'.

En CapabilityLockfile.ts:256-313, generateLockfile() produce un snapshot determinista de tiempo de compilación de todas las herramientas, prompts, recursos, imports, y dependencias de módulo. Cada LockfileTool en CapabilityLockfile.ts:100-111 declara entitlements por herramienta (filesystem, network, subprocess, crypto, codeEvaluation) y cognitiveGuardarounds (agentLimitMax, egressMaxBytes) en CapabilityLockfile.ts:140-143.

En CapabilityLockfile.ts:388, checkLockfile() es la clave CI. El camino rápido verifica la coincidencia del resumen de integridad. El camino lento en CapabilityLockfile.ts:404-484 hace una comparación por herramienta categorizando cada cambio como added, removed, changed, o unchanged. La salida serializada en CapabilityLockfile.ts:324-336 usa claves clasificadas, así entradas idénticas producen siempre la misma salida, haciendo el lockfile comparables en git.

Si el lockfile cambia entre despliegues sin una revisión correspondiente, la clave CI falla en la compilación. Si el runtime detecta una herramienta que no está en el lockfile, se rechaza antes del dispatch.

Q12: ¿Cómo garantizamos que los eventos de auditoría no pueden ser falsificados o eliminados?

Dos cadenas de hash independientes cubren superficies diferentes:

La cadena de ejecución de herramientas del runtime es construida por ChainForge.ts. En ChainForge.ts:26, GENESIS_HASH = '0'.repeat(64) ancla la cadena. Para cada evento de auditoría:

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

Esto está en ChainForge.ts:56-66. El estado de la cadena (lastHash, lastSeq) se cachea atómicamente en Redis en StreamingDaemon.ts:309-317 vía MULTI/EXEC HSET + XACK. El daemon en sí en StreamingDaemon.ts:31 usa CONSUMER_GROUP = 'audit-group' y es mono-hilo por diseño. ChainForge.ts:12 afirma que es llamado exclusivamente por el StreamingDaemon. Sin concurrencia, sin condiciones de carrera.

La trazabilidad de auditoría de despliegue es gestionada por DeployAuditLog.php:144-147. Cada registro se encadena con HMAC-SHA256: H(prev_hmac || id || event || payload). El método estático verifyChain() en DeployAuditLog.php:175-214 recorre registros ordenados por UUID v7, recomputa el HMAC, y lo compara con hash_equals().

En DeployAuditLog.php:95-99, el método delete() lanza RuntimeException. Los logs son inmutables, sin camino de delete() o update(). Esto cumple con el Artículo 26(5) y Artículo 73 de la IA Act Europea.

Las claves de sesión se rotan cada 24 horas en ChainForge.ts:110-113 (rotateSessionKey). El TTL de sesión se impone en StreamingDaemon.ts:35 con SESSION_KEY_TTL_MS = 24 * 60 * 60 * 1000.

Q13: ¿Qué hay en el cofre sellado, y cómo se gestionan realmente las claves?

El cofre almacena pares de claves Ed25519, no datos AES. VaultProvider.ts:10-52 define la interfaz: getMasterKey, generateSessionKey, sign, verify, y crossSignRotation.

SoftwareVaultProvider.ts:59-116 genera la clave maestra con SETNX segura contra condiciones de carrera en mcp:vault:{workspaceId}. El certificado de sesión en SoftwareVaultProvider.ts:138-143 firma la clave pública de la sesión con la clave privada maestra, vinculándola al workspace y al momento de expiración.

VaultProvider.ts:23 genera un par de claves de sesión con generateSessionKey(24h). El TTL de 24 horas corresponde a la rotación de ChainForge en StreamingDaemon.ts:35. La función sign en VaultProvider.ts:34 realiza firma Ed25519 usando la clave privada de la sesión.

SoftwareVaultProvider.ts:188 implementa crossSignRotation() para la rotación de clave maestra de 90 días. Esto permite que las claves antiguas firmen nuevas claves públicas y viceversa, permitiendo migración sin tiempo de inactividad.

La conexión con la arquitectura de auditoría más amplia está en la publicación de gobernanza de IA, que cubre las doce superficies que consumen estas claves.

Q14: ¿Cómo detectamos y detenemos un agente que realiza llamadas sospechosas a destinos externos desconocidos?

Cada llamada HTTP saliente desde un isolate se dirige a safeFetch en SsrfGuard.ts:163, el único punto de salida expuesto al guest. El puente en IsolateRunner.ts:161 dirige la llamada fetch del guest exclusivamente a esta función.

El TimeoutClassifier.ts:53 clasifica fallos de dispatch en UPSTREAM_TIMEOUT, COMPUTE_TIMEOUT, MEMORY, y INTERNAL_ERROR. Cuando el 30 porcentaje o más del presupuesto de dispatch se gastó en I/O. En TimeoutClassifier.ts:66, upstreamShareThresholdMs = Math.max(1_000, Math.floor(ctx.dispatchTimeoutMs * 0.3)). El error se atribuye al servicio upstream, no al bundle del guest. Las 3 llamadas más lentas se muestran en MAX_LISTED_CALLS = 3 (TimeoutClassifier.ts:46).

Los patrones DLP de ResponseGuard.ts cubren nombres de campos sensibles que nunca deben aparecer en respuestas de salida. Los patrones de redacción por defecto incluyen comodines para email, password, secret, credit_card, ssn, api_key, token, iban, y más. Cada redacción se cuenta y atribuye en ResponseGuard.ts:122-128, así un pico de redacciones para un conector específico activa una señal en el panel de Gobernanza de IA.

Q15: ¿Qué sucede con mi conexión si el proceso runtime se cuelga en medio de una solicitud?

Las solicitudes POST son stateless por diseño. En streamableHttp.ts:15, las solicitudes POST se sirven sin estado. Cada solicitud crea un McpServer + Transport efímero, maneja la solicitud, y descarta todo. El comentario en streamableHttp.ts:62 señala que HTTP sin estado significa que cualquier instancia runtime puede responder a cualquier solicitud.

Las conexiones SSE son a estado pero sus metadatos viven en Redis. ConnectionTracker.ts:61-67 almacena metadatos de conexión SSE en Redis (compatible con ElastiCache), así una caída se recupera con una nueva instancia leyendo los mismos metadatos.

En server.ts:19, el runtime arranca vacío. Carga configuración de forma perezosa en la primera conexión del cliente, no ansiosamente al iniciar. El suscriptor pub/sub en server.ts:71-90 se suscribe a mcp:invalidate, mcp:kill-server, mcp:update-quota, mcp:tools-changed, y mcp:streaming-reload al iniciar.

En server.ts:47-52, los manejadores de rechazo no capturado y excepción no capturada registran errores fatales pero mantienen el proceso vivo. El runtime está diseñado para sobrevivir a fallas individuales de solicitudes sin caerse.

El cache de snapshots en SnapshotCache.ts:202 ejecuta una purga de arranque que valida todos los snapshots en caché al boot, así una caída de un snapshot corrupto no se repite al reinicio.

---

Las Doce Superficies que Responden a Estas Preguntas

Las capacidades técnicas anteriores corresponden a las doce superficies del modelo de gobernanza de Vinkius. Ocho reportan, cuatro deciden.

Superficies que reportan (dónde vive la visibilidad) :

1. Crypto Audit Path en ChainForge.ts:26-80 para la cadena hash del runtime, DeployAuditLog.php:144-214 para la integridad del despliegue.
2. DLP Telemetry en ResponseGuard.ts:122-128 cuenta cada redacción por token.
3. FinOps Telemetry en QuotaEnforcer.ts:236-243 sigue el uso y activa cargos extra en el límite de 10K.
4. Connection Logs en AuditLogger.ts:19-55 envía eventos de conexión a Redis vía LPUSH para cumplimiento SOC 2.
5. SIEM Dispatch en StreamingDaemon.ts:83-153 consume Redis Streams con XREADGROUP, restaura checkpoints, y despacha a destinos SIEM.
6. Snapshot Integrity en SnapshotCache.ts:95-101 verifica SHA-256 antes de que cualquier blob alcance V8.
7. Timeout Classification en TimeoutClassifier.ts:41-80 atribuye fallos a upstream vs. compute.
8. Honeytoken Detection: Cuando se usa una credencial de isca, el webhook del proveedor se dispara y el conector es autobaneado.

Superficies que deciden (dónde vive la aplicación) :

1. Connector Policy en CapabilityLockfile.ts:100-143 congela la superficie de capacidades en tiempo de compilación.
2. DLP Protection en ResponseGuard.ts:4-177 se ejecuta en el proceso host en cada respuesta de herramienta.
3. FinOps Guard en CircuitBreaker.ts:22-80 se activa en techos de presupuesto financiero con error no reintentable.
4. Circuit Breaker en QuotaEnforcer.ts:154-246 se ramifica por plan, hard-bloqueando marketplace y plan gratuito en sus límites mientras permite exceso pagado.

Cada superficie se aplica en código, no en documentos de política. Los números, límites, y referencias de línea arriba son la implementación. Imprímalos. Audítelos. Despliegue con confianza.

Para la FAQ a nivel de usuario con respuestas más simples, ver la sección FAQ de la publicación de gobernanza de IA. Para la gestión de sesiones a nivel de enjambre que maneja 100 agentes concurrentes, ver la publicación sobre sesiones de SwarmGateway.