Edição de 29/09: validar a resposta antes de a tornar ação

A fronteira é o destino da resposta

Uma PME quer transformar conversas de assistência em notas para o seu sistema interno. A resposta chega em formato estruturado e contém uma descrição do problema. A questão relevante não é apenas se o texto está correto: é o que a aplicação fará com cada campo.

Propomos desenhar o percurso completo, desde a resposta recebida até à apresentação e eventual atualização de um registo. Uma descrição deve continuar a ser descrição. Um identificador deve ser verificado como identificador. O modelo pode sugerir uma operação, mas não deve decidir que o destino tem autorização para a executar.

O que a OWASP distingue

OWASP LLM05 identifica riscos quando respostas são encaminhadas sem validação adequada para destinos como shell, browser ou consultas SQL. LLM06 trata separadamente a autoridade excessiva e recomenda autorização a jusante. O NIST AI RMF é voluntário. Não inferimos destes documentos que qualquer resposta produzida seja explorável.

Separar estrutura, conteúdo e autoridade

O nosso desenho começa por uma estrutura fechada: campos esperados, tipos e comprimentos definidos pela aplicação. Valores extra ou ausentes levam a rejeição legível ou revisão, não a uma adaptação silenciosa que invente a intenção do utilizador. Aceitar a estrutura não autoriza o conteúdo.

Depois cada destino recebe uma regra própria. A nota apresentada deve ser tratada como texto ou passar por uma política explícita de formatação permitida. Atualizações de registos usam operações definidas pela aplicação e parâmetros verificados. Caminhos de ficheiro, comandos e consultas livres não pertencem a este caso de uso e ficam fora do contrato.

O caso válido por fora e perigoso por dentro

Cenário hipotético: a resposta respeita a estrutura, mas inclui uma descrição com marcação ativa e um link para um destino não aprovado. O ensaio deve introduzir marcadores sintéticos inofensivos e observar o resultado final. Não precisamos de executar uma exploração real para verificar que o conteúdo deixou de ser tratado como texto.

Inclua uma nota demasiado longa, identificador de outro cliente e operação não prevista. A equipa de teste conserva resposta bruta com dados sintéticos, decisão de validação e efeito observado no destino. Uma mensagem de erro no ecrã não prova ausência de atualização: confira também o registo que a aplicação tentava alterar.

Aceitar por destino, não por impressão

Esta matriz original define provas diferentes para apresentação e escrita. O dono da aplicação aprova o contrato de campos; segurança verifica os casos de fronteira. Um campo recusado não deve ser reenviado automaticamente por outro percurso menos restritivo. Esse comportamento também pertence ao ensaio.

Depois da rejeição, preservar o trabalho útil

Propomos uma fila de revisão onde a pessoa vê a nota rejeitada de forma segura, o motivo e os campos a corrigir. Reutilizar o texto não significa herdar uma operação rejeitada. A correção produz um novo pedido sujeito às mesmas verificações e ao âmbito da identidade que o apresenta.

Numa PME portuguesa, a autorização pode continuar manual para as primeiras escritas, mesmo que a apresentação já tenha passado o ensaio. Registe essa diferença em vez de declarar o sistema inteiro validado. Reveremos o plano quando mudar o renderizador, o contrato de campos ou o destino de escrita. Não reportamos testes executados, eficácia garantida ou experiência interna.