O Agente de um cliente nunca pode enxergar os dados de outro: por que multi-tenancy também é uma fronteira de segurança

Quando várias empresas utilizam a mesma plataforma de Inteligência Artificial, é natural que parte da infraestrutura seja compartilhada.

Os mesmos servidores podem executar operações de clientes diferentes. O mesmo banco pode armazenar registros de várias organizações. Filas, workers, serviços de observabilidade e até o modelo de IA podem atender centenas ou milhares de empresas.

Isso faz parte de uma arquitetura multi-tenant: uma única plataforma atende diferentes organizações, chamadas de tenants, mantendo uma separação lógica entre elas.

Compartilhar infraestrutura, por si só, não é o problema.

O problema começa quando essa arquitetura permite, mesmo por erro, que uma execução pertencente a uma empresa alcance dados, memória, contexto, documentos, ferramentas ou credenciais pertencentes a outra.

Em um sistema tradicional, isso já representa uma falha séria de segurança. Em uma plataforma com Agentes de IA, o impacto pode se espalhar mais rapidamente.

O Agente não consulta uma informação apenas para exibi-la. Ele pode incorporar aquela informação ao contexto, utilizá-la para raciocinar, tomar decisões, armazená-la na memória e executar ações a partir dela.

Por isso, uma das perguntas mais importantes ao avaliar uma plataforma de Agentes não é somente:

“Quantas empresas ela consegue atender?”

Também é:

“Como ela garante que o Agente de uma empresa nunca atravesse a fronteira da outra?”

Essa diferença transforma multi-tenancy de uma decisão de infraestrutura em uma questão de segurança.

Multi-tenancy não exige um servidor separado para cada cliente

Existe uma confusão comum quando se fala em isolamento.

Separar clientes não significa necessariamente manter uma infraestrutura física completamente diferente para cada empresa.

O Azure Architecture Center trata o isolamento multi-tenant como um espectro. Alguns componentes podem ser completamente compartilhados, outros podem ter separação lógica e determinados recursos podem ser dedicados a clientes com requisitos específicos.

Uma plataforma poderia, por exemplo, utilizar:

• aplicação compartilhada;
• workers compartilhados;
• filas compartilhadas;
• banco compartilhado com isolamento lógico;
• bancos separados para determinados clientes;
• credenciais individuais para cada tenant;
• armazenamento particionado;
• modelos de IA compartilhados.

A AWS segue uma lógica semelhante. Sua documentação sobre tenant isolation em arquiteturas SaaS destaca que recursos podem estar em infraestrutura compartilhada desde que existam mecanismos explícitos para impedir que um tenant alcance recursos pertencentes a outro.

A pergunta correta, portanto, não é se existe compartilhamento.

É:

quando existe compartilhamento, onde está a fronteira que impede o acesso entre clientes?

Essa fronteira precisa continuar funcionando independentemente de a separação ocorrer por bancos diferentes, schemas, tabelas, namespaces, políticas de autorização, credenciais, contas ou outros mecanismos.

Login não é isolamento entre empresas

Outro erro comum é acreditar que autenticar cada usuário resolve automaticamente o problema.

Não resolve.

Autenticação responde principalmente:

“Quem é você?”

Autorização responde:

“O que você pode fazer?”

Tenant isolation acrescenta uma terceira pergunta:

“Dentro de qual organização você pode fazer isso e quais recursos pertencem a ela?”

A AWS faz essa distinção explicitamente ao explicar isolamento em sistemas SaaS. Um usuário pode estar corretamente autenticado e possuir uma função legítima dentro da aplicação e, ainda assim, conseguir acessar um recurso pertencente a outro tenant se a aplicação não utilizar o contexto da organização para limitar esse acesso.

Imagine duas empresas fictícias:

• Empresa Alfa;
• Empresa Beta.

Um funcionário da Alfa possui uma conta válida na plataforma.

O sistema deve permitir que ele utilize os recursos da Alfa. A falha não seria deixá-lo entrar.

A falha seria permitir que, depois do login, alguma consulta, API ou processo pudesse acessar recursos da Beta.

Esse problema fica ainda mais importante quando a aplicação possui Agentes capazes de executar tarefas. A discussão sobre identidade, permissões e responsabilidade em Agentes IA deixa de ser apenas uma questão de quais ações o usuário pode executar. Também é preciso definir em nome de qual tenant aquela execução acontece.

O tenant precisa acompanhar a solicitação durante todo o caminho.

O Agente também precisa saber a qual tenant pertence

Um Agente normalmente recebe diversas informações antes de produzir uma resposta ou executar uma tarefa.

Esse contexto pode incluir:

• instruções de sistema;
• histórico da conversa;
• informações sobre o usuário;
• documentos recuperados de uma base de conhecimento;
• memória persistente;
• resultados de ferramentas;
• dados de sistemas internos;
• informações encontradas em APIs;
• respostas de outros Agentes.

Tudo isso influencia o que o modelo fará depois.

Por isso, o isolamento multi-tenant não pode existir apenas na interface ou no banco principal da aplicação.

O contexto do tenant precisa acompanhar toda a cadeia de execução.

O AWS Well-Architected Agentic AI Lens, publicado em junho de 2026, trata segurança de memória, identidade, ferramentas, comunicação e observabilidade como partes próprias da arquitetura de sistemas agênticos.

Entre seus princípios de segurança está a recomendação de particionar memória, ferramentas e canais de acordo com fronteiras explícitas de confiança, incluindo separações entre sessões, usuários, tenants e Agentes.

Na prática, não basta o front-end saber qual empresa está sendo atendida.

O runtime precisa saber.

A memória precisa saber.

A recuperação de documentos precisa saber.

A ferramenta precisa saber.

A credencial precisa saber.

A fila precisa saber.

E cada camada precisa aplicar essa restrição sem depender da boa vontade do modelo.

1. A memória de um cliente nunca deve alimentar o Agente de outro

Memória é uma das capacidades mais úteis de um Agente.

Ela permite lembrar preferências, recuperar acontecimentos anteriores, continuar tarefas e preservar contexto entre interações.

Também pode se transformar em uma superfície de vazamento.

A AWS trata isolamento de memória como uma prática específica de segurança. A recomendação é particionar esse estado pelos eixos relevantes para a aplicação, como sessão, usuário, tenant, Agente ou grupo.

Isso muda bastante o desenho da recuperação.

Se um Agente da Empresa Alfa está atendendo João, uma busca conceitualmente segura se aproxima de:

Tenant Alfa → usuário João → sessão ou memória autorizada

Uma implementação mais frágil seria simplesmente:

“Procure informações relacionadas a João.”

No segundo caso, o mecanismo de busca precisa torcer para que João seja identificado corretamente dentro de um grande conjunto compartilhado.

No primeiro, a busca já começa dentro de uma fronteira delimitada.

Essa separação também é importante porque definir o que um Agente deve lembrar, registrar e esquecer envolve tanto utilidade quanto governança. Uma memória correta entregue ao tenant errado continua sendo um vazamento.

O isolamento precisa acontecer antes que a informação entre no contexto do modelo.

2. Histórico de conversa e sessão também precisam ser isolados

Memória persistente e histórico da sessão não são exatamente a mesma coisa.

Durante uma conversa, o Agente pode manter mensagens recentes, resultados intermediários, respostas de ferramentas, arquivos analisados e informações necessárias para continuar o atendimento.

Esse estado de curto prazo também precisa de fronteiras.

Um identificador de sessão reutilizado incorretamente, uma chave de cache incompleta ou uma consulta que ignore o tenant pode inserir dados de uma conversa dentro de outra.

O problema não termina quando uma mensagem errada aparece.

Se esse conteúdo entra no contexto do modelo, ele pode influenciar a próxima decisão.

O Agente pode:

• responder com base naquela informação;
• chamar uma ferramenta utilizando aquele dado;
• registrar a informação novamente;
• criar uma memória persistente;
• repassar o conteúdo para outro Agente.

Uma falha pequena de segmentação pode virar uma contaminação de contexto que continua se propagando.

Por isso, identificadores de sessão e cache também devem carregar o contexto organizacional necessário.

Uma chave como:

session:12345

pode ser insuficiente se aquele identificador não for globalmente único.

Um desenho conceitualmente mais seguro seria algo próximo de:

tenant:alfa:session:12345

O formato exato pode variar. O princípio não.

3. Bases de conhecimento e RAG precisam respeitar a mesma fronteira

Imagine uma plataforma utilizada pela Empresa Alfa e pela Empresa Beta.

A Alfa envia:

• tabela de preços;
• contratos;
• políticas comerciais;
• apresentações;
• catálogo de produtos.

A Beta envia seus próprios documentos.

O Agente utiliza RAG, ou Retrieval-Augmented Generation, para procurar trechos relevantes antes de responder.

Fisicamente, os documentos podem estar na mesma infraestrutura.

Os embeddings também podem estar no mesmo serviço.

O índice vetorial pode ser compartilhado.

Nada disso significa automaticamente que a arquitetura esteja errada.

O risco aparece se uma consulta iniciada pela Alfa conseguir recuperar um chunk pertencente à Beta.

Para um sistema de IA, recuperar uma informação e inseri-la no contexto é praticamente colocá-la diante do modelo.

Por isso, o filtro de tenant deve participar da recuperação antes que os documentos sejam enviados ao LLM.

Essa fronteira precisa continuar em:

• arquivos originais;
• versões processadas;
• chunks;
• embeddings;
• índices vetoriais;
• metadados;
• caches de busca;
• resultados intermediários;
• permissões do storage.

Não adianta impedir o usuário de abrir diretamente o PDF da Beta se o mecanismo de retrieval consegue extrair um trecho desse mesmo PDF e entregá-lo silenciosamente ao Agente da Alfa.

4. As ferramentas são outra fronteira de segurança

Agentes modernos não apenas respondem perguntas.

Eles podem:

• consultar um CRM;
• buscar pedidos;
• verificar pagamentos;
• registrar leads;
• consultar estoque;
• criar agendamentos;
• enviar mensagens;
• emitir documentos;
• abrir tickets;
• executar automações.

Quanto mais ferramentas existem, mais importante fica a autorização fora do modelo.

A AWS recomenda que cada chamada de ferramenta seja autorizada por uma política antes da execução, propagando a identidade do Agente e o contexto do usuário. A documentação também alerta contra depender apenas do julgamento do próprio Agente para decidir se determinada chamada deve ser permitida.

Esse princípio é especialmente importante em multi-tenancy.

Imagine uma ferramenta chamada:

consultar_cliente(id)

Se essa ferramenta consegue consultar qualquer cliente da plataforma e depende do modelo para escolher somente IDs da Empresa Alfa, a fronteira de segurança está dentro do raciocínio probabilístico do LLM.

Uma arquitetura mais segura transformaria conceitualmente essa operação em:

consultar_cliente(tenant=Alfa, id=X)

E o tenant não deveria ser um campo que o Agente pudesse trocar livremente.

Ele deveria vir da identidade e do contexto já autorizado da execução.

Isso se conecta diretamente à ideia de separar decisão e execução em Agentes. O modelo pode decidir que precisa consultar determinado cliente. A camada de execução ainda deve determinar quais clientes aquela execução realmente está autorizada a acessar.

5. Credenciais não podem ser globais quando representam clientes diferentes

Considere uma plataforma integrada ao CRM de cem empresas.

O código da integração pode ser exatamente o mesmo para todas.

As credenciais não.

Cada tenant pode possuir:

• token de CRM;
• API key;
• conta de WhatsApp;
• credenciais de e-mail;
• acesso ao ERP;
• banco;
• storage;
• webhook;
• sistema financeiro.

O Agente da Alfa jamais deveria conseguir recuperar ou utilizar uma credencial pertencente à Beta.

Isso exige mais do que criptografar segredos.

Também é necessário garantir quem consegue recuperar cada segredo e dentro de qual contexto.

Se uma aplicação armazena:

crm_api_key = X

existe pouca informação sobre propriedade.

Um modelo conceitualmente mais seguro vincula o segredo ao tenant, à integração e, quando necessário, ao Agente ou escopo de execução.

A própria lógica de privilégio mínimo recomendada para Agentes existe para limitar o impacto de erros, instruções manipuladas ou comportamentos inesperados.

Uma credencial que abre cem clientes transforma uma falha em um incidente de cem clientes.

Uma credencial limitada a um único tenant reduz a superfície atingida.

6. Canais de entrada e saída também pertencem ao tenant

WhatsApp, e-mail, Telegram, chat do site, webhooks e sistemas internos podem iniciar uma execução.

A associação precisa acontecer antes que a mensagem chegue ao raciocínio do Agente.

Uma entrada deveria ser vinculada de maneira inequívoca a algo conceitualmente semelhante a:

canal → conta → tenant → Agente → sessão

O mesmo cuidado vale para a saída.

Se um worker recebe uma tarefa para enviar uma mensagem, ele precisa saber qual conta deve ser utilizada e em nome de qual organização aquela ação acontece.

Uma associação errada logo no começo pode propagar o tenant errado para toda a cadeia.

O Agente pode recuperar a base errada, carregar o histórico errado e utilizar a credencial errada mesmo que cada componente esteja funcionando tecnicamente como esperado.

7. Processos assíncronos não podem perder o tenant no caminho

Nem toda tarefa termina dentro da mesma requisição.

Um Agente pode iniciar um processo que continua em:

• fila;
• worker;
• scheduler;
• webhook;
• evento;
• rotina de retry;
• job executado minutos depois.

Essa transição é um ponto fácil para perder contexto.

Imagine que a aplicação coloque na fila apenas:

job_id = 91822

O worker precisa descobrir depois a qual tenant aquele job pertence.

Se esse vínculo estiver errado, ausente ou puder ser manipulado, a operação seguinte pode ocorrer no contexto de outra empresa.

O tenant deve acompanhar a execução pelas fronteiras assíncronas, junto dos identificadores necessários para autorização, correlação e auditoria.

Esse cuidado também ajuda na investigação de incidentes. Quando uma tarefa percorre vários serviços, é necessário conseguir reconstruir qual tenant iniciou o processo e quais recursos foram acessados.

Compartilhar infraestrutura não é o problema. Perder o contexto do tenant é.

Uma plataforma pode perfeitamente ter:

• dezenas de clientes no mesmo cluster;
• milhares de conversas na mesma fila;
• workers processando tarefas de várias empresas;
• um banco contendo múltiplos tenants;
• o mesmo modelo atendendo todos;
• serviços de observabilidade compartilhados.

O perigo aparece quando alguma camada deixa de carregar ou validar a identidade da organização.

Alguns exemplos tornam isso mais concreto.

Banco de dados: uma consulta utiliza o ID do registro, mas esquece a condição de tenant.

Cache: a chave considera o ID do usuário, mas não a empresa.

Busca vetorial: a consulta procura apenas por similaridade e ignora o namespace da organização.

Fila: o job carrega o identificador da tarefa, mas perde o tenant durante o processamento.

Ferramenta: a integração acessa recursos de vários clientes e depende do modelo para selecionar o correto.

Memória: sessões diferentes utilizam o mesmo namespace.

Credencial: o segredo é associado somente ao tipo de integração, não ao cliente proprietário.

Canal: uma mensagem recebida é vinculada ao Agente correto, mas à conta errada.

A infraestrutura pode continuar funcionando sem apresentar erro técnico.

A falha é arquitetural.

A fronteira entre clientes desapareceu.

O modelo de IA não deve ser considerado uma barreira de segurança

Talvez este seja o princípio mais importante de todo o tema.

Não basta colocar no prompt:

“Nunca utilize informações de outros clientes.”

Essa instrução pode ser útil para orientar comportamento.

Ela não cria isolamento.

Os princípios de segurança do Agentic AI Lens deixam claro que o próprio Agente não deve ser tratado como uma fronteira de confiança. Entradas, memória, ferramentas e mensagens precisam de controles externos.

O motivo é simples.

Modelos podem interpretar uma instrução incorretamente.

Podem receber contexto contaminado.

Podem sofrer prompt injection.

Podem escolher uma ferramenta errada.

Podem produzir parâmetros inesperados.

O OWASP descreve esse problema ao tratar de Excessive Agency: sistemas baseados em LLM podem causar ações prejudiciais quando recebem saídas inesperadas, ambíguas ou manipuladas e possuem ferramentas, permissões ou autonomia além do necessário.

Isso também explica por que prompt injection não deve ser tratado apenas como um problema de resposta. Se o Agente possui acesso a dados e ferramentas de vários tenants, uma manipulação pode tentar transformar uma falha de raciocínio em acesso indevido.

A regra precisa ser:

o Agente pode receber a instrução para respeitar a fronteira, mas a infraestrutura deve impedir que ele consiga atravessá-la.

Uma boa arquitetura assume que alguma coisa vai falhar

Sistemas complexos não deveriam ser projetados supondo que todos os componentes sempre funcionarão perfeitamente.

A pergunta mais útil é:

qual é o raio de impacto quando algo dá errado?

Se uma sessão for comprometida, quais outras sessões ela consegue alcançar?

Se uma memória receber conteúdo malicioso, quais usuários podem recuperá-lo?

Se um Agente chamar uma ferramenta errada, quais recursos aquela ferramenta consegue modificar?

Se uma credencial aparecer indevidamente dentro de uma execução, ela abre um sistema específico ou toda a plataforma?

Se um parâmetro for manipulado, existe outra camada verificando a autorização?

Se um worker receber um tenant incorreto, o banco ainda impede o acesso?

Fronteiras independentes reduzem movimentação lateral.

Isso significa que uma falha em uma camada não deveria automaticamente derrubar todas as demais.

O isolamento também precisa ser observável e testável

Dizer que a plataforma possui isolamento não basta.

A arquitetura precisa permitir verificar se ele realmente está acontecendo.

O Agentic AI Lens recomenda observabilidade específica para execuções agênticas, incluindo rastreamento de chamadas de ferramentas, operações de memória, handoffs e caminhos de execução.

Essa rastreabilidade é especialmente útil em ambientes multi-tenant.

Quando algo estranho acontece, a equipe deveria conseguir responder:

• qual tenant iniciou a execução;
• qual usuário ou evento originou a ação;
• qual Agente processou a solicitação;
• qual memória foi consultada;
• quais documentos foram recuperados;
• quais ferramentas foram chamadas;
• quais credenciais foram utilizadas;
• quais recursos foram acessados;
• quais processos assíncronos continuaram depois.

É justamente o tipo de análise discutido quando se pergunta: se o Agente errou, você consegue descobrir o caminho que levou ao erro?

Sem rastreabilidade, uma empresa pode descobrir que houve um vazamento sem conseguir reconstruir onde a fronteira foi quebrada.

Também é necessário testar o isolamento.

Um teste útil não deveria perguntar apenas:

“O Agente normalmente consulta dados da empresa correta?”

Deveria tentar deliberadamente:

“Uma sessão autenticada como Empresa Alfa consegue acessar um recurso pertencente à Empresa Beta?”

O resultado esperado não é que o modelo se recuse educadamente.

O resultado esperado é:

a operação ser tecnicamente impossível ou explicitamente negada pela camada responsável pela autorização.

O que observar ao avaliar uma plataforma multi-tenant com IA

Uma empresa não precisa conhecer cada detalhe do código de seu fornecedor para fazer perguntas melhores sobre segurança.

Alguns pontos ajudam bastante.

Como o tenant acompanha toda a execução?

A identidade da organização deveria continuar presente desde o canal de entrada até bancos, memória, retrieval, ferramentas, credenciais e processos em segundo plano.

A memória é particionada por empresa?

Históricos, memória persistente, cache e estados intermediários precisam possuir namespaces ou mecanismos equivalentes de isolamento.

Como documentos e bases de conhecimento são separados?

A recuperação precisa restringir o conjunto de documentos ao tenant correto antes que qualquer trecho seja incorporado ao contexto do modelo.

As ferramentas verificam autorização fora do LLM?

O modelo não deveria ser a entidade responsável por garantir sozinho que uma operação pertence à organização correta.

As credenciais são isoladas?

Tokens, APIs, contas de mensageria, bancos e integrações precisam ser recuperados de acordo com o tenant proprietário.

Jobs e filas preservam o contexto organizacional?

Processos assíncronos precisam continuar sabendo em nome de qual tenant estão sendo executados.

É possível auditar o que cada Agente acessou?

Logs e traces precisam permitir reconstruir memória, ferramentas, serviços e recursos envolvidos em uma execução.

O isolamento é testado?

Testes negativos devem tentar atravessar deliberadamente as fronteiras entre tenants.

A segurança aparece quando a tentativa falha por projeto, não porque o Agente escolheu se comportar corretamente.

A escalabilidade que importa não é apenas quantidade

É comum avaliar uma plataforma perguntando quantas mensagens, conversas, operações ou empresas ela consegue processar.

Essas métricas importam.

Mas existe outra forma de escalabilidade igualmente importante:

a capacidade de adicionar clientes sem aumentar a possibilidade de um atravessar a fronteira do outro.

Uma arquitetura multi-tenant precisa compartilhar aquilo que pode ser compartilhado:

• processamento;
• infraestrutura;
• serviços;
• modelos;
• componentes operacionais.

E precisa preservar aquilo que pertence exclusivamente a cada organização:

• dados;
• memória;
• contexto;
• documentos;
• credenciais;
• ferramentas autorizadas;
• sessões;
• canais;
• permissões.

Essa separação precisa continuar clara com dez, cem ou dez mil empresas utilizando a plataforma.

Porque a pergunta mais importante não é quantos clientes cabem na mesma infraestrutura.

Antes de perguntar quantos clientes uma plataforma suporta, vale perguntar como ela garante que um cliente nunca atravesse a fronteira do outro.