O desafio de levar agentes de IA para produção em ambientes SaaS
Provedores de Software como Serviço (SaaS) que desenvolvem aplicações agênticas com múltiplos inquilinos (multi-tenant) enfrentam desafios arquiteturais que vão muito além das preocupações habituais de segurança e governança. Isolamento entre tenants, gerenciamento de identidade, observabilidade, atribuição de custos e mitigação do problema de “vizinho barulhento” são apenas alguns dos obstáculos que separam uma demonstração funcional de um ambiente de produção robusto.
Para endereçar esse cenário, a AWS anunciou o Amazon Bedrock AgentCore, um serviço gerenciado e serverless para construir, implantar e operar com segurança aplicações agênticas na AWS. O serviço oferece primitivos para deploy de agentes, hospedagem de servidores MCP (Model Context Protocol), além de suporte nativo a gerenciamento de identidade, memória, observabilidade e avaliações — tudo projetado para tornar arquiteturas multi-tenant mais simples de construir.
Dez componentes de design para agentes multi-tenant
A AWS detalhou dez componentes arquiteturais que precisam ser considerados ao projetar agentes multi-tenant com o AgentCore. Cada um exige decisões que equilibram isolamento, eficiência operacional e otimização de custos.
Os padrões de isolamento que permeiam todas essas decisões são três: Silo, Pool e Bridge. A escolha entre eles depende da estratégia de tiers do produto SaaS.
1. Runtime do agente: dedicado ou compartilhado
A decisão mais fundamental é como o runtime do agente é provisionado em relação aos tenants. Um runtime dedicado por tenant (padrão Silo) oferece a maior proteção contra o problema do vizinho barulhento e facilita auditorias de conformidade. Um runtime compartilhado reduz custos e overhead operacional, mas exige propagação rigorosa do contexto do tenant dentro do processo.
O AgentCore Runtime resolve essa tensão com computação baseada em microVMs isoladas por sessão. Cada sessão recebe seu próprio sistema de arquivos persistente, permitindo que os agentes mantenham estado entre etapas de uma interação sem risco de vazamento entre sessões. O contexto do tenant é injetado no ambiente de execução via cabeçalhos HTTP customizados — incluindo identificador do tenant, tier, preferências regionais, feature flags e entitlements.
2. Modelos: compartilhados, por tier ou fine-tuned
Modelos de fundação (FM — Foundation Models) compartilhados são o ponto de partida recomendado para a maioria dos deployments multi-tenant. Para casos que exigem terminologia específica, conformidade regulatória ou SLAs de performance, modelos fine-tuned por tenant se tornam necessários, embora introduzam maior complexidade operacional.
A AWS oferece, via Amazon Bedrock, uma seleção de grandes modelos de linguagem (LLM — Large Language Models) de diferentes provedores, além de suporte a fine-tuning com datasets próprios e importação de modelos customizados via Amazon Bedrock Custom Model Import.
3. Workflows: padrões Silo, Pool e Bridge
Workflows podem ser implementados como ferramentas MCP, endpoints de API ou habilidades do agente. O padrão Silo usa habilidades dedicadas por tenant, com toda a lógica de negócio isolada — máxima customização, mas manutenção separada por tenant. O padrão Pool usa habilidades compartilhadas. O padrão Bridge combina os dois: etapas comuns (autenticação, logging, tratamento de erros) ficam em habilidades compartilhadas, que invocam habilidades específicas do tenant em runtime para a lógica crítica de negócio.
4. RAG multi-tenant
Sistemas de Geração Aumentada por Recuperação (RAG — Retrieval Augmented Generation) exigem decisões de isolamento de dados. O padrão Silo usa bancos de dados vetoriais dedicados por tenant — recomendado para indústrias reguladas. O padrão Pool usa bancos vetoriais compartilhados com filtragem por metadados e controle de acesso por namespace, mais eficiente em custo para plataformas com muitos tenants pequenos e médios.
O Amazon Bedrock Knowledge Bases oferece capacidades gerenciadas de RAG com suporte a múltiplos bancos vetoriais e possibilidade de criar bases de conhecimento isoladas ou compartilhadas. Para orientações detalhadas, a AWS publicou referências sobre RAG multi-tenant com Amazon Bedrock Knowledge Bases e sobre multi-tenancy em aplicações RAG com filtragem de metadados.
5. Contexto do tenant, padrão act-on-behalf e propagação de tokens
Diferentemente de APIs determinísticas, agentes de IA são não-determinísticos e potencialmente autônomos. Um agente comprometido poderia fazer chamadas não autorizadas a serviços downstream, levando a roubo de credenciais, escalada de privilégios e o problema do “Confused Deputy”.
A AWS recomenda o padrão de delegação (Act-on-Behalf), em vez de impersonação completa. Nesse modelo, os tokens são transformados em cada fronteira de serviço com credenciais de escopo limitado e uma claim act (conforme o RFC 8693 do OAuth 2.0) que identifica o agente. O AgentCore Identity suporta a troca de token On-behalf-of, permitindo que agentes e servidores MCP troquem um token de acesso do usuário por um novo token com escopo restrito para um recurso downstream específico.
O contexto do tenant deve ser codificado em Tokens Web JSON (JWT — JSON Web Tokens) capturando três dimensões: Contexto de Segurança (claims padrão: iss, sub, exp, aud), Contexto do Tenant (tenant_id e escopos específicos) e Contexto da Requisição (atributos de domínio para lógica de negócio).
6. Controle de acesso granular para ferramentas MCP e APIs
Aplicações agênticas multi-tenant precisam restringir o acesso a servidores MCP por meio de políticas avaliadas em runtime — considerando cotas do tenant, permissões por tier e limites de uso. O AgentCore Policy intercepta e avalia todas as requisições dos agentes antes de permitir acesso a ferramentas, com políticas escritas em linguagem natural ou diretamente em Cedar.
Na camada de invocação, servidores MCP filtram as ferramentas disponíveis com base no tier do tenant, feature flags e limites de quota. O AgentCore Gateway permite que agentes acessem ferramentas de forma segura, transformando APIs e funções AWS Lambda em ferramentas compatíveis com agentes, com suporte a Amazon API Gateway, schemas OpenAPI, modelos Smithy, funções Lambda e servidores MCP.
Na camada de acesso a dados, políticas de Controle de Acesso Baseado em Atributos (ABAC — Attribute-Based Access Control) reforçam o isolamento usando condições do AWS Identity and Access Management (IAM — Identity and Access Management) para restringir o acesso a dados com base em tags e atributos do principal.
7. Memória: isolamento por namespace hierárquico
O gerenciamento de memória multi-tenant deve implementar cinco níveis lógicos: Global (conhecimento compartilhado entre tenants), Estratégia (padrões específicos por tipo de agente), Tenant (histórico e preferências do tenant), Usuário (contexto individual dentro do tenant) e Sessão (memória de curto prazo para conversas ativas).
O AgentCore Memory oferece isolamento por namespace hierárquico em todos esses níveis, com suporte a políticas baseadas em recursos e controle de acesso baseado em atributos para acesso granular. A implementação envolve construir identificadores compostos a partir de informações do tenant e do usuário (por exemplo, tenant_123:user_456) e prefixar todas as operações de memória com o caminho de namespace apropriado.
8. Identidade, confiança e descoberta de agentes
Conforme agentes interagem com outros agentes além das fronteiras organizacionais, três preocupações fundamentais emergem: identidade (quem é este agente e ele pode provar isso?), confiança (devo confiar neste agente?) e descoberta (como encontro o agente certo?).
O AgentCore Identity implementa identidades de agente como workload identities, com cada agente recebendo uma identidade verificável criptograficamente ancorada na conta AWS e na infraestrutura IAM da organização. Para confiança, a indústria ainda está trabalhando no problema — o Agent Naming Service (ANS) v2, atualmente um Internet-Draft da IETF (trabalho em andamento), ancora cada identidade de agente a um nome de domínio DNS, com três níveis de verificação: Bronze (PKI), Silver (PKI + DANE) e Gold (PKI + DANE + Transparency Log).
Para descoberta, o AWS Agent Registry, disponível via Amazon Bedrock AgentCore, oferece um catálogo centralizado para descobrir agentes, habilidades, servidores MCP e recursos customizados em uma organização, com busca por linguagem natural ou estruturada.
9. Rastreamento de custos por tenant e observabilidade
A atribuição precisa de custos em ambientes multi-tenant requer instrumentação a nível de aplicação que emita métricas tagueadas por tenant para cada invocação do agente, capturando tokens de entrada/saída, invocações de ferramentas e duração de execução. O AgentCore Observability oferece visibilidade em tempo real dos workflows dos agentes com integração compatível com OpenTelemetry, alimentada pelo Amazon CloudWatch.
10. Guardrails: segurança de conteúdo
Guardrails multi-tenant atuam em três pontos: pré-processamento (validação do input antes do processamento pelo agente, bloqueando prompt injections e sanitizando PII conforme requisitos de conformidade como HIPAA e PCI-DSS), pós-processamento (validação das respostas para precisão factual, detecção de alucinações e varredura por vazamento de dados sensíveis) e configurações por tenant ou tier.
O Amazon Bedrock Guardrails oferece filtragem de conteúdo e controles de segurança com políticas configuráveis para tópicos negados, filtros de conteúdo, filtros de palavras e redação de informações sensíveis.
Implementando os três padrões com o AgentCore
Padrão Silo
No modelo Silo, cada tenant opera dentro de uma stack totalmente isolada, com seu próprio AgentCore Runtime, AgentCore Gateway e AgentCore Memory, todos delimitados por fronteiras IAM separadas. O fluxo começa com a autenticação do usuário no provedor de identidade, que emite um JWT com o contexto do tenant. Um proxy da aplicação SaaS roteia a requisição para o agente correto com base nesse contexto, e o AgentCore Runtime valida o JWT, cria uma sessão microVM isolada e inicia o raciocínio do agente. Quando o agente precisa invocar ferramentas, chama o Gateway dedicado ao tenant, que valida o JWT, extrai o contexto e integra com os recursos backend específicos daquele tenant.
O trade-off é o maior overhead operacional, já que cada cliente executa recursos dedicados. Mas para workflows críticos de segurança e conformidade, o escopo limitado de impacto potencial justifica a escolha.
Padrão Pool
No modelo Pool, os recursos são compartilhados entre múltiplos tenants para maximizar a utilização e a eficiência operacional. O AgentCore Runtime e a lógica do agente são compartilhados, com o contexto do tenant extraído do JWT em cada execução. O AgentCore Memory é particionado com base no contexto do tenant usando namespace (por exemplo, actor_id: "tenant-a:user-123"). O Gateway centralizado roteia chamadas de ferramentas para recursos backend compartilhados, aplicando isolamento via credenciais e configurações com escopo por tenant.
O modelo Pool é altamente eficiente e pode ser a única opção viável quando há um grande número de tenants pequenos. O trade-off é a necessidade de maior rigor nos testes de controle de acesso granular e mais instrumentação para atribuição de custos por tenant.
Padrão Bridge
O modelo Bridge representa um meio-termo estratégico, combinando a eficiência de custo da infraestrutura compartilhada com os benefícios de segurança de recursos isolados. A ideia é poder escolher o nível de isolamento em cada camada e componente individualmente, em vez de estar preso a um padrão único. Por exemplo, é possível ter um AgentCore Runtime e Gateway siloed para tenants premium e um Runtime e Gateway pooled para tenants do tier padrão. Outra variação possível é um Runtime siloed com Gateway e ferramentas pooled.
Próximos passos
Este artigo cobre os conceitos fundamentais para construção de agentes multi-tenant. A AWS indicou que publicará posts subsequentes com implementações end-to-end dos modelos Pool e Silo, incorporando os componentes detalhados nas considerações de design. Para quem quiser colocar a mão na massa desde já, a AWS disponibilizou um workshop de agentes multi-tenant com experiência prática usando o Amazon Bedrock AgentCore.
Fonte
Building multi-tenant agents with Amazon Bedrock AgentCore (https://aws.amazon.com/blogs/machine-learning/building-multi-tenant-agents-with-amazon-bedrock-agentcore/)
