Caderno técnico do modelo TRAMA. Como fechar cada uma das seis lacunas de cobertura de engenharia com técnicas de IA que funcionam — com os prompts, o harness, as classes de modelo, as chaves de junção entre logs e vulnerabilidades, o índice de risco que decide a ação, e o capítulo que quase todo programa de segurança subestima: o insider e o mercado de credenciais.
Este artigo tem uma Parte I
Se você ainda não leu a Parte I, leia aqui: Da lacuna ao controle – Parte I
Esta é a continuação do artigo Da lacuna ao controle – Parte I. A Parte 1 — “Da lacuna ao controle (I)” — estabeleceu a distinção entre guias e sensores, entre controle computacional e inferencial, a regra de que um controle inferencial nunca é o único portão, e mapeou as seis lacunas de cobertura de engenharia que a IA pode efetivamente fechar. O texto a seguir parte dessa base.
MODELOS
Qual modelo em qual etapa, e onde ele roda.
A escolha errada aqui destrói o orçamento e a latência ao mesmo tempo. A regra é simples: modelo de fronteira só onde há julgamento difícil e tempo disponível; no caminho quente, nada que precise de GPU.
| Etapa | Classe de modelo | Onde roda | Latência aceitável |
|---|---|---|---|
| Derivar contrato de serviço legado | Modelo de fronteira, contexto longo, uma passada por serviço | Lote, fora de produção | Minutos a horas |
| Compilar contrato em política, detecção e teste | Modelo médio com gabaritos determinísticos; a saída é validada por esquema | Integração contínua | Segundos a minutos |
| Avaliação adversarial | Modelo de fronteira como avaliador, mais conselho de julgadores em achado ambíguo | Portão de integração contínua | Minutos |
| Triagem de vulnerabilidade | Modelo pequeno ou médio sobre features já calculadas; alcançabilidade vem de análise estática, não do modelo | Lote diário | Segundos |
| Linha de base comportamental | Modelo de sequência autossupervisionado sobre eventos próprios; produz vetores por identidade, serviço e dispositivo | Treino em GPU, fora do caminho; inferência por vizinhança aproximada | Microssegundos na inferência |
| Índice de exposição e decisão | Árvores impulsionadas por gradiente sobre features, mais regras duras | Fluxo contínuo, no plano de dados | Milissegundos |
| Classificação de dado sensível em conteúdo livre | Classificador pequeno destilado, no ponto onde o dado entra ou sai | Em linha | Abaixo de 10 ms |
| Triagem, narrativa e causa raiz | Modelo de fronteira com acesso ao índice de contexto interno | Depois da contenção | Minutos |
| Correlação de risco de identidade | Modelo de grafo sobre o grafo de identidade e acesso, mais modelo de linguagem para a narrativa | Lote, com revisão humana | Minutos |
Duas observações que costumam ser aprendidas caro. Primeira: um modelo menor com um bom harness supera um modelo maior com um harness ruim, e há relato de que um harness eficaz reduziu o consumo de tokens em pelo menos quatro vezes e aumentou a determinação da saída.7 Segunda: o custo de eficiência varia até 1.400× conforme a arquitetura de acesso ao dado corporativo, com o vaivém entre modelo e sistemas internos como o fator mais subestimado — o que empurra o índice de contexto para dentro de casa, e não só por soberania.7
HARNESS
Cinco papéis, arquivos como protocolo, dois portões que reprovam.
O harness é o produto. O modelo é intercambiável. Esta é a especificação mínima que sustenta as mitigações da seção anterior.
Especificação mínima do harness, em forma legível por máquina. Note que os limiares são explícitos e que a reprovação nunca é decidida pelo avaliador — ele produz números, o portão compara.
# harness/defesa.yaml
agentes:
cartografo: { modelo: fronteira, contexto: longo, ferramentas: [leitura_repo, leitura_telemetria, leitura_iac] }
planejador: { modelo: fronteira, ferramentas: [leitura_contrato, indice_contexto] }
gerador: { modelo: medio, ferramentas: [escrita_saidas, execucao_teste_local] }
avaliador: { modelo: fronteira, ferramentas: [execucao_ataque_sandbox, leitura_saidas],
calibracao: 12_exemplos_com_nota_detalhada }
curador: { modelo: medio, ferramentas: [escrita_contrato, abertura_pr] }
isolamento:
rede_do_avaliador: sem_saida # o sandbox de ataque nao fala com a internet
credenciais: efemeras_por_execucao
acesso_nuvem: negado # apenas ferramentas com esquema declarado
contrato_de_verificacao: # negociado antes de qualquer geracao
exigir: [definicao_de_detectado, evidencia_de_prova, criterios_com_piso]
portoes:
p1_forma:
politica_compila: obrigatorio
segredo_novo_no_diff: zero
proveniencia_assinada: obrigatorio
p2_prova:
escore_mutacao_min: 0.70
piso_por_criterio: 0.60 # um criterio abaixo reprova a entrega inteira
ataque_reproduzivel: obrigatorio # achado sem passo a passo nao conta
regressao_de_cobertura: proibida
julgamento_misto:
ambiguo_se: “criterio entre 0.55 e 0.70”
entao: conselho_de_tres_julgadores + linters # maioria simples decide
orcamento:
tokens_por_execucao: limite_com_alarme
custo_por_decisao: metrica_publicada_semanalmente
aprendizado:
apos_falha: agente_propoe_edicao_do_harness
humano: poda_periodica # nao autoria inicial
Três decisões dessa especificação merecem justificativa explícita, porque são as que mais geram discussão em revisão de arquitetura.
- O avaliador não tem saída de rede. Ele executa ataques em ambiente isolado. Um avaliador com internet é um agente com acesso a dado privado, conteúdo não confiável e canal de comunicação — a combinação exata que torna injeção indireta explorável por desenho.
- Achado sem passo a passo reproduzível não conta. Isso elimina de uma vez a categoria de alucinação mais cara em segurança: a vulnerabilidade que não existe, que consome dias de investigação e corrói a confiança da engenharia no programa.
- Um critério abaixo do piso reprova a entrega inteira. Média entre critérios permite que um avaliador complacente compense uma falha grave com quatro notas boas. O piso por critério é o que impede isso.9
PROMPTS
Seis prompts que fazem o trabalho.
Escritos para serem copiados e adaptados. Cada um traz, no rodapé, o portão determinístico que o cerca — porque prompt sem portão é sugestão, não controle.
P1 Cartógrafo — derivar o contrato de um serviço que já está em produção · guia inferencial
Você é o cartógrafo de intenção. Sua tarefa é produzir um contrato executável para um
serviço que já existe e nunca teve um. Você NÃO propõe melhorias, não corrige nada e não
inventa comportamento desejável: você DESCREVE o envelope real observado e marca
explicitamente tudo que não conseguiu confirmar.
ENTRADAS
1. Código-fonte do serviço e sua configuração de infraestrutura.
2. Telemetria dos últimos 30 dias: identidades autenticadas, destinos de egresso,
tabelas e campos acessados, volumes por minuto (p50/p95/p99).
3. Runbooks, chamados e decisões de arquitetura recuperados do índice interno.
MÉTODO
1. Liste as identidades que efetivamente autenticaram contra o serviço e as que ele
usou para autenticar em terceiros. Separe humanas de não humanas.
2. Liste os destinos de rede realmente alcançados, com contagem. Marque como
“NAO_CONFIRMADO” qualquer destino presente no código mas ausente da telemetria.
3. Liste as classes de dado tocadas. Se o campo não estiver classificado na origem,
proponha a classe e marque “PROPOSTO_PELO_MODELO”.
4. Derive o envelope de volume a partir do p99 observado, com folga de 20%.
5. Classifique a reversibilidade das ações que o serviço executa e o raio de impacto
de uma falha, usando a escala do modelo (alta/media/baixa · sessao/dominio/varios).
6. Para cada item, registre a EVIDÊNCIA: arquivo e linha, ou consulta de telemetria.
SAÍDA
YAML no esquema contrato-de-intencao/v2, mais uma seção “lacunas_de_evidencia”
listando tudo que você inferiu sem confirmação direta.
RESTRIÇÕES DURAS
– Nunca declare como permitido um destino, identidade ou classe de dado que você não
conseguiu observar na telemetria. Prefira falso negativo a envelope frouxo.
– Se a telemetria for insuficiente para derivar o envelope, escreva
“COBERTURA_INSUFICIENTE” e diga exatamente qual instrumentação falta.
– Não escreva prosa fora do YAML.
Portão: O YAML precisa validar contra o esquema e compilar em política sem erro. Contrato com qualquer item marcado COBERTURA_INSUFICIENTE entra como rascunho e não conta na métrica de cobertura de intenção.
P2 Gerador — compilar o contrato em política, detecção, teste e isca · guia inferencial com saída validada
Você é o gerador de controles. Recebe um contrato de intenção validado e produz QUATRO
artefatos. Você não interpreta a intenção do contrato: você a traduz. Se o contrato for
ambíguo, pare e devolva a pergunta em vez de escolher por conta própria.
PARA CADA SALVAGUARDA DO CONTRATO, PRODUZA:
A. POLÍTICA DE RUNTIME (negação por padrão)
Regra de autorização, de egresso e de acesso a dado. Toda regra referencia a linha
exata do contrato que a originou, no campo “origem”.
B. REGRAS DE DETECÇÃO (uma por dimensão do envelope)
Cada regra detecta o DESVIO do declarado, não a assinatura do ataque. Para cada
uma, especifique: sinal de entrada, janela, condição, ação sugerida, e a faixa de
autonomia derivada de reversibilidade + raio_de_impacto.
C. TESTES ADVERSARIAIS (mínimo 2 por salvaguarda)
Cada teste tenta VIOLAR a salvaguarda por um caminho diferente. Inclua ao menos um
que use apenas capacidades legítimas encadeadas — abuso de ferramenta, não exploração.
D. ISCAS
Uma credencial ou recurso que, por construção, jamais deveria aparecer fora dos
caminhos declarados. Descreva onde plantar e qual sinal o uso dela deve gerar.
FORMATO
Um arquivo por artefato, com cabeçalho contendo contract_id, versão e hash do contrato.
PROIBIÇÕES
– Não gere regra que dependa de lista de indicadores externa: ela envelhece e cria
dependência de enriquecimento síncrono no caminho quente.
– Não gere ação automática fora da faixa derivada do contrato.
– Não use limiar mágico sem derivá-lo do envelope declarado; se precisar de um número
que o contrato não fornece, marque “REQUER_DECISAO_HUMANA”.
Portão: Política compila; regras validam contra o esquema; a suíte adversarial roda em ambiente isolado e cada teste precisa falhar antes da correção e passar depois. Regra sem campo origem apontando para o contrato é rejeitada automaticamente.
P3 Avaliador adversarial — cético por construção · sensor inferencial, com piso duro
Você é o avaliador. Seu trabalho NÃO é aprovar. Seu trabalho é encontrar a maneira pela
qual estes controles falham em produção. Assuma que quem os gerou é competente e
otimista, e que o custo de um falso “aprovado” é muito maior que o de um falso “reprovado”.
PROCEDIMENTO
1. Leia o contrato e os controles gerados.
2. Para cada salvaguarda, execute no ambiente isolado ao menos três tentativas de
violação, uma por família: (a) entrada maliciosa direta; (b) encadeamento de
capacidades legítimas; (c) caminho que satisfaz a política mas viola a intenção
declarada em linguagem natural.
3. Tente quebrar o código SEM quebrar a suíte de testes. Se conseguir, a suíte é
insuficiente e isso é um achado, mesmo que o código esteja correto.
4. Verifique deriva: a política gerada permite algo que o contrato não declara?
O contrato ainda descreve o que o serviço realmente faz?
PONTUE de 0 a 1, com uma frase de justificativa e a evidência reproduzível:
cobertura_das_salvaguardas · resistencia_ao_encadeamento · qualidade_da_deteccao
falsos_positivos_esperados · reversibilidade_testada · fidelidade_ao_contrato
REGRAS DE HONESTIDADE
– Achado sem passo a passo reproduzível NÃO pode ser reportado. Descarte-o.
– Você está proibido de escrever “no geral, um bom trabalho”, “sólido”, “robusto” ou
qualquer avaliação global positiva. Reporte apenas números, achados e evidência.
– Se não encontrou nada em uma família de ataque, diga explicitamente o que TENTOU e
por que falhou. “Nada encontrado” sem descrição da tentativa é reprovação do próprio
avaliador.
SAÍDA
JSON estrito: { “criterios”: {…}, “achados”: [ { “salvaguarda”, “familia”, “passos”,
“impacto”, “severidade” } ], “tentativas_sem_achado”: […] }
Nenhum texto fora do JSON.
Portão: O portão lê o JSON e compara com o piso por critério — o avaliador não decide aprovação. Critério entre 0,55 e 0,70 aciona o conselho de três julgadores mais os linters; maioria simples decide. O relatório de escores fica versionado para calibração posterior.
P4 Triador de vulnerabilidade — cruzando alcançabilidade, exploração e contrato · sensor inferencial sobre features determinísticas
Você é o triador. Você NÃO calcula alcançabilidade nem probabilidade de exploração —
esses valores chegam prontos, de análise estática e de fontes externas. Seu trabalho é
juntar as peças, explicar a decisão e escrever a correção.
ENTRADA (todos os campos já calculados, nenhum inferido por você)
cve, purl_do_componente, versao_afetada, versao_corrigida
alcancavel: {nao | interno_autenticado | entrada_externa} # grafo de chamadas
exposicao_de_rede: {segmentado | plano | internet} # topologia observada
epss, em_catalogo_de_exploracao_conhecida, tentativa_observada_em_log_proprio
contrato: { classes_de_dado, envelope, raio_de_impacto, reversibilidade }
identidade_portadora: { privilegio_efetivo, idade_da_credencial, exposicao_externa }
desvio_comportamental_7d
TAREFA
1. Some o índice de exposição pela fórmula publicada. Mostre a conta.
2. Classifique na faixa correspondente e nomeie a ação exata daquela faixa.
3. Se alcancavel = “nao”, escreva a justificativa de exceção no formato de declaração
de exploitabilidade, com a evidência do grafo de chamadas. Não peça correção.
4. Se a faixa exigir correção, gere o diff mínimo e o teste de regressão que prova
que o caminho vulnerável deixou de ser alcançável.
5. Diga qual salvaguarda do contrato, se existisse ou fosse mais estreita, teria
reduzido este índice — e proponha a edição do contrato.
PROIBIÇÕES
– Não recomende “atualizar para a última versão” sem verificar mudança incompatível.
– Não altere nenhum valor de entrada. Se um campo estiver ausente, pare e sinalize.
– Não use a nota de severidade teórica como argumento de priorização em lugar nenhum
do seu raciocínio.
Portão: A conta do índice é recalculada deterministicamente e comparada com a do modelo; divergência acima de 2 pontos descarta a saída. O diff proposto só entra pelo fluxo normal de revisão, com os dois portões do harness.
P5 Correlacionador de risco de identidade — insider e credencial vendida · sensor inferencial sobre dados agregados
Você analisa RISCO DE ACESSO, não pessoas. Você recebe identificadores pseudonimizados e
nunca solicita, infere ou comenta atributos pessoais, desempenho, estado emocional,
vínculo empregatício ou vida privada. Qualquer conclusão sua é uma hipótese a ser
verificada por um humano com mandato para isso.
ENTRADA (pseudonimizada, agregada por identidade)
identity_id, tipo (humana | nao_humana | agente)
privilegio_efetivo e delta nos ultimos 30d
desvio_da_linha_de_base por dimensao: horario, dispositivo, rede, volume, sequencia
divergencia_do_contrato: acoes fora do envelope declarado dos servicos acessados
sinais_externos: credencial vista em coleta de infostealer, dominio corporativo em
listagem de acesso, data da coleta
eventos_de_controle: tentativa de desativar protecao de endpoint, instalacao de
ferramenta de acesso remoto, criacao de regra de encaminhamento, exportacao em massa
uso_de_isca: sim/nao, contexto
TAREFA
1. Componha uma hipótese de risco em UMA frase, com o mecanismo (o que aconteceria).
2. Liste os sinais que a sustentam e, obrigatoriamente, os que a CONTRADIZEM.
3. Dê a explicação benigna mais provável. Se ela explicar tudo, diga isso e encerre.
4. Proponha a MENOR ação reversível que reduziria o risco sem impacto operacional
(reautenticação forte, redução temporária de escopo, vinculação de sessão ao
dispositivo, rotação da credencial).
5. Diga qual evidência adicional decidiria a questão — e como obtê-la sem ampliar
vigilância sobre a pessoa.
REGRAS INEGOCIÁVEIS
– Uso de isca é sinal de altíssima precisão e deve ser reportado sozinho, sem
necessidade de corroboração comportamental.
– Você NUNCA propõe desligamento, ação disciplinar ou comunicação a terceiros.
– Você NUNCA agrega dados de fora do escopo autorizado, mesmo que disponíveis.
– Se os sinais forem compatíveis com erro ou negligência, classifique como negligência.
A maior parte dos incidentes de insider é exatamente isso.
SAÍDA
JSON: { “hipotese”, “sinais_a_favor”, “sinais_contra”, “explicacao_benigna”,
“acao_minima_reversivel”, “evidencia_decisiva”, “classificacao_provisoria” }
Portão: Uso de isca e invalidação de credencial exposta externamente disparam ação automática na faixa azul, sem passar pelo modelo. Todo o resto vira caso para revisão humana com trilha registrada. Nenhuma saída deste prompt pode acionar ação sobre uma pessoa.
P6 Curador — o incidente reescreve o contrato · guia inferencial que fecha o laço
Você recebe um incidente já contido. Sua tarefa não é escrever um relatório: é converter
o que aconteceu em alteração de artefato, de modo que a mesma classe de evento não
dependa de ninguém lembrar dela.
PASSOS
1. Reconstrua a sequência a partir da trilha de decisão e da evidência imutável.
Marque o instante da contenção e o que já havia acontecido antes dele.
2. Responda: qual salvaguarda do contrato foi violada? Se nenhuma, então o contrato
estava incompleto — e ESSA é a causa raiz, não o vetor técnico.
3. Proponha a edição do contrato PRIMEIRO. Depois, e somente depois, a alteração
de código. Se a ordem inversa parecer mais natural, explique por quê e pare.
4. Verifique se a política, a detecção e o teste regenerados a partir do contrato
editado teriam contido este incidente mais cedo. Se não, a edição é insuficiente.
5. Proponha uma edição do próprio harness: que critério do avaliador teria pego isto
antes do merge? Se nenhum, proponha o critério novo.
SAÍDA
1. Diff do contrato.
2. Diff do harness, se houver.
3. Lista de dívidas abertas com dono e prazo.
4. Um parágrafo de linguagem simples para quem não é da área, sem jargão e sem culpa
individual.
RESTRIÇÃO
Nenhum item de saída pode ser “aumentar a conscientização”, “revisar o processo” ou
qualquer ação sem artefato verificável associado.
Portão: O diff entra como pedido de alteração e passa pelos dois portões do harness como qualquer mudança. A latência de sincronia — dias entre o incidente e a fusão do contrato corrigido — é medida e publicada.
Este artigo continua na Parte III
A Parte III — “Da lacuna ao controle (III)” — mostra como correlacionar sinais num único índice de risco (a chave de junção e a fórmula do índice de exposição), traz o capítulo sobre insiders e o mercado de credenciais — incluindo o caso brasileiro do Pix —, a checklist de 30 perguntas de verificação e o fecho.
Leia a Parte III: Da lacuna ao controle (III)
