Chatbot de IA Público vs. Portal do Cliente: Separar Identidade e Acesso a Dados com Segurança

Um chatbot num site público pode responder a perguntas sobre produtos, explicar horários de funcionamento ou encaminhar para a página de serviço adequada. Contudo, assim que passa a consultar o estado de encomendas, contratos, faturas ou pedidos de suporte num portal do cliente, não é apenas o conteúdo que muda. Surge uma nova fronteira de segurança. Um chatbot de IA autenticado deve separar claramente identidade, permissões, sessão e ações concretas.

Por isso, a decisão arquitetural mais importante não é: „Qual modelo devemos utilizar?“. É antes: „Que informação e que ação são permitidas em cada zona de confiança?“. Responder a esta questão antes do design do prompt reduz fugas de dados, associações incorretas de contas e ações indesejadas. O guia seguinte constitui uma orientação técnica e organizacional, não uma consultoria jurídica individual.

Por que público e autenticado são dois modos de operação distintos

No chat público, a pessoa é inicialmente desconhecida. O sistema pode conhecer, no máximo, o contexto da conversa, o idioma selecionado e os dados de sessão tecnicamente necessários. As respostas devem, portanto, limitar-se a fontes autorizadas e de acesso geral. Um endereço de e-mail inserido, um número de encomenda ou uma afirmação como „Este é o meu contrato“ não constituem comprovativo de autorização.

Por outro lado, no portal do cliente existe uma sessão com sessão iniciada. Contudo, mesmo aí, o início de sessão não significa automaticamente que todas as fontes e ações sejam permitidas. A OWASP Authentication Cheat Sheet distingue autenticação, verificação de identidade e gestão de sessão. As recentes NIST Digital Identity Guidelines, Revisão 4 também tratam a verificação de identidade, autenticação e federação como blocos independentes. Para as equipas de desenvolvimento web, isto significa: o chat só pode utilizar os sinais de confiança comprovadamente fornecidos pelo sistema envolvente.

Três zonas em vez de um chatbot omnipotente

Uma solução sólida divide o conhecimento e as ferramentas em pelo menos três zonas:

• Zona pública: conteúdos do site autorizados, informações gerais sobre produtos, processos, canais de contacto e assistência não vinculativa.
• Zona autenticada: dados e processos associados à conta com sessão iniciada, a uma organização, função ou permissão.
• Zona especialmente protegida: alterações sensíveis, pagamentos/reembolsos, celebração de contratos, novos endereços de entrega, alteração de permissões ou outras ações que exijam confirmação adicional ou verificação humana.

Estas zonas não devem constar apenas no prompt do sistema. Têm de estar mapeadas em fontes de dados, APIs, funções, permissões de ferramentas e verificações no lado do servidor. Um prompt pode orientar o comportamento, mas não é um controlo de acessos. O mesmo se aplica ao RAG: realizar pesquisas em documentos públicos e privados num índice comum e não filtrado cria uma superfície de ataque desnecessariamente ampla.

Autenticação não é autorização

De forma simplificada, a autenticação responde a: „Qual é a identidade digital com sessão iniciada?“. A autorização responde a: „Esta identidade tem permissão para ler precisamente este objeto ou executar esta função?“. Esta diferença é facilmente esbatida no chat, uma vez que os utilizadores formulam identificadores de forma natural: „Mostra-me a fatura 4711“ ou „Altera o endereço da encomenda 815“.

As recomendações da OWASP contra IDOR exigem uma verificação de permissão no nível do objeto, mesmo que os identificadores sejam difíceis de adivinhar. Na prática, isto significa que o servidor deduz a conta atual a partir da sessão protegida e verifica, a cada pedido, se a fatura, encomenda ou pedido de suporte pertence a esse espaço de dados permitido. O modelo de linguagem não pode aceitar um ID de cliente ou de objeto introduzido livremente como âncora de confiança.

O que o chat público do site pode responder

Para a área pública, uma lista de permissões (allowlist) é preferível a uma longa lista de proibições. Podem estar autorizados, por exemplo, prazos de devolução, regiões de entrega, características dos produtos, tutoriais, estrutura geral de preços ou o caminho para iniciar sessão. Não estão autorizados estados de encomendas individuais, detalhes de contratos, agendamentos pessoais, notas internas ou a confirmação de que uma determinada conta existe.

Mesmo respostas aparentemente inofensivas podem revelar informações. „Não existe nenhuma conta associada a este endereço de e-mail“ confirma uma tentativa de verificação. Uma resposta neutra como „Inicie sessão no portal do cliente para aceder a informações relativas à conta“ mantém o limite seguro. Para tentativas de manipulação, são necessárias medidas de proteção adicionais, conforme descrito no artigo Prompt Injection em Chatbots de Sites.

O que o chatbot de IA autenticado necessita adicionalmente

Após o início de sessão, o assistente ganha mais autonomia, mas apenas dentro do contexto determinado pelo servidor. Dados de entrada adequados incluem uma referência interna de sessão, a organização ou cliente (tenant) permitido, funções e um conjunto restrito de funcionalidades. Credenciais brutas, palavras-passe, tokens de sessão completos ou campos de dados pessoais desnecessários não devem ser incluídos no contexto do modelo.

A OWASP Authorization Cheat Sheet recomenda verificações de autorização para cada recurso e função concretos. No contexto de chamadas de ferramentas, isto significa: não é o modelo que decide se uma fatura pode ser vista. O modelo solicita a informação permitida a um serviço; este serviço volta a verificar a sessão, a função, o cliente (tenant) e o objeto. O chat recebe apenas os campos estritamente necessários para a resposta.

Como definir limites práticos para dados e ferramentas

As operações de leitura e de escrita devem ser ferramentas distintas. Uma ferramenta como „gerir conta de cliente“ é demasiado abrangente. É preferível utilizar funções focadas, tais como „listar encomendas em aberto próprias“, „ler estado de uma encomenda permitida“ ou „preparar pedido de suporte“. Cada função deve ter um esquema de entrada mínimo, validação de permissões no lado do servidor, tratamento claro de erros e uma saída delimitada.

Para a RAG recomenda-se a mesma lógica: fontes públicas num espaço de pesquisa público; documentos associados à conta num espaço de pesquisa filtrado por cliente (tenant) e função. Os filtros são gerados no lado do servidor com base na sessão, nunca a partir de dados introduzidos livremente no chat. As alterações a fontes, funções e aprovações devem seguir um procedimento documentado; pode encontrar um modelo no artigo sobre Content Governance e Controlo de Alterações.

Considerar a expiração de sessão, terminar sessão e dispositivos partilhados

A interface do chat não deve transmitir a ideia de que uma permissão permanece ativa indefinidamente. A OWASP Session Management Cheat Sheet descreve a sessão como a ligação entre a autenticação, o tráfego HTTP e o controlo de acessos. Se a sessão expirar, a tentativa seguinte de aceder a dados privados tem de falhar com segurança. Uma resposta antiga no histórico visível não pode ser interpretada como uma nova permissão.

As equipas devem também testar o encerramento de sessão, a alteração de conta, a mudança de função e a utilização em dispositivos partilhados. Os históricos de conversa privados não podem surgir na conta seguinte após a troca. Em caso de sessão expirada, o assistente deve direcionar claramente o utilizador para iniciar sessão novamente, sem repetir detalhes sensíveis da sessão anterior. Quanto ao registo e à análise, aplica-se o princípio da minimização de dados; o artigo sobre analítica de chatbot com minimização de dados apresenta limites adequados para eventos e retenção.

Ações sensíveis exigem uma confirmação dedicada

Efetuar o login no portal não é necessariamente suficiente para todas as ações. Quando o chat altera um endereço de entrega, confirma um contrato ou desencadeia um pagamento, o sistema deve solicitar uma confirmação clara e específica para essa ação. A OWASP Transaction Authorization Cheat Sheet separa o login da autorização de transação, exigindo controlos no lado do servidor e validação dos dados fundamentais da transação.

Um padrão seguro é o seguinte: o chat regista o pedido e apresenta um resumo claro; o portal verifica a permissão atual e, se necessário, solicita uma nova autenticação ou um segundo fator de autenticação. Só depois disso é que um serviço no servidor executa a ação rigorosamente confirmada. Se o destino, o valor ou outros dados essenciais forem alterados, a autorização prévia é anulada.

Exemplo: devolução sem fuga de dados

Uma pessoa anónima pergunta: „Posso devolver a minha encomenda?“. O chat público explica a lógica geral de devolução e disponibiliza um link para o portal. Não solicita o endereço completo nem dados de pagamento. Após o login, o chat do portal pode listar as encomendas elegíveis para devolução da própria pessoa através de uma ferramenta de leitura. Quando a pessoa seleciona uma encomenda, o servidor volta a verificar a permissão do objeto e as regras aplicáveis.

Para proceder à devolução efetiva, uma ferramenta de ação separada gera um resumo. A pessoa confirma os artigos e a opção de recolha na interface do portal. Se a verificação falhar, o chat não revela sinais internos de risco, mas oferece um próximo passo seguro. Caso seja necessária uma clarificação humana, realiza-se uma transição para atendimento humano (Human Handoff) controlada, contendo apenas o contexto necessário e autorizado.

Matriz de testes antes do Go-Live

Uma matriz de testes não deve validar apenas cenários ideais (happy paths). Utilize pelo menos duas contas com funções semelhantes e dados separados e teste os seguintes cenários:

• Pedido anónimo de informações gerais e de dados privados da conta.
• Conta A com sessão iniciada lê um objeto próprio e, em seguida, tenta aceder ao identificador de um objeto da Conta B.
• Sessão expirada, encerramento de sessão, alteração de conta e revogação de funções durante um chat ativo.
• Mudança de idioma a meio do processo, sem alteração do espaço de dados ou da permissão.
• Prompt Injection nas entradas do utilizador e nos documentos recuperados.
• Falha de uma ferramenta de leitura, tempo limite excedido (timeout) e dados inconsistentes no backend.
• Ação de escrita sem confirmação, com dados alterados e com confirmação expirada.
• Transição para atendimento humano com um contexto de conversa mínimo e compreensível.

Os resultados esperados devem ser definidos antes do teste: Que resposta é permitida publicamente? Que erro HTTP é gerado no lado do servidor? Que informação pode estar visível no chat? Que evento é registado sem conteúdo confidencial? Um modo degradado (Degraded Mode) planeado ajuda quando os serviços de identidade ou backend falham; para isso, consulte o nosso guia de resposta a incidentes e rollback.

Lista de verificação para um limite de portal robusto

• Documentar a zona pública, a zona autenticada e a zona especialmente protegida.
• Modelar separadamente autenticação, autorização e aprovação de transações.
• Obter a conta e o cliente (tenant) a partir da sessão segura.
• Verificar as permissões do objeto no lado do servidor em cada operação de leitura e escrita.
• Separar e filtrar tecnicamente fontes de RAG públicas e privadas.
• Restringir as permissões das ferramentas ao mínimo; separar leitura e escrita.
• Considerar a expiração de sessão, logout, troca de conta e alterações de funções no chat.
• Apresentar resumos claros de ações sensíveis e solicitar confirmações específicas.
• Limitar a transição humana e o registo de eventos aos dados estritamente necessários.
• Testar de forma reproduzível tentativas de acesso horizontal utilizando pelo menos duas contas.

Um chatbot de IA autenticado não se torna seguro pelo simples facto de estar atrás de um início de sessão. A segurança surge quando cada informação e cada ação possuem um limite verificável. Por conseguinte, comece pelo mapa de zonas e pela matriz de testes antes de ligar fontes de dados privadas ou ferramentas de escrita. Desta forma, o chat público permanece útil e o chat do portal operacional, sem misturar as duas zonas de confiança.

Fontes

• NIST SP 800-63, Revisão 4: Digital Identity Guidelines
• OWASP Authentication Cheat Sheet
• OWASP Authorization Cheat Sheet
• OWASP Session Management Cheat Sheet
• OWASP Insecure Direct Object Reference Prevention Cheat Sheet
• OWASP Transaction Authorization Cheat Sheet