Proteger chamadas de ferramentas de chatbots IA: Direitos, confirmação e plano de reversão

Um chatbot para websites muda fundamentalmente a partir do momento em que deixa de apenas responder e passa a poder desencadear ações. Uma consulta de agendamento é algo simples. No entanto, um cancelamento, uma alteração de endereço ou um reembolso alteram o estado real do negócio. O modelo de linguagem pode sugerir a chamada de uma ferramenta adequada. Contudo, saber se a ação é permitida deve ser decidido por uma camada de aplicação separada e determinística. Chamadas de ferramentas seguras em chatbots de IA não surgem de um prompt de sistema especialmente rigoroso, mas sim de funções limitadas, verificação de permissões no lado do servidor, uma confirmação clara e um fluxo de execução controlado.

Por que um bom modelo de linguagem não substitui a autorização

Um modelo trabalha com probabilidades. Ele pode interpretar mal uma intenção, adicionar um parâmetro ou reagir a conteúdos manipulados. A descrição de risco da OWASP sobre Excessive Agency aponta três causas típicas: funcionalidade excessiva, permissões demasiado abrangentes e demasiada autonomia. O problema não é apenas uma entrada maliciosa. Uma solicitação ambígua ou um erro plausível do modelo também pode preparar uma ação indesejada.

A regra de arquitetura mais importante é: o modelo formula uma proposta, mas a aplicação autoriza e executa. Uma chamada de ferramenta como cancelAppointment é, inicialmente, apenas uma intenção estruturada. Só uma verificação de política (Policy Check) valida o utilizador, o tenant, o objeto, a ação permitida, o estado atual e a confirmação necessária. Esta separação complementa a proteção contra Prompt Injection em chatbots de websites; ela continua a ser necessária mesmo quando nenhum ataque foi detetado.

Classificar cada ferramenta pelo seu impacto e não pelo nome

As equipas não devem classificar todo o chatbot de forma genérica como "seguro" ou "crítico". O fator decisivo é o impacto de cada ferramenta individual. Uma matriz de risco simples traz clareza:

• Leitura e pouco sensível: consultar horários de funcionamento ou informações de produtos publicamente disponíveis.
• Leitura e dados pessoais: exibir o estado de uma encomenda ou dados do cliente; para tal, deve-se verificar a identidade, o tenant e a associação ao objeto.
• Escrita, mas facilmente reversível: criar um pedido de contacto interno ou adicionar uma nota não vinculativa.
• De alto impacto ou difícil reversão: cancelar uma reserva, alterar dados de contacto, publicar conteúdos, enviar mensagens ou iniciar pagamentos.

A partir desta classe determinam-se os direitos, o nível de confirmação, os limites e o registo (logging). Uma autorização genérica como "O chatbot pode usar o CRM" é demasiado vaga. É preferível ter uma lista de capacidades concretas com parâmetros definidos e transições de estado permitidas.

Least Privilege começa na definição do escopo das funções

O OWASP Authorization Cheat Sheet recomenda o princípio do Menor Privilégio (Least Privilege) e Deny by Default. Para chamadas de ferramentas, isto significa: o chatbot recebe apenas a função e o segmento de dados estritamente necessários para cada etapa.

Ferramentas pequenas em vez de interfaces universais

Uma ferramenta getOrderStatus(orderId) é mais fácil de proteger do que um acesso livre à base de dados. Uma ferramenta requestCallback(topic, timeWindow) é mais controlável do que uma função genérica para enviar mensagens arbitrárias. Funções abertas de SQL, Shell, URL ou e-mail aumentam desnecessariamente o impacto potencial. Ferramentas de teste que já não sejam necessárias também devem ser removidas do catálogo de produção.

Executar no contexto do utilizador autenticado

O backend não pode confiar apenas no facto de o modelo passar o ID de cliente correto. Deve derivar o utilizador e o tenant atuais a partir da sessão confiável e verificar novamente se existe acesso a cada objeto. A diferença prática entre um chat público e uma área reservada é explicada em detalhe no artigo sobre Identidade e Acesso a Dados no Portal do Cliente. Uma conta de serviço geral com acesso total é quase sempre o atalho errado para ações focadas no utilizador.

Validar parâmetros de forma determinística

Os parâmetros das ferramentas precisam de um esquema rigoroso: campos permitidos, tipos, comprimentos, intervalos de valores e regras de estado. O ID de um agendamento deve pertencer ao utilizador, a data deve estar dentro de um intervalo válido e a ação deve corresponder ao estado atual. Campos desconhecidos são rejeitados. A aplicação deve também garantir que o próprio nome da ferramenta provém de uma allowlist fixa e não é executado a partir de texto gerado livremente.

A confirmação deve mostrar a ação real

Para alterações de alto impacto, a pergunta "Tem a certeza?" não é suficiente. A diretriz da OWASP sobre Autorização de Transações descreve o princípio "What You See Is What You Sign": os utilizadores devem poder visualizar e confirmar os dados essenciais da ação concreta. Para um chatbot de website, isto significa, por exemplo:

• "Cancelar agendamento de 18 de agosto às 14:30" em vez de "Confirmar alteração"
• "Alterar endereço de entrega da encomenda ...84 para Lisboa" em vez de "Guardar dados"
• "Criar pedido de contacto com o tema Faturação" em vez de "Enviar pedido"

A confirmação é vinculada no lado do servidor exatamente a esse rascunho de ação. Se o destino, valor, data, destinatário ou outros parâmetros essenciais mudarem, a confirmação expira. Ela recebe um prazo de validade curto e não pode ser reutilizada para uma segunda ação. Para operações altamente críticas, pode ser necessária uma reautenticação ou aprovação por uma pessoa. O modelo não deve saltar esta etapa nem substituí-la por uma resposta de tom apaziguador.

Planear idempotência, limites e plano de reversão

Mesmo uma chamada de ferramenta corretamente autorizada pode chegar duplicada por razões técnicas: o navegador repete um pedido, um timeout aciona um retry ou o utilizador envia a mesma mensagem novamente. Ferramentas de escrita devem, por isso, utilizar um ID de idempotência no lado do servidor. Para o mesmo ID, a mesma ação é executada no máximo uma vez; uma nova tentativa recebe o resultado já conhecido.

Além disso, cada ferramenta precisa de limites adequados: número máximo de chamadas por sessão, timeouts curtos, retries limitados e interrupção em cadeias invulgares. Antes da execução, o backend verifica o estado novamente. Dessa forma, uma reserva já cancelada não é processada uma segunda vez. Sempre que possível, a ação deve ser criada inicialmente como rascunho ou pedido pendente. Para alterações diretas inevitáveis, deve estar claro como compensar, revogar ou transferir a situação para uma equipa de suporte. Um modo degradado e plano de reversão bem preparados evitam o improviso durante uma falha.

Registar dados sem recolher segredos

Um registo de segurança (audit log) deve conseguir responder a quem autorizou qual ação, com base em quê e com que resultado foi executada. É útil incluir: ID do ator pseudonimizado, ferramenta e versão, referência do objeto, versão da política, decisão de autorização, ID de confirmação, ID de idempotência, carimbo de data/hora e resultado. Palavras-passe, tokens, históricos completos de chat e dados pessoais desnecessários não devem constar deste registo.

O OWASP AI Agent Security Cheat Sheet recomenda dados de decisão estruturados para ações de alto risco e a separação entre decisão e execução. Isto é diferente de um rastreio técnico completo (tracing): para a auditoria de segurança, o que conta é uma prova concisa e consistente da cadeia de autorização. O armazenamento e o acesso devem alinhar-se com a real necessidade de verificação.

Uma arquitetura robusta em cinco camadas

1. Diálogo e proposta: O modelo reconhece a intenção e gera um rascunho de ação estruturado, mas não executa nada diretamente.
2. Decisão de política: Um componente determinístico verifica a allowlist de ferramentas, utilizador, tenant, objeto, parâmetros, classe de risco e limites.
3. Confirmação: A interface exibe os dados essenciais da ação. A autorização é temporária e está vinculada ao rascunho inalterado.
4. Execução: Um executor com escopo restrito verifica a autorização novamente imediatamente antes da chamada e utiliza um ID de idempotência.
5. Rastreabilidade e resposta: Resultado, erros e a cadeia de autorização são registados com minimização de dados; alertas, compensação e intervenção humana estão definidos.

O NIST AI RMF Core enquadra estas tarefas em Govern, Map, Measure e Manage. Na prática, isto significa: definir responsabilidades e limites de risco, compreender o contexto de utilização, testar os controlos e reagir a desvios observados.

Matriz de testes antes do Go-Live

Apenas testes positivos não são suficientes. Uma ferramenta também deve falhar de forma segura sob condições adversas. No mínimo, os seguintes casos devem fazer parte de uma matriz de testes repetível:

• Um utilizador não autenticado ou sem permissão solicita a ação.
• Uma sessão válida faz referência a um objeto de outro tenant.
• Parâmetros essenciais alteram-se após a confirmação.
• O mesmo pedido é repetido devido a timeout ou duplo clique.
• Uma ferramenta devolve instruções manipuladas ou campos adicionais inesperados.
• Uma chamada excede os limites de tempo, quantidade ou custo.
• O sistema de destino falha entre a verificação e a execução.
• Uma permissão é revogada imediatamente antes da execução.

O esperado não são apenas ações bem-sucedidas, mas recusas claras, dados inalterados e eventos de segurança úteis. Antes de ativar o acesso de escrita para utilizadores reais, o fluxo pode ser testado em Shadow Mode com pedidos reais, sem executar as ações propostas.

Checklist para equipas de websites

• Cada ferramenta é pequena, com propósito específico e pertence a uma allowlist fixa?
• O utilizador, tenant, objeto e ação são verificados no lado do servidor?
• O Deny by Default e as permissões técnicas mínimas são aplicados?
• Os utilizadores vêm todos os dados essenciais antes de ações críticas?
• A confirmação expira em caso de alterações e após um curto período?
• Um ID de idempotência previne execuções duplicadas?
• Existem limites, timeout, interrupção, compensação e transição para suporte humano (Human Handoff)?
• Tokens, segredos e dados pessoais desnecessários ficam fora dos logs?
• A matriz de testes cobre erros de permissão, manipulação, retries e falhas?

Conclusão: O modelo sugere, a aplicação decide

Um chatbot de website capaz de executar ações não precisa de começar com acesso total. Comece com uma ação restrita e reversível, e construa a cadeia de autorização de forma visível ao seu redor. Quando o escopo da ferramenta, a autorização no servidor, a confirmação concreta, a idempotência e o plano de reversão são desenhados em conjunto, o chat continua útil sem dar ao modelo o papel de um sistema de segurança. Para o próximo passo, vale a pena realizar um workshop com os responsáveis de produto, desenvolvimento, suporte e proteção de dados: escolha uma ação real, classifique o seu risco e defina o caso de rejeição segura antes da primeira autorização em produção.