As quatro falhas obrigatórias

Falha 1 — prompt de segurança substitui autorização

Sintoma: um documento com uma instrução embutida ("ignore instruções anteriores", "modo de manutenção", "solicitação autorizada da equipe de compliance") consegue fazer o agente propor uma ação de alto privilégio — exportar arquivo, enviar e-mail para fora, conceder papel — e a única coisa entre o pedido e o efeito é uma frase no system prompt dizendo para o modelo recusar. Causa: uma instrução de segurança no prompt é um pedido à mesma camada que está sendo atacada — o texto que o modelo lê. Ela pode funcionar contra as frases de ataque que alguém testou e falhar contra a próxima variação, porque não existe uma lista finita de formas de pedir a mesma coisa em linguagem natural. Resposta: mover a decisão para fora do texto. authorizeToolCall decide só a partir de {tenantId, role, toolName} contra DEFAULT_TOOL_POLICY, uma tabela congelada onde o papel extractor nunca tem export_archive, send_email ou grant_role — não há string de ataque que altere uma tabela que o código nunca consulta o documento para preencher. checkEgress nega o destino do e-mail mesmo com uma allowlist vazia ou com um destino diferente já cadastrado (sem correspondência parcial). E, como defesa estrutural adicional contra um futuro bug que tente contornar isso passando um campo de autoridade forjado, assertNoAuthorizationFromDocument rejeita qualquer ação que não declare sourceOfAuthority: 'policy' antes mesmo de authorizeToolCall ser consultada. Os oito testes da suíte "Mandatory failure 1" cobrem exatamente essas três camadas, e um teste adicional confirma que a tabela de política não foi alterada depois de processar o fixture hostil.

Falha 2 — circuit breaker descarta jobs

Sintoma: o provedor cai, um circuit breaker abre para parar de sobrecarregá-lo ainda mais — e, ao abrir, os jobs que estavam prestes a ser processados simplesmente somem, porque a lógica de "não chamar o provedor agora" não tinha um caminho explícito para o que fazer com o job em vez disso. Causa: um circuit breaker bem implementado do ponto de vista do provedor (para de martelar um sistema já sobrecarregado) pode ser mal implementado do ponto de vista do job, se "não chamar" for tratado como equivalente a "não fazer nada com o resultado". Resposta: callWithBreaker(breaker, fn, onOpenFallback) não tem um terceiro caminho — se o breaker não permite tentativa, onOpenFallback é chamado e seu retorno é devolvido com a marca shortCircuited: true; se permite, fn roda e o sucesso ou falha é registrado no breaker. Em todo uso real deste capítulo, onOpenFallback marca o job como needs_review — o mesmo estado terminal seguro que o capítulo 2 já definia para qualquer extração que precise de revisão humana, não um estado novo inventado só para outage. Um teste prova que o provedor não é chamado de novo enquanto o breaker está OPEN (proteção real), e outro prova que o job aparece em needs_review no fallback (nenhuma perda). Um Bulkhead por chave complementa isso limitando concorrência por tenant ou provedor, para que um vizinho barulhento não abra o breaker de todo mundo ao mesmo tempo.

Falha 3 — rollback quebra schema de jobs em voo

Sintoma: uma versão de policy introduz uma regra nova — neste capítulo, requiresSecondApproval: true para um tipo de documento de alto risco (wire-transfer-instruction sintético), exigindo duas aprovações humanas independentes em vez de uma. Um rollback de código de volta para a versão anterior, que nunca ouviu falar desse campo, continua aprovando o mesmo tipo de documento com uma única aprovação — não porque alguém reverteu a regra de propósito, mas porque o código antigo não tem como enxergar um campo que o schema mais novo introduziu. Causa: um rollback de código é tratado como "voltar para um estado que já funcionou", mas jobs que já existem sob o schema mais novo não voltam junto — eles continuam carregando uma garantia que o handler antigo não sabe avaliar. Resposta: assertJobSafeForHandlerVersion(job, 'v1') recusa processar um job com requiresSecondApproval: true e menos de dois aprovadores distintos registrados — a mesma checagem passa livremente para o mesmo job assim que uma segunda aprovação independente existe, e passa livremente para qualquer job que nunca teve essa regra em primeiro lugar (sem falso positivo). findJobsNeedingReconciliation(jobs, 'v1') varre uma lista inteira de jobs e devolve exatamente os que um rollback precisaria entregar para revisão humana antes de ser declarado completo — no fixture deste capítulo, isso é uma lista de um único job, o exato job que a falha descreve. O runbook de rollback (examples/operations/rollback-runbook.md) ordena as ações ao redor disso: reverter policy/prompt antes de código, rodar a reconciliação, só então reverter código — e nunca apagar um log de um efeito que já aconteceu sob a versão que está sendo revertida.

Falha 4 — backup presumido sem restore test

Sintoma: um runbook ou um colega afirma "temos backup" — e a primeira vez que alguém de fato tenta restaurar é durante um incidente real, quando já é tarde demais para descobrir que o processo de restauração nunca funcionou. Causa: a existência de um arquivo de backup não prova nada sobre a capacidade de recuperação; ela só prova que uma exportação rodou uma vez. Sem um restore de verdade, "temos backup" é uma crença, não uma evidência. Resposta: runRestoreDrill() não afirma recuperação — ele executa: exporta um estado sintético (quatro jobs, um deles com a regra de segunda aprovação da falha 3, três entradas de auditoria) para um arquivo temporário real no disco, descarta toda referência em memória ao estado original, reimporta só a partir do arquivo, recalcula um checksum SHA-256 sobre o conteúdo restaurado e compara com o checksum gravado no próprio arquivo. Rodado nesta sessão, o drill normal recuperou os quatro jobs e as três entradas de auditoria com contagem e status idênticos ao original, em 1 a 3 milissegundos medidos — um número que só prova que o código de exportação/importação funciona rápido para um snapshot sintético de quatro registros num laptop, não uma meta de RTO de produção. Um segundo cenário, deliberadamente corrompendo um campo do snapshot depois de exportado, faz importState lançar RestoreIntegrityError em vez de importar silenciosamente um dado incorreto — a diferença entre um backup testado e um backup presumido é exatamente esse segundo cenário existir e falhar alto quando deveria.

O que a mock de sandbox não prova

runParserWithLimits corre a chamada de parse contra um timeout com Promise.race e rejeita se o tempo estourar — isso prova que o código chamador reage corretamente a um parser lento ou travado, nada mais. Não prova isolamento de sistema operacional: um parser que consome CPU sem nunca ceder o event loop pode travar o processo inteiro antes mesmo do timer conseguir disparar seu callback. Não prova proteção contra um "zip bomb" ou uma estrutura de arquivo patológica que expanda para gigabytes na memória — o mock nunca chega a executar uma biblioteca de parsing real contra um arquivo malicioso de verdade. A mesma honestidade se aplica ao teste de concorrência: claimJobOnce prova que a lógica de "exatamente um vencedor" está correta dentro de um único processo e um único event loop; não cria uma corrida real entre dois processos do sistema operacional disputando o mesmo job — essa é a mesma limitação que o capítulo 4 já declarou para si mesmo ao construir a fila durável, e este capítulo a repete em vez de fingir tê-la resolvido.

Custo, segurança e reversibilidade

Segurança e resiliência se encontram na mesma decisão de shadow/canary: um plano de rollout (examples/operations/rollout-plan.md) que testa uma versão nova contra tráfego real sem afetar usuários ainda paga por cada chamada de LLM que o teste faz — chamada de shadow não é gratuita, ela precisa passar pela mesma reserva de orçamento do capítulo 6, só que sob uma subcota dedicada, e seus efeitos propostos precisam passar pelas mesmas guardas de autorização e egress antes de serem descartados deliberadamente, nunca por um caminho de código diferente e menos testado. Os critérios de parada do rollout incluem um critério de segurança sem piso de amostra: uma única ocorrência de um fixture de ataque conseguindo um efeito que deveria ser negado já é suficiente para interromper o estágio, porque uma regressão de segurança não é uma distribuição para se tirar média — ao contrário do critério de qualidade, que exige uma amostra mínima de vinte documentos antes de contar como evidência, reaproveitando a disciplina de amostra do capítulo 5. Toda decisão deste capítulo também é reversível por desenho, mas com uma ressalva que os quatro falhas obrigatórias deixam explícita: reversível não significa que os efeitos de uma versão errada desaparecem junto com o rollback do código — um e-mail já enviado continua enviado, um documento já aprovado com uma única aprovação continua aprovado até que a reconciliação humana o revise. Rollback desfaz a causa futura, nunca o efeito passado; é por isso que o runbook trata reconciliação como um passo obrigatório, não uma limpeza opcional.

Checklist

• Toda decisão de autorização recebe só identidade e política como entrada, nunca um campo derivado do texto do documento ou uma alegação do próprio modelo.
• Toda ação proposta declara sourceOfAuthority: 'policy'; qualquer outro valor é rejeitado antes da checagem de política.
• Todo upload passa por limite de tipo e tamanho antes do parser rodar; todo parse roda sob um timeout que o worker nunca espera indefinidamente.
• Um circuit breaker nunca retorna sem chamar a função real ou o fallback do chamador; o fallback sempre marca o job como needs_review, nunca o descarta.
• Um outage respeita um teto de gasto por tentativa; retries nunca são ilimitados.
• Um rollback de código roda a checagem de compatibilidade de schema e entrega a lista de reconciliação a um humano antes de ser declarado completo.
• Nenhum rollback apaga um log ou uma entrada de auditoria de um efeito já executado.
• Nenhuma alegação de backup é feita sem um restore real, medido, incluindo um cenário de falha esperada (snapshot corrompido) que também foi testado.
• node --test examples/security/guards.test.mjs passa localmente antes de qualquer mudança de guarda, breaker, schema ou drill de restore.

Exercícios

Básico — provar que um documento hostil não altera a allowlist. Critério verificável: rodar node --test examples/security/guards.test.mjs e conferir que a suíte "Basic exercise" passa, incluindo o teste que serializa DEFAULT_TOOL_POLICY antes e depois de processar o fixture prompt-injection-exfiltration e compara as duas strings. Solução comentada: o teste também confirma que a tabela está congelada em todos os níveis exercitados (Object.isFrozen no objeto raiz e em cada array de papel), então mesmo um código que tentasse push uma ferramenta nova na allowlist do extractor lançaria TypeError antes de conseguir.

Intermediário — provar que um outage de provedor aciona revisão segura sem retries infinitos. Critério verificável: processJobWithFaultTolerance com o cenário 'unavailable' deve terminar com needsReview: true, job.review_status === 'needs_review', o breaker em estado 'OPEN', e o número de tentativas registradas menor ou igual ao failureThreshold configurado — mesmo pedindo maxAttempts: 10. Solução comentada: o teste correspondente roda exatamente esse cenário com failureThreshold: 2 e confirma result.attempts.length <= 3 (duas chamadas reais mais, no máximo, uma tentativa de fallback já contabilizada) em vez de dez, provando que o breaker interrompe a tentativa antes do limite nominal de retries ser alcançado.

Avançado — simular rollback com jobs v1/v2 e executar o restore drill, registrando RPO/RTO medidos e limitações. Critério verificável: findJobsNeedingReconciliation sobre uma lista com um job v1 sem a regra nova, um job v2 com uma única aprovação e um job v2 com duas aprovações distintas deve devolver exatamente o segundo job; runRestoreDrill({ corrupt: false }) deve devolver success: true com jobCountMatches e statusesMatch verdadeiros, e runRestoreDrill({ corrupt: true }) deve devolver success: false com uma mensagem de erro de checksum. Solução comentada: rodar node examples/operations/restore-drill.mjs diretamente imprime os dois relatórios completos — nesta sessão, o drill normal mediu 1 a 3 milissegundos de rtoMsMeasured para quatro jobs sintéticos, contra uma meta didática de até 30 minutos (DIDACTIC_TARGETS.rtoMinutes) para uma hipotética implantação de produção; um teste dedicado ("didactic RPO/RTO targets are clearly separated...") existe só para impedir que esses dois números — milissegundos medidos e minutos de meta — sejam comparados como se fossem a mesma unidade ou o mesmo tipo de evidência.

Glossário curto

• Autorização por identidade+política: decisão de permitir ou negar um efeito que depende só de quem está pedindo e de uma tabela determinística, nunca do texto de um documento não confiável.
• Excessive agency: um agente com mais ferramentas, permissões ou autonomia do que a tarefa exige — categoria LLM06 da OWASP.
• Circuit breaker: componente que para de chamar um serviço com falha repetida, protegendo o serviço, sem nunca descartar o trabalho que estava sendo processado.
• Bulkhead: limite de concorrência por chave (tenant, provedor) que isola uma sobrecarga local do restante do sistema.
• Compatibilidade de schema (rollback): garantia de que um handler de versão antiga recusa — em vez de processar silenciosamente errado — um job que carrega uma regra que só a versão mais nova conhece.
• RPO (recovery point objective): quanto dado, em tempo, um sistema pode se dar ao luxo de perder num desastre — uma meta, não uma medição deste capítulo.
• RTO (recovery time objective): quanto tempo um sistema pode levar para voltar a funcionar depois de um desastre — também uma meta didática aqui, medida só contra um drill sintético local.
• Reconciliação: revisão humana de efeitos já executados sob uma versão que está sendo revertida; rollback desfaz código, reconciliação decide o que fazer com o que já aconteceu.

Ponte para o capítulo 8

Este capítulo assumiu que o RelayOps continua sendo um único serviço, um único worker pool, uma única fila — e nunca perguntou se essa forma ainda é a certa quando o volume cresce, quando um tenant domina a fila compartilhada, ou quando os tipos de documento variam o suficiente para que "um pipeline serve todos" pare de ser verdade. O capítulo 8 trata de escalar com evidência: que gargalo medido — não um diagrama bonito de microsserviços — justifica separar um serviço, particionar dados por tenant ou mudar de modelo, e como provar o benefício de cada mudança antes de a declarar concluída.