O desafio de servir múltiplos clientes com requisitos diferentes
Provedores de Software como Serviço (SaaS) que constroem aplicações de IA sobre o Amazon Bedrock AgentCore frequentemente se deparam com um problema clássico: precisam atender múltiplos clientes (tenants) com exigências de segurança completamente distintas, tudo a partir de uma infraestrutura compartilhada.
Alguns clientes precisam de acesso entre contas da Amazon Web Services (AWS). Outros, por questões regulatórias, exigem que o tráfego fique restrito a uma Nuvem Privada Virtual (VPC). Sem um controle centralizado no nível do recurso, gerenciar essa diversidade se torna complexo e propenso a erros.
A AWS documentou como o AgentCore suporta políticas baseadas em recursos — um mecanismo que oferece controle centralizado sobre quem pode acessar o AgentCore Runtime e seus endpoints, e sob quais condições. A seguir, exploramos o cenário prático e o passo a passo técnico apresentados no blog oficial.
O cenário multi-tenant
Imagine um provedor SaaS que opera uma plataforma de atendimento ao cliente com IA. Ele usa o AgentCore para implantar agentes inteligentes que respondem dúvidas de produtos, processam devoluções e escalam casos complexos para atendentes humanos. Dois clientes empresariais compartilham esse mesmo agente, mas com requisitos de segurança bem diferentes:
- Tenant A — Example Corp: grande varejista operando na conta AWS
111122223333. Sua equipe de desenvolvimento e equipe de administração precisam invocar o agente diretamente da própria conta AWS, sem necessidade de compartilhamento de credenciais. Não há restrições de rede — qualquer caminho de acesso é válido, desde que as credenciais AWS sejam válidas. - Tenant B — AnyCompany: empresa de saúde operando na conta AWS
444455556666. Por exigências de conformidade com a regulação HIPAA, todo o tráfego ao agente de IA deve originar-se exclusivamente de dentro de uma VPC privada (vpc-health1234). Qualquer chamada de API feita fora desse perímetro de rede deve ser bloqueada, mesmo que venha de uma role com credenciais válidas.
O provedor SaaS opera na conta 555555555555, na região us-west-2, com um AgentCore Runtime chamado support-agent-runtime e um AgentCore Runtime endpoint padrão (DEFAULT). Ambos os tenants compartilham essa mesma infraestrutura.
Arquitetura da solução
A solução utiliza políticas baseadas em recursos aplicadas tanto ao AgentCore Runtime quanto ao AgentCore Runtime endpoint. O diagrama abaixo ilustra os dois padrões de acesso em ação:
A conta do provedor SaaS hospeda o AgentCore Runtime e o endpoint. A Example Corp acessa o agente entre contas usando roles do AWS Identity and Access Management (IAM) autenticadas com Signature Version 4 (SigV4), o protocolo padrão de assinatura de requisições AWS. A AnyCompany também acessa entre contas, mas com uma restrição adicional: todas as requisições devem passar por um endpoint de VPC para o AgentCore.
Um detalhe crítico: as políticas baseadas em recursos precisam ser aplicadas tanto no AgentCore Runtime quanto no AgentCore Runtime endpoint. Para operações InvokeAgentRuntime, a AWS avalia as políticas nos dois recursos — se qualquer um deles negar o acesso ou não tiver um Allow explícito, a requisição é bloqueada.
Implementação passo a passo
Pré-requisitos
Antes de começar, é necessário ter:
- Uma conta AWS com acesso ao AgentCore e permissões para chamar
PutResourcePolicy,GetResourcePolicyeDeleteResourcePolicy - AWS Command Line Interface (AWS CLI) v2 instalada e configurada com a API
bedrock-agentcore-controldisponível - Um AgentCore Runtime com autenticação SigV4 e um endpoint DEFAULT apontando para a versão mais recente
- Para o cenário com restrição de VPC: um endpoint de VPC de interface para o AgentCore configurado na VPC do tenant. Veja mais em Interface VPC endpoints para Amazon Bedrock AgentCore
Passo 1: Acesso entre contas para a Example Corp (Tenant A)
Sem políticas baseadas em recursos, habilitar acesso entre contas normalmente exigiria que as roles da Example Corp assumissem uma role na conta do provedor via encadeamento de roles IAM — adicionando complexidade operacional e criando roles adicionais que precisariam ser mantidas para cada tenant. Com políticas baseadas em recursos, as roles da Example Corp recebem acesso direto ao AgentCore Runtime e ao endpoint, sem encadeamento de roles.
Política baseada em recurso para o AgentCore Runtime — salve como runtime-policy.json:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowExampleCorpCrossAccountAccess",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:role/DeveloperRole",
"arn:aws:iam::111122223333:role/AdminRole"
]
},
"Action": "bedrock-agentcore:InvokeAgentRuntime",
"Resource": "arn:aws:bedrock-agentcore:us-west-2:555555555555:runtime/support-agent-runtime"
}
]
}Política baseada em recurso para o AgentCore Runtime endpoint — salve como endpoint-policy.json:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowExampleCorpCrossAccountAccess",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:role/DeveloperRole",
"arn:aws:iam::111122223333:role/AdminRole"
]
},
"Action": "bedrock-agentcore:InvokeAgentRuntime",
"Resource": "arn:aws:bedrock-agentcore:us-west-2:999999999999:runtime/support-agent-runtime/runtime-endpoint/DEFAULT"
}
]
}Aplicar as políticas:
aws bedrock-agentcore-control put-resource-policy \
--resource-arn arn:aws:bedrock-agentcore:us-west-2:555555555555:runtime/support-agent-runtime \
--policy file://runtime-policy.json \
--region us-west-2
aws bedrock-agentcore-control put-resource-policy \
--resource-arn arn:aws:bedrock-agentcore:us-west-2:555555555555:runtime/support-agent-runtime/runtime-endpoint/DEFAULT \
--policy file://endpoint-policy.json \
--region us-west-2Verificar as políticas:
aws bedrock-agentcore-control get-resource-policy \
--resource-arn arn:aws:bedrock-agentcore:us-west-2:555555555555:runtime/support-agent-runtime \
--region us-west-2
aws bedrock-agentcore-control get-resource-policy \
--resource-arn arn:aws:bedrock-agentcore:us-west-2:555555555555:runtime/support-agent-runtime/runtime-endpoint/DEFAULT \
--region us-west-2Política baseada em identidade na conta da Example Corp — políticas baseadas em recursos sozinhas não são suficientes para acesso entre contas. A Example Corp também precisa anexar uma política baseada em identidade às roles DeveloperRole e AdminRole na conta 111122223333:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowInvokeAgentRuntime",
"Effect": "Allow",
"Action": "bedrock-agentcore:InvokeAgentRuntime",
"Resource": [
"arn:aws:bedrock-agentcore:us-west-2:555555555555:runtime/support-agent-runtime",
"arn:aws:bedrock-agentcore:us-west-2:555555555555:runtime/support-agent-runtime/runtime-endpoint/DEFAULT"
]
}
]
}Passo 2: Acesso entre contas com restrição de VPC para a AnyCompany (Tenant B)
A AnyCompany opera sob conformidade HIPAA e exige que todo o tráfego ao agente permaneça dentro de um caminho de rede privado. Assim como a Example Corp, ela precisa de acesso entre contas — mas com uma restrição adicional: as requisições devem originar-se da VPC vpc-health1234 via endpoint de VPC de interface. Qualquer requisição fora dessa VPC é negada, mesmo que venha da ApplicationRole com credenciais válidas.
Para isso, as políticas baseadas em recursos são atualizadas com um par de declarações: um Allow para a ApplicationRole e um Deny explícito para qualquer requisição que não venha da VPC aprovada. A condição StringNotEquals sobre aws:SourceVpc garante que, se o valor não corresponder a vpc-health1234 — ou se a chave estiver ausente porque nenhum endpoint de VPC foi usado — o bloqueio entra em vigor. Como um Deny explícito sempre sobrepõe qualquer Allow, esse padrão garante que nenhuma outra política possa inadvertidamente conceder acesso de fora da VPC.
Adicione os seguintes statements ao runtime-policy-v2.json, junto com os statements da Example Corp do Passo 1:
{
"Sid": "AllowAnyCompanyCrossAccountAccess",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::444455556666:role/ApplicationRole"
},
"Action": "bedrock-agentcore:InvokeAgentRuntime",
"Resource": "arn:aws:bedrock-agentcore:us-west-2:555555555555:runtime/support-agent-runtime"
},
{
"Sid": "DenyAnyCompanyOutsideVpc",
"Effect": "Deny",
"Principal": {
"AWS": "arn:aws:iam::444455556666:role/ApplicationRole"
},
"Action": "bedrock-agentcore:InvokeAgentRuntime",
"Resource": "arn:aws:bedrock-agentcore:us-west-2:555555555555:runtime/support-agent-runtime",
"Condition": {
"StringNotEquals": {
"aws:SourceVpc": "vpc-health1234"
}
}
}Adicione os statements equivalentes ao endpoint-policy-v2.json:
{
"Sid": "AllowAnyCompanyCrossAccountAccess",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::444455556666:role/ApplicationRole"
},
"Action": "bedrock-agentcore:InvokeAgentRuntime",
"Resource": "arn:aws:bedrock-agentcore:us-west-2:555555555555:runtime/support-agent-runtime/runtime-endpoint/DEFAULT"
},
{
"Sid": "DenyHealthFirstOutsideVpc",
"Effect": "Deny",
"Principal": {
"AWS": "arn:aws:iam::444455556666:role/ApplicationRole"
},
"Action": "bedrock-agentcore:InvokeAgentRuntime",
"Resource": "arn:aws:bedrock-agentcore:us-west-2:555555555555:runtime/support-agent-runtime/runtime-endpoint/DEFAULT",
"Condition": {
"StringNotEquals": {
"aws:SourceVpc": "vpc-health1234"
}
}
}Como o comando put-resource-policy substitui toda a política do recurso, os arquivos atualizados devem incluir tanto os statements da AnyCompany quanto os da Example Corp do Passo 1.
Aplicar as políticas atualizadas:
aws bedrock-agentcore-control put-resource-policy \
--resource-arn arn:aws:bedrock-agentcore:us-west-2:555555555555:runtime/support-agent-runtime \
--policy file://runtime-policy-v2.json \
--region us-west-2
aws bedrock-agentcore-control put-resource-policy \
--resource-arn arn:aws:bedrock-agentcore:us-west-2:555555555555:runtime/support-agent-runtime/runtime-endpoint/DEFAULT \
--policy file://endpoint-policy-v2.json \
--region us-west-2Verificar as políticas atualizadas:
# Verificar política do Agent Runtime
aws bedrock-agentcore-control get-resource-policy \
--resource-arn arn:aws:bedrock-agentcore:us-west-2:555555555555:runtime/support-agent-runtime \
--region us-west-2
# Verificar política do Agent Runtime Endpoint
aws bedrock-agentcore-control get-resource-policy \
--resource-arn arn:aws:bedrock-agentcore:us-west-2:555555555555:runtime/support-agent-runtime/runtime-endpoint/DEFAULT \
--region us-west-2Política baseada em identidade na conta da AnyCompany — a restrição de VPC é aplicada inteiramente na conta do provedor, por meio da condição na política baseada em recurso. Portanto, a política baseada em identidade da AnyCompany não precisa de condições de VPC, mantendo a configuração do lado do tenant simples:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowInvokeAgentRuntime",
"Effect": "Allow",
"Action": "bedrock-agentcore:InvokeAgentRuntime",
"Resource": [
"arn:aws:bedrock-agentcore:us-west-2:555555555555:runtime/support-agent-runtime",
"arn:aws:bedrock-agentcore:us-west-2:555555555555:runtime/support-agent-runtime/runtime-endpoint/DEFAULT"
]
}
]
}Considerações sobre autenticação OAuth
As políticas apresentadas até aqui usam autenticação SigV4 com principals de roles IAM específicas. Se o AgentCore Runtime ou o AgentCore Gateway estiver configurado com autenticação OAuth, a estrutura do principal muda. Recursos autenticados via OAuth requerem um principal curinga ("Principal": "*"), pois a identidade do chamador vem de um Token Web JSON (JWT) validado antes da avaliação da política. Requisições anônimas ou não autenticadas são rejeitadas antes mesmo de a política ser avaliada, então o curinga não significa acesso aberto.
Para restringir requisições OAuth a uma VPC específica, basta combinar o principal curinga com uma condição de VPC na política baseada em recurso. Vale notar que chaves de condição baseadas em principal IAM — como aws:PrincipalAccount e aws:PrincipalOrgID — não são populadas no contexto de autenticação OAuth. Apenas chaves de condição de nível de rede (como aws:SourceVpc, aws:SourceVpce, aws:SourceIp) estão disponíveis. Veja mais detalhes em políticas baseadas em recursos para Amazon Bedrock AgentCore.
Entendendo a avaliação das políticas
Para consolidar o entendimento, vale observar como a AWS avalia as políticas em diferentes cenários:
- Example Corp, qualquer rede: política de identidade permite + política do runtime permite + política do endpoint permite → Acesso concedido
- AnyCompany, de dentro da VPC: política de identidade permite + condição
aws:SourceVpccorresponde em ambos os recursos → Acesso concedido - AnyCompany, fora da VPC: condição
aws:SourceVpcnão corresponde → Deny explícito em ambos os recursos → Acesso negado - Qualquer outra role entre contas, qualquer rede: sem Allow correspondente na política do recurso → Acesso negado
- Qualquer role sem política de identidade: mesmo com Allow no recurso, a ausência de política de identidade bloqueia o acesso entre contas → Acesso negado
Conclusão
O que a AWS demonstra nesse guia é uma abordagem elegante para um problema real de plataformas SaaS multi-tenant: como oferecer controles de segurança distintos para cada cliente sem duplicar infraestrutura. A Example Corp obtém integração entre contas sem complexidade de gerenciamento de credenciais. A AnyCompany obtém o isolamento de rede exigido pela sua equipe de conformidade, com a garantia de que interações envolvendo informações potencialmente sensíveis ficam dentro do perímetro de rede controlado.
Ambos os tenants compartilham o mesmo AgentCore Runtime e endpoint, mas cada um tem controles de segurança sob medida aplicados no nível do recurso. Políticas baseadas em recursos complementam as políticas baseadas em identidade do IAM, oferecendo controle em camadas sobre quais principals podem invocar quais agentes e a partir de quais caminhos de rede.
Para aprofundar o tema, a AWS recomenda:
- Documentação do Amazon Bedrock AgentCore
- Políticas baseadas em recursos para Amazon Bedrock AgentCore
- Chaves de condição globais da AWS, incluindo aws:SourceVpce e aws:PrincipalOrgID
- AWS Well-Architected Framework — Pilar de Segurança para boas práticas de multi-tenancy
Fonte
Secure multi-tenant AI agents with Amazon Bedrock AgentCore resource-based policies (https://aws.amazon.com/blogs/security/secure-multi-tenant-ai-agents-with-amazon-bedrock-agentcore-resource-based-policies/)
Leave a Reply