User's blog

Controle quais domínios seus agentes de IA podem acessar

Written by

Make.com Service User

in

O desafio de dar acesso à internet para agentes de IA

Agentes de inteligência artificial que conseguem navegar pela web abrem possibilidades impressionantes — desde automação de pesquisas até coleta de dados em tempo real. Porém, fornecer acesso irrestrito à internet para um agente de IA levanta preocupações legítimas sobre segurança e conformidade regulatória. E se o agente acessar websites não autorizados? E se dados sensíveis forem exfiltrados para domínios externos?

O Amazon Bedrock AgentCore fornece ferramentas gerenciadas que permitem agentes de IA interagir com a web através do navegador, executar código e ser hospedados em ambiente gerenciado. Quando implantado em uma Nuvem Privada Virtual da AWS (Amazon VPC), você consegue controlar o acesso à rede das ferramentas utilizando o AWS Network Firewall para implementar filtragem baseada em domínios.

Por que isso importa para empresas

Requisitos de segurança em setores regulados

Organizações em indústrias reguladas que implantam agentes de IA têm demandas consistentes e rigorosas em relação ao controle de tráfego de rede — tanto entrada quanto saída. Clientes em setores altamente regulados (como serviços financeiros) exigem explicações detalhadas sobre como o tráfego dos agentes é controlado e auditado. Esses clientes querem garantias de que os endpoints de tempo de execução permaneçam privados e que controles adicionais, como proteção de firewall de aplicações web, estejam disponíveis.

Requisitos de provedores SaaS multi-tenant

Empresas de Software como Serviço (SaaS) com múltiplos clientes precisam de controles granulares em nível de DNS, pois suas arquiteturas multi-tenant exigem políticas de rede específicas por cliente. Por exemplo, o Cliente A pode precisar permitir domínios que o Cliente B bloqueia. Requisitos comuns incluem: bloqueio específico de execução (impedir acesso a certos domínios durante launches específicas do navegador), restrições regionais e regras baseadas em categorias (desabilitar sites de jogos ou redes sociais através de conjuntos de regras pré-configurados).

Mitigação de vulnerabilidades e conformidade

Equipes de segurança identificaram que agentes de IA podem ser enganados para navegar para sites intencionais através de ataques de injeção de prompts. Listas de permissão de URLs customizadas reduzem a superfície de ataque ao restringir o navegador apenas aos domínios aprovados, independentemente do que o agente for instruído a fazer. Filtragem de egresso baseada em domínios fornece o logging e visibilidade de controle de acesso que equipes de segurança frequentemente precisam para seus processos de monitoramento.

Arquitetura da solução

A solução implanta o AgentCore Browser em uma subnet privada sem acesso direto à internet. O tráfego de saída é roteado através do AWS Network Firewall, que inspeciona os headers de Indicação de Nome de Servidor TLS (SNI) para determinar o domínio de destino e aplicar regras de filtragem. Você também consegue monitorar as ações do Network Firewall através da integração nativa com métricas do Amazon CloudWatch.

Implantação do AgentCore com AWS Network Firewall e filtragem de egresso baseada em domínios — Fonte: Aws

Componentes da arquitetura

A arquitetura inclui:

  • Subnet privada: hospeda instâncias do AgentCore Browser sem endereços IP públicos
  • Subnet pública: contém o NAT Gateway para conectividade de saída
  • Subnet de firewall: hospeda o endpoint do Network Firewall
  • Tabelas de rota: quatro tabelas que controlam o fluxo de tráfego através do firewall para requisições de saída e tráfego de retorno

Fluxo de tráfego

O fluxo funciona em etapas sequenciais:

  • O AgentCore Runtime executa o agente e invoca a ferramenta AgentCore Browser
  • AgentCore Browser inicia uma requisição HTTPS da subnet privada
  • A tabela de rotas da subnet privada direciona tráfego ao NAT Gateway na subnet pública
  • O NAT Gateway traduz o endereço IP privado e encaminha a requisição ao endpoint do Network Firewall
  • Network Firewall inspeciona o header SNI do TLS para identificar o domínio de destino
  • Se o domínio corresponder a uma regra de lista de permissão, o firewall encaminha tráfego ao Internet Gateway
  • O Internet Gateway roteia tráfego aprovado para o destino externo
  • Tráfego de retorno segue o caminho simétrico de volta através do firewall para o agente

Esta arquitetura garante que tráfego de navegador seja inspecionado e filtrado, independentemente do destino.

Implementação prática

Pré-requisitos

Antes de começar, certifique-se de ter:

  • Uma conta AWS com permissões para criar recursos de VPC, Network Firewall e funções IAM
  • AWS Command Line Interface (AWS CLI) versão 2.x configurada com credenciais apropriadas
  • Acesso ao Amazon Bedrock AgentCore
  • Familiaridade básica com conceitos de redes VPC

Passo 1: Deploy de recursos

Para a configuração completa e passo a passo do VPC e Network Firewall, consulte a documentação de configuração VPC do Amazon Bedrock AgentCore. Esta seção destaca configurações específicas para o AgentCore Browser.

Inicie o deploy do template CloudFormation:

Você pode manter os valores padrão do stack. No entanto, certifique-se de adicionar um nome de stack (por exemplo, "agentcore-egress") ao campo "Stack name", escolha uma Zona de Disponibilidade no menu "Availability Zone" e inclua um nome de bucket existente válido no parâmetro "BucketConfigForOutput". Aguarde a conclusão da criação do stack, que normalmente leva 10 minutos. Continue com os próximos passos após o status do stack mudar para CREATE_COMPLETE.

Passo 2: Revisar a função de execução IAM

AgentCore Browser requer uma função IAM com política de confiança para o serviço bedrock-agentcore.amazonaws.com:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "bedrock-agentcore.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Passo 3: Configurar lista de permissão do Network Firewall

Crie um grupo de regras stateful com seus domínios aprovados. Note o ponto à frente (.) para corresponder a subdomínios:

cat > allowlist-rules.json << 'EOF'
{
  "RulesSource": {
    "RulesSourceList": {
      "Targets": [
        ".wikipedia.org",
        ".stackoverflow.com",
        ".docs.aws.amazon.com",
        ".amazonaws.com",
        ".pypi.org",
        ".pythonhosted.org"
      ],
      "TargetTypes": ["HTTP_HOST", "TLS_SNI"],
      "GeneratedRulesType": "ALLOWLIST"
    }
  },
  "StatefulRuleOptions": {
    "RuleOrder": "STRICT_ORDER"
  }
}
EOF
aws network-firewall create-rule-group \
  --rule-group-name browser-allowed-domains \
  --type STATEFUL \
  --capacity 100 \
  --rule-group file://allowlist-rules.json \
  --region us-east-2

Importante: inclua .amazonaws.com na sua lista de permissão se o navegador precisar acessar serviços AWS ou use VPC Endpoints como alternativa.

Passo 4: Configurar política de firewall

A política de firewall deve usar aws:drop_established como ação padrão. Isso permite que handshakes TCP sejam concluídos (necessário para inspeção SNI do TLS) enquanto bloqueia conexões para domínios não permitidos:

cat > firewall-policy.json << 'EOF'
{
  "StatelessDefaultActions": ["aws:forward_to_sfe"],
  "StatelessFragmentDefaultActions": ["aws:forward_to_sfe"],
  "StatefulRuleGroupReferences": [
    {
      "ResourceArn": "arn:aws:network-firewall:us-east-2:ACCOUNT_ID:stateful-rulegroup/browser-allowed-domains",
      "Priority": 1
    }
  ],
  "StatefulEngineOptions": {
    "RuleOrder": "STRICT_ORDER"
  },
  "StatefulDefaultActions": ["aws:drop_established"]
}
EOF

Passo 5: Criar grupo de segurança

Crie um grupo de segurança que permita tráfego de saída. O Network Firewall cuida da filtragem de domínios:

# Create security group
aws ec2 create-security-group \
  --group-name agentcore-egress-sg \
  --description "AgentCore tools - egress only, filtered by Network Firewall" \
  --vpc-id vpc-XXXXXXXXX \
  --region us-east-2

# Allow all outbound traffic (Network Firewall handles filtering)
aws ec2 authorize-security-group-egress \
  --group-id sg-XXXXXXXXX \
  --protocol -1 \
  --port -1 \
  --cidr 0.0.0.0/0 \
  --region us-east-2

# Remove default inbound rules if present (AgentCore tools don't need inbound)
aws ec2 revoke-security-group-ingress \
  --group-id sg-XXXXXXXXX \
  --protocol -1 \
  --port -1 \
  --cidr 0.0.0.0/0 \
  --region us-east-2

Passo 6: Criar AgentCore Browser

Crie o navegador com configuração VPC apontando para sua subnet privada:

aws bedrock-agentcore-control create-browser \
  --name my_secure_browser \
  --execution-role-arn arn:aws:iam::ACCOUNT_ID:role/AgentCoreBrowserExecutionRole \
  --network-configuration '{
    "networkMode": "VPC",
    "vpcConfig": {
      "securityGroups": ["sg-XXXXXXXXX"],
      "subnets": ["subnet-XXXXXXXXX"]
    }
  }' \
  --region us-east-2

Passo 7: Testar a configuração

Inicie uma sessão de navegador e verifique que as regras de firewall funcionam corretamente:

# Start browser session
aws bedrock-agentcore start-browser-session \
  --browser-identifier my_secure_browser-ABC123xyz \
  --region us-east-2

Use a URL WebSocket retornada com uma ferramenta de automação de navegador como Playwright para testar domínios permitidos e bloqueados.

Monitoramento via CloudWatch

Verifique os logs de firewall no CloudWatch para tentativas de conexão bloqueadas:

# View recent alert logs (blocked connections)
aws logs filter-log-events \
  --log-group-name "/aws/network-firewall/agentcore-egress/alerts" \
  --filter-pattern '{ $.event.alert.action = "blocked" }' \
  --region us-east-2 \
  --start-time $(($(date +%s) - 300))000

Boas práticas e considerações

Práticas recomendadas

  • Use avaliação STRICT_ORDER: facilita processamento previsível de regras ao combinar listas de permissão e bloqueio
  • Inclua .amazonaws.com para acesso a serviços AWS: ou use VPC Endpoints para evitar rotear chamadas de API através da internet
  • Configure a tabela de rotas de entrada do IGW: crítico para roteamento simétrico. Sem isso, tráfego de retorno bypassa o firewall
  • Habilite logs ALERT e FLOW: logs ALERT capturam conexões bloqueadas; logs FLOW fornecem metadados de conexão
  • Aguarde sincronização do firewall: mudanças de regras levam alguns minutos para se propagar
  • Configure HOME_NET para arquiteturas multi-VPC: por padrão, inspeção de domínio do Network Firewall filtra apenas tráfego originário da faixa CIDR da VPC de deployment

Limitações e considerações de custo

Inspeção de conteúdo requer inspeção TLS: por padrão, filtragem de domínio opera em metadados TLS não criptografados (headers SNI) e não consegue inspecionar corpos de requisição ou resposta criptografados.

Risco de bypass de header SNI/Host: o Network Firewall usa headers SNI do TLS e headers Host HTTP — não endereços IP — para determinar domínios de destino. Se esses headers forem manipulados, tráfego pode contornar filtragem de domínio. Para deployments de alta segurança, combine regras de domínio com regras baseadas em IP para destinos bloqueados críticos, ou adicione filtragem DNS como camada adicional.

Escopo de HOME_NET em deployments multi-VPC: por padrão, inspeção de domínio do Network Firewall aplica-se apenas ao tráfego originário da faixa CIDR da VPC de deployment. Se você usar firewall centralizado com AWS Transit Gateway (múltiplas VPCs roteando através de um firewall compartilhado), você deve configurar a variável HOME_NET em seu grupo de regras para incluir faixas CIDR de origem.

Custos variam conforme seu uso. Consulte os preços de NAT Gateway e Network Firewall para taxas atuais.

Limpeza de recursos

Delete recursos nesta ordem para evitar cobranças contínuas:

  • Delete o AgentCore Browser
  • Delete o Network Firewall (desabilite configurações de proteção primeiro)
  • Delete o NAT Gateway
  • Libere o endereço IP elástico
  • Delete as subnets e tabelas de rota
  • Desanexe e delete o Internet Gateway
  • Delete a VPC

Nota: AgentCore Browser e Code Interpreter criam interfaces de rede elásticas em sua VPC. Após deletar esses recursos, aguarde alguns minutos para a interface de rede ser liberada antes de deletar o grupo de segurança, subnet ou VPC.

Próximos passos

Filtragem de domínio através de inspeção SNI é uma camada de segurança de egresso. Dependendo de seus requisitos, considere essas mitigações adicionais:

  • Route 53 DNS Firewall: ajuda a bloquear ou permitir consultas DNS por domínio e previne tunneling e exfiltração de DNS. Útil quando você precisa de filtragem em nível DNS ou proteção contra exfiltração de dados baseada em DNS.
  • Inspeção TLS + Suricata DLP: descriptografa HTTPS, inspeciona corpos de requisição/resposta com regras Suricata, ajuda a bloquear padrões de dados sensíveis (PII, credenciais). Necessário quando você precisa de prevenção de perda de dados (DLP) para tráfego gerado por agentes.
  • Arquitetura de inspeção centralizada: roteia tráfego de múltiplas VPCs através de uma VPC de inspeção compartilhada com Network Firewall. Útil quando você tem múltiplos deployments do AgentCore e quer enforcement de política centralizado.

Quando usar inspeção TLS, configure certificados customizados em seus recursos do AgentCore para confiar na CA de re-assinatura do Network Firewall.

Conclusão

Ao combinar ferramentas do Amazon Bedrock AgentCore com AWS Network Firewall, você consegue dar aos agentes de IA acesso controlado à web mantendo segurança e alinhamento de conformidade. A abordagem de filtragem baseada em domínios permite definir precisamente quais websites agentes podem acessar, bloquear destinos indesejados e fazer logging de tentativas de conexão para fins de auditoria.

Esta arquitetura resolve as preocupações de segurança levantadas por clientes corporativos: conformidade em setores regulados fornece isolamento de rede e logging de auditoria necessários para revisões de segurança em nível CISO, controle multi-tenant habilita políticas de domínio por cliente ou por execução para provedores SaaS, defesa contra injeção de prompts restringe navegação de agentes a domínios aprovados reduzindo superfície de ataque, e evidência de auditoria gera logs no CloudWatch que suportam requisitos de conformidade.

Para empresas implantando agentes de IA que precisam de acesso à internet para pesquisa, coleta de dados ou integrações de API, este padrão fornece uma abordagem production-ready para manter controle rigoroso sobre onde esse acesso leva. Em vez de manter proxies squid customizados ou infraestrutura de rede complexa, você consegue usar serviços gerenciados da AWS para implementar filtragem de egresso em nível corporativo em horas, não semanas.

Para mais informações sobre AgentCore Browser, consulte a documentação do AgentCore Browser.

Recursos relacionados

Fonte

Control which domains your AI agents can access (https://aws.amazon.com/blogs/machine-learning/control-which-domains-your-ai-agents-can-access/)

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

More posts