CEO Corner

O risco começa quando o conteúdo adquire autoridade

Uma injeção de prompt pode fazer a IA tratar material fornecido para análise como ordem para mudar seu comportamento. O National Cyber Security Centre britânico alerta contra presumir um limite de segurança confiável entre instruções e dados dentro do modelo.

Análise do NCSC

No exemplo, a tarefa inicial é preparar evidências. O anexo introduz outra: transmitir informações a um novo destinatário. A falha ocorre quando uma afirmação documental se transforma em permissão para agir. Um documento autêntico, remetente conhecido ou repositório interno não autoriza automaticamente todas as instruções que contém.

A distinção vale além dos seguros. Uma fatura pode propor novos dados bancários sem autorizar sua alteração. Um chamado pode pedir acesso elevado sem concedê-lo. Um relatório pode descrever uma transação sem permitir sua execução. É necessário separar pedido, evidências que o sustentam e decisão autorizada.

Eu pediria aos responsáveis de negócio que identificassem essas distinções nos processos manuais. A adoção de agentes deve explicitá-las no fluxo conectado. Caso contrário, a automação pode remover verificações informais feitas por pessoas experientes sem decisão consciente de eliminá-las.

Definir os limites de ação antes de conectar mais ferramentas

Eu separaria interpretação documental e autoridade para alterar registros ou comunicar externamente. O agente deve receber o acesso necessário ao caso, sem herdar uma conta técnica capaz de ler todas as apólices e enviar qualquer mensagem por conveniência de integração.

A OWASP identifica funcionalidade, permissões e autonomia excessivas como causas de capacidade de ação excessiva. . Minha resposta seria definir operações pequenas e explícitas, com condições impostas pela aplicação e pelos sistemas conectados, fora do julgamento do modelo.

OWASP LLM06

Uma proposta de envio deve indicar caso, finalidade permitida, identificadores dos documentos e destinatário. O serviço executor precisa verificar autoridade atual do usuário, vínculo com o caso, informações permitidas e situação verificada do destinatário. Deve rejeitar divergências mesmo diante de explicações persuasivas. Uma instrução geral para concluir o caso não pode virar permissão irrestrita de divulgação.

Esse desenho não exige clique humano em todo fluxo. Ações repetíveis de baixo risco podem ser pré-autorizadas sob condições estreitas e aplicáveis. O material recuperado durante a tarefa não pode ampliar essas condições. APIs e ferramentas Model Context Protocol (MCP) devem preservar essa disciplina; conectividade não concede confiança.

Tornar a aprovação específica e significativa

Uma tela que apenas pergunta se devemos continuar é fraca quando o revisor não enxerga a ação. No exemplo, quero destinatário, origem de sua verificação, documentos, finalidade e informações divulgadas claramente apresentados. Um resumo tranquilizador do agente não substitui esses detalhes.

A aprovação deve corresponder à operação revisada. Se o agente muda o destinatário, substitui um documento ou amplia o escopo, a permissão anterior não deve valer silenciosamente. A execução precisa conferir novamente os parâmetros aprovados e as permissões atuais, inclusive quando uma ação enfileirada ocorre após mudanças de acesso ou estado do caso.

A revisão humana exige condições de trabalho adequadas. Centenas de pedidos vagos sob pressão podem estimular aceitação automática. Eu reduziria aprovações desnecessárias para tarefas seguras e delimitadas, reservando revisão efetiva para ações importantes e combinações incomuns. O controle deve mostrar diferenças frente ao aprovado e permitir rejeitar ou investigar.

Um segundo agente não garante uma verificação independente

Um agente pode transformar a instrução do anexo em um resumo profissional. Outro lê o resumo, presume que o envio é procedimento padrão e o encaminha ao executor. A fonte original desaparece enquanto a instrução passa a parecer recomendação interna.

A identidade da fonte e seu nível de confiança devem sobreviver às transferências. Uma afirmação copiada continua sendo daquela fonte; outro agente repeti-la não cria autoridade gerencial. O controle independente deve se apoiar nas permissões e registros verificados da organização, não apenas no acordo entre modelos expostos ao mesmo material.

Também há respostas contaminadas sem uso de ferramentas. Omitir uma exceção ou distorcer uma cláusula pode influenciar uma decisão humana. Precisamos de controles de ação e de fidelidade das evidências preparadas. Restringir envios protege contra uma consequência, mas não prova a correção da orientação restante.

Testar consequências de negócio e o serviço legítimo

A OWASP recomenda privilégio mínimo e aprovação humana para operações de alto risco como mitigação de injeções de prompt. . Eu traduziria esses princípios em testes do processo real, usando registros sintéticos e destinos controlados.

OWASP LLM01

O teste deve acompanhar o que acontece após ler material suspeito. O agente propõe outra tarefa? A aplicação bloqueia destinatário não autorizado? Um anexo alterado invalida uma aprovação anterior? Um pedido inadequado continua bloqueado após resumo, resposta de ferramenta ou nova tentativa? O resultado esperado e o trabalho legítimo que deve continuar possível precisam ser definidos antes.

Eu separaria tentativas de atravessar limites de ações não autorizadas realmente executadas. Um modelo propor ação proibida e o executor negá-la corretamente é diferente de o modelo recusar por conta própria. Ambas as observações importam, mas só a visão completa mostra qual camada protegeu. Ausência de incidentes num teste pequeno não comprova impossibilidade futura.

Os testes devem incluir documentos comuns, idiomas suportados e ambiguidades realistas. Bloquear toda solicitação incomum pode parecer seguro enquanto inviabiliza serviços essenciais. É preciso medir bloqueios indevidos, tempo de revisão e conclusão legítima junto com falhas de segurança. Repita os testes pertinentes quando mudarem modelo, fontes, definições das ferramentas ou permissões.

Financiar a recuperação como capacidade operacional

Uma ação suspeita deve permitir suspender o caminho de execução afetado sem desativar desnecessariamente todos os serviços. Segurança e operações precisam identificar dados acessados, transmissões e alterações reais, credenciais envolvidas e ações ainda na fila. Logs devem ajudar sem espalhar conteúdo sensível pelos sistemas de monitoramento.

Conter não é reparar. Revogar uma credencial pode interromper novas ações, mas não recuperar dados já divulgados. Corrigir o prompt não desfaz uma alteração concluída. As equipes responsáveis precisam avaliar casos afetados, restaurar estado confiável quando possível, determinar notificações necessárias e aprovar a retomada.

O custo de um agente inclui integração controlada, capacidade de revisão, testes e recuperação. Isso faz parte de tornar confiável a produtividade prometida. Prefiro autorizar um fluxo limitado que resista a testes difíceis a financiar ampla autonomia cuja segurança dependa de instruir o modelo a se comportar.