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: "A superfície de perguntas e respostas empresariais da Vinkius: doze perguntas difíceis das equipes de segurança, finanças e plataforma, cada uma respondida por uma superfície de aplicação específica. O sandbox V8, o circuito interrompido, a cadeia de hash, o lockfile de capacidades, o interruptor de quarentena."

Perguntas sobre AI Empresarial: Doze Perguntas Difíceis sobre Vinkius com Respostas no Código

As empresas não estão perguntando se agentes de IA transformarão como o trabalho é feito. Elas estão perguntando se a Vinkius sobreviverá à conversa que elas sabem que está vindo, a da reunião em que sua equipe de segurança, sua equipe de finanças e sua equipe de plataforma exigem cada uma saber exatamente como esta plataforma conquista a confiança para rodar tráfego de produção.

Eu respondi estas perguntas em salas de reuniões, em salas de guerra de segurança, e nos silenciosos fios de e-mail que seguem cada piloto. Esta é a versão consolidada. Cada resposta abaixo nomes o arquivo de origem, o número da linha, e o mecanismo de aplicação. Nada aqui é política escrita em um deck de slides. Cada controle é uma chamada de função, uma constante em código fonte, ou uma chave Redis que o runtime verifica antes de o agente ver qualquer resultado.

Se você é a pessoa que precisa subir à frente de uma sala e explicar por que um principal não determinístico com acesso a ferramentas merece rodar dentro da sua rede, este é o documento que você mantém aberto enquanto fala.

---

A Fronteira de Isolamento

Q1: Como podemos garantir que nossos agentes de IA não escapam do sandbox e atingem nossa rede interna?

O agente nunca roda em uma máquina que você possui. Cada chamada de ferramenta executa em um V8 isolate fresco criado por isolated-vm, uma biblioteca que embute o motor V8 fora do Node.js e não fornece nenhuma ponte para o processo host a menos que nós injejemos explicitamente uma. O isolate recebe apenas os globais polyfills que escolhemos expor. Não há process, não há require, não há fs, não há fetch do ponto de vista do guest.

O limite de memória é uma constante fixa. Limits.ts:36 define ISOLATE_MEMORY_LIMIT_MB = 128. Em IsolateRunner.ts:117 o construtor define this.memoryLimit = options.memoryLimit ?? 128 e em IsolateRunner.ts:143 o isolate é criado com new ivm.Isolate({ memoryLimit: this.memoryLimit }). Quando o guest atinge 128 MB, o V8 lança um RangeError que termina o cálculo. Não há como exceder.

A sequência de inicialização em IsolateRunner.ts:132 mostra exatamente o que é conectado. Passos 1 a 12 injetam apenas os primitivos delegados pelo host que pretendemos: uma ponte de console, uma ponte de temporizadores, uma ponte de criptografia (getRandomValues), uma ponte de fetch (que passa pelo SSRF guard), uma ponte de resumo (SHA-256, SHA-384, SHA-512), uma ponte HMAC (para JWT HS256), e uma ponte de transporte MCP. Nenhum soquete de rede bruto é entregue ao guest. O interceptor em IsolateRunner.ts:164-183 captura definições de ferramentas do bundle e envia-as de volta ao host, mas o guest não pode chamar funções arbitrárias do host.

O snapshot em SnapshotCache.ts:19 é validado com SHA-256 antes de chegar ao V8. Um snapshot corrompido ou adulterado é deletado em SnapshotCache.ts:70-71 antes de ser carregado.

Para a arquitetura completa do runtime por trás desta fronteira de isolamento, veja AI Agents Are the New Consumers e How V8 Isolates Power the Vinkius Runtime.

Q2: Se um agente tentar chamar nossos serviços internos, o que realmente o impede?

Toda chamada HTTP de saída de um isolate passa por uma única função: safeFetch em SsrfGuard.ts:163. Não há outro caminho de saída. O guest pode chamar fetch mas a ponte em IsolateRunner.ts:161 a encaminha exclusivamente para esta função.

A defesa SSRF tem três camadas, todas em SsrfGuard.ts:

Primeiro, validação de destino. SsrfGuard.ts:27 define PRIVATE_RANGES, uma lista de padrões regex que correspondem a 127/8, 10/8, 172.16 to 172.31/12, 192.168/16, 169.254/16, 0/8, e seus gêmeos IPv6 (::1, fc00, fe80). Todo endereço resolvido é testado contra esta lista antes que a conexão possa prosseguir.

Segundo, fixação de DNS com acoplamento de IP. SsrfGuard.ts:50 define DNS_CACHE_MAX_ENTRIES = 4_096. O tempo de vida do cache é acoplado ao tempo de vida do soquete keep-alive do undici em Limits.ts:46, AGENT_KEEP_ALIVE_TIMEOUT_MS = 65_000. Um endereço validado não pode sobreviver à política de conexão que o justificou. Isso impede ataques de rebinding de DNS onde um atacante roteia o registro A entre a resolução e a conexão.

Terceiro, a lookup customizada do undici em SsrfGuard.ts:110-113 resolve DNS para um IP antes do handshake TLS, depois passa este mesmo IP como servername para manter o SNI alinhado com o host real sendo conectado. A conexão é fixada ao IP resolvido pela duração do soquete em pool.

Q3: O que impede uma ferramenta de exfiltrar dados sensíveis por meio de sua resposta?

A limpeza de dados acontece em ResponseGuard.ts, e roda inteiramente no processo host, nunca dentro do isolate V8. O comentário em ResponseGuard.ts:4 afirma o limite de segurança explicitamente: redação entre dados upstream e saída do agente.

O guardião é a etapa 6 do pipeline de execução em ToolExecutionPipeline.ts:422. As etapas do pipeline em ordem são: (1) aplicação de quota em ToolExecutionPipeline.ts:380, (2) execução do handler em ToolExecutionPipeline.ts:392, (3) normalização da resposta em ToolExecutionPipeline.ts:396, (4) truncamento FinOps em ToolExecutionPipeline.ts:401, (5) compactação em ToolExecutionPipeline.ts:408, (6) DLP em ToolExecutionPipeline.ts:422, (7) detecção de erro de ferramenta em ToolExecutionPipeline.ts:426, e (8) telemetria em ToolExecutionPipeline.ts:448.

Em ResponseGuard.ts:54-57 o guardião divide os padrões de entrada em duas categorias. Padrões como *.email são extraídos para nomes de campos (ex. email) e aplicados por item em cada objeto da árvore de resposta. O mesmo padrão de stepRedact no pipeline Presenter. Padrões como user.ssn usam o caminho original e são compilados com fast-redact para correspondência explícita no nível superior.

O valor de censura é [REDACTED] em ResponseGuard.ts:108-116. Quando um erro ocorre durante a redação, ResponseGuard.ts:177 retorna { error: '[REDACTED]: DLP redaction failed' } para que nenhum dado parcial vaze.

Cada redação é contada e atribuída em ResponseGuard.ts:122-128, assim o painel de Governança de AI mostra qual conector disparou qual redação e quantas vezes.

Q4: Um conector comprometido ou com bug pode afetar outros conectores rodando no mesmo runtime?

Não. Cada token de conexão recebe seu próprio isolate, seu próprio mapa de credenciais, e seu próprio ciclo de vida. IsolateLifecycle.ts:34 abre com o invariante: cada token recebe seu próprio IsolateRunner com suas próprias credenciais injetadas. Nada compartilhado entre tokens.

A injeção de credenciais em IsolateLifecycle.ts:96-104 mescla credenciais do servidor descriptografadas com o token de conexão do chamador, mas apenas tokens com prefixo vk_live_ são injetados. IsolateLifecycle.ts:32 define CONNECTION_TOKEN_PREFIX = 'vk_live_'.

O caminho rápido em IsolateLifecycle.ts:124-136 restaura um isolate do snapshot, mas a re-injeção em IsolateLifecycle.ts:62-64 reafirma o mapa de credenciais antes de entregar o runner de volta. Um isolate ativo sobrevive a uma única requisição. Legacy SSE mantém-o por toda a sessão e POSTs stateless reaproveitam enquanto essa sessão está aberta. Mas ele pode ter sido inicializado por um caminho que ainda não tinha resolvido o token de conexão. O guardião de impressão digital em injectSecrets garante que isso é um no-op quando o mapa já está atualizado.

Q5: Como a Vinkius impõe limites de gastos, e o que acontece quando eles são excedidos?

O circuito interrompido em CircuitBreaker.ts:22 executa como a primeira verificação no pipeline. É um contador de janela deslizante armazenado no Redis. O objeto de configuração fornece window_minutes, max_requests, e cooldown_minutes da configuração do servidor.

Em CircuitBreaker.ts:48-56 o contador é incrementado com INCR em uma chave com escopo cb:window:{scopeId}:{windowKey}. A chave da janela é derivada de Math.floor(Date.now() / 1000 / windowSeconds) em CircuitBreaker.ts:50, assim a janela avança deterministicamente e reseta automaticamente.

Quando o contador excede max_requests, o interrutor em CircuitBreaker.ts:60-62 dispara escrevendo cb:tripped:{scopeId} com SETEX pelo período de cooldown. A mensagem de erro é deliberadamente codificada:

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

Esta é uma falha deliberadamente não retriável. Diferentemente de um limite de taxa 429, que um cliente retria com backoff, o circuito interrompido diz ao agente para parar e ao usuário para verificar seu plano. A mensagem é injetada na resposta da ferramenta para que o agente veja em seu contexto de prompt.

O QuotaEnforcer.ts:27 constrói o circuito interrompido em seu construtor e chama this.circuitBreaker.check(config) em QuotaEnforcer.ts:48 antes de qualquer lógica de quota.

Q6: Como vocês lidam com cobranças extras sem bloquear tráfego legítimo?

O modelo de quota ramifica por plano em QuotaEnforcer.ts:154-246:

Assinaturas de marketplace (planos corporativos com assento por conector) são bloqueados com hard-block no limite de assinatura acordado. QuotaEnforcer.ts:163 decrementa o contador com DECR e retorna um erro SUBSCRIPTION QUOTA EXCEEDED em QuotaEnforcer.ts:168.

Plano gratuito é bloqueado com hard-block sem caminho de excesso. QuotaEnforcer.ts:186-188 decrementa o contador e retorna REQUEST BLOCKED: QUOTA EXCEEDED com um link de atualização em QuotaEnforcer.ts:205.

Plano pago nunca é bloqueado com hard-block por quota. QuotaEnforcer.ts:246 permite a requisição. A cobrança de excesso é disparada em QuotaEnforcer.ts:236-243: quando newCount excede quota.limit, o excesso é calculado como newAmount = newCount - quota.limit, e creditSlot = Math.ceil(overAmount / 10_000). Quando o slot cruza um limite de 10K, triggerOverageCharge dispara como fire-and-forget em QuotaEnforcer.ts:242. A chamada de cobrança nunca bloqueia a requisição.

O TTL da chave de quota em QuotaEnforcer.ts:15 é QUOTA_KEY_TTL_SECONDS = 31 * 24 * 60 * 60 (31 dias), cobrindo qualquer ciclo de faturamento de 30 dias. O loop de tentativa INCR em QuotaEnforcer.ts:88-100 tenta até 3 vezes com backoff exponencial [0, 50, 150] ms.

Q7: Que paradas de emergência existem se um conector ficar malicioso ou comprometido?

Três níveis de chave de parada, cada um operando em um escopo diferente:

Tier 1: Quarentena por-servidor em SoarController.php:50 POST /servers/{server}/soar/kill. Define mcp:quarantine:{id} no Redis com TTL de 3600 segundos. Todas as rotas de transporte verificam esta chave e retornam 403 em legacySse.ts:63, mcpEndpoint.ts:257, e streamableHttp.ts:101.

Tier 2: Parada de emergência por-servidor em ServerLifecycleController.php:72-100. Desativa o servidor, revoga TODOS os tokens (revoked_at = now, revoked_by = 'server_halt', is_enabled = false nas linhas 81-86), e transmite mcp:kill-server mais mcp:invalidate por-token via Redis pub/sub na linha 89. Conforme Artigo 14 da IA Act Europeia.

Tier 3: Parada global no nível da organização em Organization.php:645-666. Ativa as colunas global_halt_at e global_halt_by que o runtime verifica a cada requisição.

O lado runtime recebe estes sinais em server.ts:96-103. O canal mcp:kill-server dispara ConnectionTracker.ts:158-194, que encerra todas as conexões SSE, descarta isolados V8, e purga entradas de cache Redis.

A FAQ da publicação de governança na pergunta do circuito interrompido cobre o comportamento visível ao usuário. O playbook completo de resposta a incidentes com integração SOAR está na seção FAQ daquela publicação.

Q8: O que impede um agente descontrolado de abrir milhares de sessões concorrentes?

A camada de sessão impõe um teto rígido por token. SessionManager.ts:44 define MAX_SESSIONS_PER_TOKEN = 50. Em SessionManager.ts:171 a verificação roda: if (meta.token === token && ++count >= MAX_SESSIONS_PER_TOKEN). A 51ª sessão concorrente é rejeitada.

As sessões são varridas a cada 15 segundos via SESSION_SWEEP_INTERVAL_MS = 15_000 (SessionManager.ts:43). Sessões ociosas normais expiram após SESSION_IDLE_TIMEOUT_MS = 120_000 (2 minutos). Sob pressão de memória, o timeout cai para SESSION_PRESSURE_TIMEOUT_MS = 30_000 (30 segundos).

Cada entrada de sessão no Redis recebe REDIS_SESSION_TTL = 150 (2,5 minutos), combinando o timeout ocioso em SessionManager.ts:120. A varredura em SessionManager.ts:89 também impõe limites de memória: MEMORY_WARN_THRESHOLD = 0.65 (65%) inicia avisos e MEMORY_PRESSURE_THRESHOLD = 0.80 (80%) dispara evicção agressiva de dois níveis.

O mapeamento sessão-para-token é armazenado no Redis em SessionManager.ts:155-163, assim qualquer instância runtime pode resolver ou rejeitar uma sessão. Isso significa que a escala horizontal funciona. Você pode rodar múltiplas instâncias runtime e o teto de sessão ainda é imposto globalmente na frota.

Para a mecânica de coalescimento de sessões no nível de enxame que gerencia 100 agentes concorrentes compartilhando sessões, veja a publicação sobre sessões do SwarmGateway.

Q9: Como agentes não ficam sem tempo sob carga? Qual o overhead real da pipeline de governança?

O pipeline é desenhado de modo que o overhead é proporcional ao tamanho da resposta, não à latência da API upstream. A execução raw do handler em ToolExecutionPipeline.ts:392 é cronometrada separadamente das etapas do pipeline.

O caminho frio usa snapshots. IsolateLifecycle.ts:124-136 tenta o caminho rápido primeiro: bootFromSnapshot em IsolateRunner.ts:247 cria o isolate a partir de um snapshot em cache com polyfills pré-carregados, documentado como aproximadamente 3 a 5 milissegundos. O comentário em IsolateLifecycle.ts:123 afirma que o cache de snapshots acelera inicializações subsequentes para cerca de 15 a 25 milissegundos. Apenas a primeira inicialização por deploy paga o caminho lento em IsolateLifecycle.ts:138, que executa o bundle IIFE completo em aproximadamente 50 a 100 milissegundos.

Em BOOT_TIME_BUDGET_MS = 5_000 (Limits.ts:33), o timeout de inicialização é generoso em relação às latências observadas. Em DISPATCH_TIME_BUDGET_MS = 30_000 (Limits.ts:26), o teto de despacho cobre a cauda da latência da API upstream. A função TimeoutClassifier.ts:53 distingue entre erros UPSTREAM_TIMEOUT, COMPUTE_TIMEOUT, e MEMORY para que uma API externa lenta não seja culpe pelo bundle do guest.

O servidor de manifestos em streamableHttp.ts:66-69 serve initialize, tools/list, e prompts/list com zero overhead de inicialização V8: manipuladores raw do MCP SDK sem custo de framework. Apenas tools/call e prompts/get atingem o pipeline completo.

As conexões são em pool com keep-alive do undici. Limits.ts:46 define AGENT_KEEP_ALIVE_TIMEOUT_MS = 65_000, um pouco acima da janela idle padrão de 60 segundos do ALB. Limits.ts:49 define AGENT_POOL_MAX = 100 como o teto rígido de agents pool concorrentes.

Q10: Como sabemos que nosso token de conexão não está sendo usado por outra pessoa?

Os tokens nunca são armazenados ou buscados pelo valor bruto no cache do runtime. Em ProxyRegistry.ts:385-406, a função de invalidação aceita tokens em texto plano e hashes de tokens. O runtime não tem APP_KEY e não pode endereçar seu próprio cache Redis diretamente. A invalidação de cache flui do Laravel via pub/sub, nunca do runtime. Esta é uma restrição arquitetural deliberada: o runtime é puramente um receptor.

A resolução de token em ProxyRegistry.ts:200-218 resolve o token de conexão do chamador contra a API Laravel, e o resultado é cacheado com TTL. A função invalidate em ProxyRegistry.ts:385 suporta revogação tanto por token direto quanto por hash HMAC, assim o Laravel pode revogar por ID de hash sem nunca enviar o token bruto por pub/sub.

O ConnectionTracker.ts:19 define IDLE_TIMEOUT_MS = 30 * 60_000 (30 minutos) para a varredura LRU, e ConnectionTracker.ts:356-394 executa evicção de dois níveis: ocioso normal em 30 minutos, e pressão de memória a 75% de TASK_MEMORY (padrão 1 GB).

Q11: Como verificamos que a superfície de capacidades não mudou entre deploys?

O arquivo mcpfusion.lock é a fonte de verdade para toda a superfície comportamental de um conector. CapabilityLockfile.ts:54 define LOCKFILE_VERSION = 1 e CapabilityLockfile.ts:57 define LOCKFILE_NAME = 'mcpfusion.lock'.

Em CapabilityLockfile.ts:256-313, generateLockfile() produz um snapshot determinístico de compilação de todas as ferramentas, prompts, recursos, imports, e dependências de módulo. Cada LockfileTool em CapabilityLockfile.ts:100-111 declara entitlements por ferramenta (filesystem, network, subprocess, crypto, codeEvaluation) e cognitiveGuardarounds (agentLimitMax, egressMaxBytes).

Em CapabilityLockfile.ts:388, checkLockfile() é a chave CI. O caminho rápido verifica correspondência de resumo de integridade. O caminho lento em CapabilityLockfile.ts:404-484 faz comparação por ferramenta categorizando cada mudança como added, removed, changed, ou unchanged. A saída serializada em CapabilityLockfile.ts:324-336 usa chaves classificadas, assim entradas idênticas sempre produzem saída idêntica, tornando o lockfile comparável no git.

Se o lockfile muda entre deploys sem uma revisão correspondente, a chave CI falha o build. Se o runtime detecta uma ferramenta que não está no lockfile, ela é rejeitada antes do despacho.

Q12: Como garantimos que eventos de auditoria não podem ser falsificados ou deletados?

Duas cadeias de hash independentes cobrem superfícies diferentes:

A cadeia de execução de ferramentas do runtime é construída por ChainForge.ts. Em ChainForge.ts:26, GENESIS_HASH = '0'.repeat(64) ancorra a cadeia. Para cada evento de auditoria:

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

Isso está em ChainForge.ts:56-66. O estado da cadeia (lastHash, lastSeq) é cacheado atomicamente no Redis em StreamingDaemon.ts:309-317 via MULTI/EXEC HSET + XACK. O daemon em si em StreamingDaemon.ts:31 usa CONSUMER_GROUP = 'audit-group' e é unithread por design. ChainForge.ts:12 afirma que é chamado exclusivamente pelo StreamingDaemon. Nenhuma concorrência, nenhuma condição de corrida.

O trilha de auditoria de deployment é gerenciada por DeployAuditLog.php:144-147. Cada registro é encadeado com HMAC-SHA256: H(prev_hmac || id || event || payload). O método estático verifyChain() em DeployAuditLog.php:175-214 percorre registros ordenados por UUID v7, recomputa o HMAC, e compara com hash_equals().

Em DeployAuditLog.php:95-99, o método delete() lança RuntimeException. Logs são imutáveis, sem caminho de delete() ou update(). Isto está em conformidade com Artigo 26(5) e Artigo 73 da IA Act Europeia.

As chaves de sessão rotacionam a cada 24 horas em ChainForge.ts:110-113 (rotateSessionKey). O TTL da sessão é imposta em StreamingDaemon.ts:35 com SESSION_KEY_TTL_MS = 24 * 60 * 60 * 1000.

Q13: O que há no cofre selado, e como as chaves são realmente gerenciadas?

O cofre armazena pares de chaves Ed25519, não dados AES. VaultProvider.ts:10-52 define a interface: getMasterKey, generateSessionKey, sign, verify, e crossSignRotation.

SoftwareVaultProvider.ts:59-116 gera a chave mestre com SETNX race-safe em mcp:vault:{workspaceId}. O certificado de sessão em SoftwareVaultProvider.ts:138-143 assina a chave pública da sessão com a chave privada mestre, ligando-a ao workspace e ao tempo de expiração.

VaultProvider.ts:23 gera um par de chaves de sessão com generateSessionKey(24h). O TTL de 24 horas corresponde à rotação do ChainForge em StreamingDaemon.ts:35. A função sign em VaultProvider.ts:34 realiza assinatura Ed25519 usando a chave privada da sessão.

SoftwareVaultProvider.ts:188 implementa crossSignRotation() para rotação de chave mestra de 90 dias. Isso permite que chaves antigas assinem novas chaves públicas e vice-versa, permitindo migração sem downtime.

A conexão com a arquitetura de auditoria mais ampla está na publicação de governança de AI, que cobre as doze superfícies que consomem estas chaves.

Q14: Como detectamos e paramos um agente fazendo chamadas suspeitas a destinos externos desconhecidos?

Toda chamada HTTP de saída de um isolate é direcionada para safeFetch em SsrfGuard.ts:163, o único ponto de saída exposto ao guest. A ponte em IsolateRunner.ts:161 direciona a chamada fetch do guest exclusivamente para esta função.

O TimeoutClassifier.ts:53 classifica falhas de despacho em UPSTREAM_TIMEOUT, COMPUTE_TIMEOUT, MEMORY, e INTERNAL_ERROR. Quando 30 porcento ou mais do orçamento de despacho foi gasto em I/O. Em TimeoutClassifier.ts:66, upstreamShareThresholdMs = Math.max(1_000, Math.floor(ctx.dispatchTimeoutMs * 0.3)). O erro é atribuído ao serviço upstream, não ao bundle do guest. As 3 chamadas mais lentas são exibidas em MAX_LISTED_CALLS = 3 (TimeoutClassifier.ts:46).

Os padrões DLP de ResponseGuard.ts cobrem nomes de campos sensíveis que nunca devem aparecer em respostas de saída. Os padrões de redação padrão incluem curingas para email, password, secret, credit_card, ssn, api_key, token, iban, e mais. Cada redação é contada e atribuída em ResponseGuard.ts:122-128, assim um pico de redações para um conector específico dispara um sinal no painel de Governança de AI.

Q15: O que acontece com minha conexão se o processo runtime travar no meio de uma requisição?

Requisições POST são stateless por design. Em streamableHttp.ts:15, requisições POST são servidas statelessmente. Cada requisição cria um McpServer + Transport efêmero, manipula a requisição, e descarta tudo. O comentário em streamableHttp.ts:62 afirma que HTTP stateless significa que qualquer instância runtime pode responder a qualquer requisição.

Conexões SSE são stateful mas seus metadados vivem no Redis. ConnectionTracker.ts:61-67 armazena metadados de conexão SSE no Redis (compatível com ElastiCache), assim uma falha é recuperada por uma nova instância lendo os mesmos metadados.

Em server.ts:19, o runtime inicializa vazio. Carrega configuração lazily na primeira conexão do cliente, não ansiosamente no startup. O assinante pub/sub em server.ts:71-90 subscreve a mcp:invalidate, mcp:kill-server, mcp:update-quota, mcp:tools-changed, e mcp:streaming-reload no startup.

Em server.ts:47-52, manipuladores de rejeição não tratada e exceção não capturada registram erros fatais mas mantêm o processo vivo. O runtime é desenhado para sobreviver a falhas individuais de requisições sem descer.

O cache de snapshots em SnapshotCache.ts:202 executa uma purga de inicialização que valida todos os snapshots em cache no boot, assim uma falha de snapshot corrompido não se repete no restart.

---

As Doze Superfícies Que Respondem a Estas Perguntas

As capacidades técnicas acima correspondem às doze superfícies do modelo de governança da Vinkius. Oito reportam, quatro decidem.

Superfícies que reportam (onde a visibilidade vive):

1. Crypto Audit Path em ChainForge.ts:26-80 para a cadeia de hash do runtime, DeployAuditLog.php:144-214 para integridade de deployment.
2. DLP Telemetry em ResponseGuard.ts:122-128 conta cada redação por token.
3. FinOps Telemetry em QuotaEnforcer.ts:236-243 monitora uso e dispara cobranças extras no limite de 10K.
4. Connection Logs em AuditLogger.ts:19-55 envia eventos de conexão para Redis via LPUSH para conformidade SOC 2.
5. SIEM Dispatch em StreamingDaemon.ts:83-153 consome Redis Streams com XREADGROUP, restaura checkpoints, e despacha para destinos SIEM.
6. Snapshot Integrity em SnapshotCache.ts:95-101 verifica SHA-256 antes de qualquer blob chegar ao V8.
7. Timeout Classification em TimeoutClassifier.ts:41-80 atribui falhas a upstream vs. compute.
8. Honeytoken Detection: Quando uma credencial de isca é usada, o webhook do provedor dispara e o conector é auto-banido.

Superfícies que decidem (onde a aplicação vive):

1. Connector Policy em CapabilityLockfile.ts:100-143 congela a superfície de capacidades em tempo de compilação.
2. DLP Protection em ResponseGuard.ts:4-177 roda no processo host em cada resposta de ferramenta.
3. FinOps Guard em CircuitBreaker.ts:22-80 dispara em teto de orçamento financeiro com erro não retriável.
4. Circuit Breaker em QuotaEnforcer.ts:154-246 ramifica por plano, hard-bloqueia marketplace e plano gratuito nos limites enquanto permite excesso pago.

Cada superfície é aplicada em código, não em documentos de política. Os números, limites, e referências de linha acima são a implementação. Imprima-os. Audite-os. Implante com confiança.

Para a FAQ de nível de usuário com respostas mais simples, veja a seção FAQ da publicação de governança de AI. Para a gestão de sessões no nível de enxame que lida com 100 agentes concorrentes, veja a publicação sobre sessões do SwarmGateway.