Isolamento entre clientes em agentes de IA

Uma resposta correta pode carregar o contexto do cliente errado

Uma empresa opera um agente de atendimento para várias contas. O usuário faz uma pergunta comum sobre um pedido. O agente encontra uma política válida, produz uma resposta clara e cita uma condição comercial que pertence a outro cliente.

O texto parece plausível. A falha está na fronteira usada para recuperar contexto.

Esse risco aparece em plataformas SaaS, operações terceirizadas, grupos empresariais, consultorias, centrais compartilhadas e agentes internos que atendem unidades diferentes. Quanto mais fontes, memórias e ferramentas entram no fluxo, maior a necessidade de provar que cada execução permaneceu dentro do escopo autorizado.

Isolamento entre clientes em agentes de IA é o conjunto de controles que impede uma tarefa de consultar, combinar, memorizar, registrar ou alterar recursos pertencentes a outra conta. A fronteira precisa acompanhar o trabalho inteiro, da autenticação ao efeito confirmado no sistema final.

O que significa tenant em uma arquitetura de agentes

Tenant é a unidade cujo conteúdo e recursos precisam permanecer separados. Dependendo do negócio, pode representar:

• uma empresa cliente;
• uma unidade do mesmo grupo;
• uma carteira comercial;
• uma organização dentro de um SaaS;
• um projeto sob confidencialidade;
• um ambiente de teste ou produção;
• uma área com regras próprias de acesso.

A definição precisa ser explícita. Usar cliente, conta, workspace, organização e projeto como se fossem equivalentes cria brechas. Um grupo empresarial pode compartilhar contratos entre unidades e proibir o compartilhamento de dados trabalhistas. Uma consultoria pode atender duas marcas do mesmo controlador sob acordos diferentes.

Registre qual objeto governa o isolamento, quem pode pertencer a ele e quais exceções de compartilhamento são permitidas.

Onde a mistura entre clientes costuma acontecer

Recuperação de dados

Uma busca vetorial, consulta SQL ou chamada de API retorna registros sem filtro obrigatório por tenant. O modelo recebe conteúdo de várias contas e escolhe o trecho que parece responder melhor.

Memória

Resumo de conversa, preferência, correção humana ou fato persistido entra em uma memória comum. Outra execução recupera esse conteúdo porque a similaridade semântica foi alta.

Cache

A resposta de uma consulta fica armazenada com uma chave incompleta. O próximo cliente faz uma pergunta parecida e recebe o resultado anterior.

Ferramentas

A credencial usada pelo agente alcança várias contas. O prompt informa qual cliente deve ser usado, mas a API aceita qualquer identificador enviado nos argumentos.

Filas e estado

Uma tarefa assíncrona perde o vínculo com a conta durante retentativa, retomada ou transferência entre agentes. O worker processa o payload com configuração padrão.

Logs e avaliação

Prompts, respostas e argumentos de ferramentas ficam disponíveis para equipes, fornecedores ou ambientes que não deveriam acessar aquele cliente. O fluxo final pode estar correto enquanto a observabilidade cria a exposição.

Artefatos

Relatórios, planilhas e PDFs são gravados em uma pasta comum, herdam link público ou recebem um nome previsível. A entrega certa existe, mas a proteção do arquivo está errada.

O guia de DLP para agentes de IA trata a passagem de dados por essas fronteiras. O isolamento multi-tenant acrescenta uma obrigação específica: uma identidade autorizada em uma conta não deve atravessar para outra durante a mesma unidade de trabalho.

O tenant precisa nascer em uma fonte confiável

O agente não deveria escolher livremente qual conta usar a partir de texto da conversa. Expressões como “consulte a empresa X” podem ser ambíguas, estar desatualizadas ou ter sido inseridas por conteúdo não confiável.

O identificador do tenant deve vir de uma fonte autenticada, como:

• sessão do usuário;
• token emitido para a aplicação;
• registro oficial do caso;
• canal vinculado previamente à conta;
• evento assinado por um sistema autorizado;
• relação confirmada entre usuário, cliente e recurso.

Depois de estabelecido, o identificador acompanha a execução em um envelope protegido. O modelo pode receber o contexto necessário para trabalhar, mas não recebe autoridade para trocar o tenant.

Um envelope mínimo pode conter:

• tenant_id;
• identidade solicitante;
• caso ou objeto de negócio;
• finalidade;
• ambiente;
• política aplicável;
• ferramentas permitidas;
• versão da configuração;
• identificador da execução.

A fonte da verdade para agentes de IA ajuda a definir qual sistema governa cada objeto quando CRM, atendimento, documentos e memória apresentam registros divergentes.

Aplique a fronteira em cada camada

Identidade e autorização

Prefira identidades restritas a uma conta quando a plataforma permitir. Quando uma identidade técnica atende vários tenants, a autorização precisa validar usuário, ação, objeto e tenant em cada chamada.

Uma credencial ampla protegida somente por instrução transfere a segurança para o componente mais probabilístico do sistema. A página sobre identidade e credenciais para agentes detalha contas próprias, escopos, tokens curtos, rotação e revogação.

Banco de dados

Filtros por tenant devem ser aplicados no repositório, na política de linha ou na camada de acesso. Evite montar consultas em que o modelo pode omitir ou substituir a condição.

Controles úteis incluem:

• políticas de segurança por linha;
• conexões ou esquemas separados para maior criticidade;
• índices compostos com tenant;
• bloqueio de consultas sem escopo;
• validação do objeto retornado antes do uso;
• testes que tentam acessar identificadores de outra conta.

Busca e RAG

O índice precisa preservar metadados de origem e tenant. O filtro deve ocorrer antes da seleção de trechos. Filtrar o resultado depois da recuperação permite que conteúdo indevido influencie ranking, resumo ou ferramentas subsequentes.

Verifique também documentos sem metadado, arquivos movidos, duplicatas e reindexações. Um único item órfão pode entrar em todas as buscas.

Memória

Separe memória por tenant, usuário, processo e finalidade. Uma correção feita por um cliente não deveria virar regra global sem revisão e promoção explícitas.

Defina:

• chave de particionamento;
• tipos de memória permitidos;
• prazo de validade;
• origem e autoridade;
• regra de recuperação;
• descarte ao encerrar contrato;
• processo para transformar aprendizado local em padrão comum.

O artigo sobre memória de agentes de IA mostra como distinguir estado de sessão, memória operacional, conhecimento e preferências persistentes.

Cache

Inclua tenant, ambiente, versão, permissão e parâmetros relevantes na chave. Respostas que dependem do usuário ou da autorização podem exigir cache privado ou nenhuma reutilização.

A invalidação também precisa respeitar a fronteira. Atualizar a política de um cliente não deveria apagar tudo nem manter uma resposta vencida somente para aquela conta. Veja o guia de cache para agentes de IA.

Ferramentas e ações

Ferramentas estreitas reduzem o espaço de erro. Em vez de expor buscar_cliente(id_livre), a arquitetura pode oferecer buscar_cliente_do_caso(caso_autorizado). O adaptador resolve o tenant a partir do envelope e rejeita argumentos divergentes.

Antes de executar, valide:

1. identidade técnica;
2. tenant da execução;
3. tenant do objeto;
4. ação permitida;
5. ambiente;
6. alçada;
7. confirmação esperada no destino.

O catálogo de ferramentas para agentes ajuda a registrar contrato, efeito, autenticação e limites de cada capacidade.

Logs e traces

Cada evento deve carregar o tenant para investigação e controle de acesso. O conteúdo registrado precisa ser reduzido e protegido. Equipes de suporte podem consultar metadados operacionais sem receber automaticamente prompts, anexos ou dados completos de todos os clientes.

A política de retenção de dados para agentes orienta finalidade, prazo, acesso e descarte das evidências.

Escolha o nível de separação pelo impacto

Uma única arquitetura física pode atender casos de baixo risco quando controles lógicos são fortes e testados. Processos críticos podem exigir separação maior.

Separação lógica

Recursos compartilhados usam identificadores, políticas e controles de acesso para dividir contas. Costuma simplificar operação e custo, mas qualquer falha no filtro pode ampliar o alcance.

Separação por esquema, índice ou fila

Cada tenant ou grupo de risco recebe componentes próprios em algumas camadas. Isso reduz caminhos de mistura e aumenta complexidade de provisionamento, migração e observabilidade.

Separação física

Banco, armazenamento, runtime ou ambiente dedicado atende uma conta. Pode ser necessário por contrato, risco, residência de dados ou consequência operacional. Ainda exige identidade e configuração corretas. Infraestrutura dedicada não corrige envio para destinatário errado.

A decisão deve considerar sensibilidade, volume, obrigações, raio de impacto, capacidade de detecção e custo de reconstrução. O comparativo sobre residência de dados em IA complementa a análise quando país, região e subfornecedores também fazem parte do contrato.

Teste isolamento como uma propriedade do sistema

Uma demonstração com duas contas limpas prova pouco. Os testes precisam tentar romper a fronteira.

Casos de leitura cruzada

Use identificadores válidos de outra conta em URLs, argumentos, anexos, buscas, filtros e referências indiretas. O resultado esperado é bloqueio antes da recuperação do conteúdo.

Casos de memória e cache

Ensine uma preferência exclusiva no tenant A e faça uma pergunta semelhante no tenant B. Repita com sessões, usuários, idiomas e versões diferentes.

Casos de ferramenta

Tente atualizar um objeto de outra conta, trocar o identificador depois da aprovação e retomar uma tarefa com envelope incompleto. Verifique a resposta da API e o estado final.

Casos assíncronos

Exercite fila, retentativa, timeout, cancelamento, DLQ e reprocessamento. O tenant deve permanecer vinculado à unidade mesmo depois de várias transições.

Casos de observabilidade

Confirme que suporte, avaliação e engenharia acessam somente o escopo autorizado. Procure conteúdo em logs, erros, traces, arquivos temporários e exportações.

Casos de ciclo de vida

Crie, migre, suspenda e encerre uma conta. Teste revogação, exclusão, retenção autorizada e impossibilidade de recuperar memória após o término.

Falhas encontradas devem entrar no conjunto de regressão. O ambiente de teste para agentes organiza dados, identidades e integrações para esse exercício.

Monitore sinais de quebra de fronteira

Mistura entre clientes merece alerta imediato. Alguns sinais:

• recurso retornado com tenant divergente;
• consulta sem filtro obrigatório;
• documento sem metadado de conta;
• cache hit entre tenants;
• memória recuperada fora do escopo;
• tentativa de ferramenta sobre objeto divergente;
• worker iniciado sem envelope completo;
• artefato salvo em local compartilhado indevido;
• log acessado por equipe sem vínculo com a conta;
• volume anormal de bloqueios por uma mesma integração.

O alerta precisa informar execução, identidade, contas envolvidas, objeto, ferramenta, versão e ação de contenção. Evite copiar o conteúdo sensível para o próprio alerta.

Se houver exposição confirmada ou possibilidade relevante de dano, pause a capacidade afetada, preserve evidência e acione o plano de resposta a incidentes de IA.

Checklist de isolamento entre clientes

• [ ] O tenant está definido para cada unidade de trabalho?
• [ ] O identificador nasce em uma fonte autenticada?
• [ ] O modelo está impedido de trocar o tenant?
• [ ] Banco, busca e armazenamento aplicam filtro antes de retornar conteúdo?
• [ ] Memória e cache usam chaves com escopo completo?
• [ ] Ferramentas validam tenant da execução e do objeto?
• [ ] Filas preservam o vínculo em retentativas e retomadas?
• [ ] Logs e avaliações têm controle de acesso por conta?
• [ ] Artefatos recebem localização e compartilhamento compatíveis?
• [ ] Contas suspensas perdem acesso sem afetar as demais?
• [ ] Testes tentam leitura, escrita e persistência cruzadas?
• [ ] Existe alerta e interrupção para qualquer divergência?
• [ ] Contratos de exclusão e retenção podem ser executados?
• [ ] Um dono responde pela fronteira completa?

Isolamento precisa ser demonstrável

Separar clientes por convenção de nomes, prompt ou pasta funciona até a primeira exceção. Agentes atravessam várias camadas e podem carregar contexto por rotas que a interface não mostra.

Uma arquitetura segura vincula tenant, identidade, objeto e finalidade desde a entrada. Cada consulta, memória, ferramenta, fila e artefato verifica essa relação novamente. Testes adversariais e monitoramento mostram se a fronteira continua funcionando depois de mudanças.

A empresa deveria conseguir responder uma pergunta objetiva: qual controle impede esta execução de ler, lembrar ou alterar qualquer recurso de outra conta? Quando a resposta depende de o modelo interpretar corretamente o nome do cliente, a separação ainda não está pronta para produção.