Controle onde seus agentes de IA navegam com políticas Chrome Enterprise no Amazon Bedrock AgentCore

O problema: agentes de IA com acesso irrestrito à web

Agentes de IA que navegam pela web sem restrições representam um risco real para organizações. Sem controles adequados, um agente pode acessar domínios não autorizados, armazenar credenciais no gerenciador de senhas do navegador ou baixar arquivos fora dos fluxos aprovados. Para empresas que operam serviços internos com uma Autoridade Certificadora (CA) privada, há ainda outro obstáculo: toda conexão HTTPS com esses serviços falha com erros de validação de certificado.

Para endereçar esses cenários, a AWS anunciou que o Amazon Bedrock AgentCore Browser agora oferece suporte a políticas Chrome Enterprise e certificados CA raiz personalizados. Com isso, as organizações ganham controle granular sobre o comportamento de navegação dos agentes — e podem conectá-los a infraestrutura interna com segurança.

O que muda com esse suporte

As políticas Chrome Enterprise permitem configurar mais de 450 configurações do navegador, incluindo filtragem de URLs, restrições de download e controle do gerenciador de senhas, tudo via configuração JSON padrão do Chrome Enterprise. Já o suporte a certificados CA raiz personalizados permite que os agentes se conectem a serviços internos e trabalhem com proxies corporativos que interceptam SSL, sem precisar desabilitar a validação de certificados.

Para referência completa das configurações disponíveis, a AWS disponibiliza a lista de políticas Chrome Enterprise.

Por que aplicar políticas de navegador em agentes de IA

As políticas Chrome Enterprise atendem a três necessidades organizacionais quando aplicadas a agentes de navegação:

  • Restringir o escopo do agente a domínios aprovados: listas de permissão e bloqueio de URLs limitam onde os agentes podem navegar. Um agente responsável por processar faturas em um portal específico não precisa de acesso a redes sociais ou mecanismos de busca. As políticas impõem esses limites no nível do navegador, independentemente do prompt ou do raciocínio do agente.
  • Desabilitar recursos arriscados do navegador: é possível desligar o gerenciador de senhas, bloquear downloads de arquivos, desativar o preenchimento automático e controlar dezenas de outras capacidades do navegador. Para agentes que interagem com sistemas sensíveis, esses controles reduzem o risco de armazenamento ou exfiltração não intencional de dados.
  • Separar o gerenciamento de políticas do desenvolvimento do agente: as políticas gerenciadas são configuradas no nível do navegador via API do plano de controle e se aplicam a todas as sessões criadas a partir daquele navegador. Isso permite que a equipe de segurança defina configurações aprovadas enquanto a equipe de desenvolvimento foca na lógica do agente, sem embutir decisões de política no código da aplicação.

Como as políticas e certificados CA raiz são aplicados

A integração funciona em duas camadas de aplicação de políticas, com uma configuração opcional de confiança de certificados:

  • Políticas gerenciadas operam no nível do navegador. Os arquivos JSON de política Chrome Enterprise são armazenados no Amazon Simple Storage Service (Amazon S3) e fornecidos ao criar um navegador via API do plano de controle. Essas políticas são armazenadas pelo serviço e aplicadas em todas as sessões. Elas mapeiam para o diretório /etc/chromium/policies/managed/ do Chrome e não podem ser substituídas por configurações de nível de sessão.
  • Políticas recomendadas operam no nível da sessão. Podem ser fornecidas ao iniciar uma sessão via API do plano de dados. Mapeiam para o diretório /etc/chromium/policies/recommended/ e funcionam como preferências do usuário. Se houver conflito entre uma política gerenciada e uma recomendada, a gerenciada tem precedência — comportamento padrão do Chrome.
  • Certificados CA raiz personalizados são armazenados no AWS Secrets Manager e referenciados ao criar um navegador ou um AgentCore Code Interpreter. O serviço importa o certificado para o repositório de confiança de certificados, fazendo com que conexões a serviços internos e proxies que interceptam SSL funcionem sem desabilitar a validação.

Arquitetura da solução

O diagrama abaixo ilustra como os arquivos JSON de política Chrome e os certificados CA raiz fluem do ambiente da organização pelo plano de controle e plano de dados do Amazon Bedrock AgentCore até a sessão de navegador isolada.

Imagem original — fonte: Aws

No ambiente da organização, os arquivos JSON de política ficam armazenados no Amazon S3, e os certificados CA raiz opcionais ficam no AWS Secrets Manager. O plano de controle busca a política no S3 ao chamar CreateBrowser (seta 1) e busca o certificado CA raiz no Secrets Manager, se configurado (seta 2, tracejada para indicar que é opcional). A aplicação chama a API CreateBrowser (seta 3) e depois a API StartBrowserSession (seta 4). O plano de controle passa os metadados de configuração do navegador para o plano de dados (seta 5). O plano de dados implanta políticas gerenciadas, recomendadas e certificados CA raiz na sessão isolada do navegador (seta 6). O Chrome lê a configuração mesclada na inicialização e aplica as políticas durante toda a sessão.

Pré-requisitos

Para seguir o tutorial, é necessário ter:

  • Python 3.10 ou superior
  • Uma conta AWS com acesso ao Amazon Bedrock AgentCore habilitado
  • Credenciais AWS configuradas (verificável com aws sts get-caller-identity)
  • Uma região AWS onde o Amazon Bedrock AgentCore esteja disponível (veja as regiões suportadas na documentação do AgentCore)
  • Acesso a um modelo de IA para conduzir o agente. O tutorial utiliza o Anthropic Claude via Amazon Bedrock. O AgentCore é agnóstico de modelo — outros provedores e frameworks de agentes podem ser substituídos. Para detalhes sobre configuração de diferentes modelos com o framework Strands Agents, veja Provedores de Modelos na documentação do Strands Agents.

O notebook cria automaticamente os recursos AWS necessários, incluindo o bucket S3, a função de execução do Gerenciamento de Identidade e Acesso (IAM), o AgentCore Browser e o AgentCore Code Interpreter. Esse provisionamento automático é voltado para demonstração. Implantações em produção devem usar recursos pré-existentes com políticas IAM de menor privilégio revisadas pela equipe de segurança. Consulte o README do repositório de exemplos para detalhes completos sobre as políticas IAM.

Importante: use credenciais temporárias do AWS IAM Identity Center ou do AWS Security Token Service (AWS STS). Não use chaves de acesso de longa duração. Siga o princípio do menor privilégio ao configurar permissões IAM.

Configurando o ambiente

O código completo do tutorial está disponível como um Jupyter notebook no repositório de exemplos. Clone e execute as células em sequência:

git clone https://github.com/awslabs/amazon-bedrock-agentcore-samples.git
cd amazon-bedrock-agentcore-samples/01-tutorials/05-AgentCore-tools/02-Agent-Core-browser-tool/13-browser-chrome-policies
python3 -m venv .venv
source .venv/bin/activate # On Windows: .venv\Scripts\activate
pip install -r requirements.txt
export AWS_REGION=us-west-2
jupyter notebook browser-chrome-policies.ipynb

Execute as células em sequência. A Parte 1 cobre as políticas Chrome Enterprise. A Parte 2 cobre os certificados CA raiz personalizados.

Walkthrough: políticas Chrome Enterprise na prática

Definindo a política Chrome Enterprise

As primeiras células do notebook definem uma política Chrome Enterprise que restringe o navegador à documentação da AWS e desabilita recursos desnecessários para o agente:

policy = {
    "URLBlocklist": ["*"],
    "URLAllowlist": [
        "docs.aws.amazon.com",
        ".aws.amazon.com",
        ".amazonaws.com",
    ],
    "PasswordManagerEnabled": False,
    "DownloadRestrictions": 3,
    "DeveloperToolsAvailability": 0,
    "BookmarkBarEnabled": False,
    "AutofillAddressEnabled": False,
    "AutofillCreditCardEnabled": False,
}

Cada configuração tem um propósito claro: URLBlocklist: ["*"] bloqueia todas as URLs por padrão; URLAllowlist libera apenas os domínios da AWS; PasswordManagerEnabled: false impede o armazenamento de credenciais; DownloadRestrictions: 3 bloqueia downloads; e as demais configurações desabilitam ferramentas de desenvolvimento, barra de favoritos e preenchimento automático.

Vale destacar: o URLAllowlist usa o formato de padrão de filtro de URL do Chrome, que difere dos padrões glob típicos. Padrões como docs.aws.amazon.com correspondem ao domínio exato. Um ponto inicial, como .aws.amazon.com, corresponde a subdomínios. Para a sintaxe completa de padrões, consulte a documentação da política URLAllowlist.

Atenção: o DeveloperToolsAvailability deve ser definido como 0 (ou omitido) para navegadores usados com Playwright ou outra automação baseada em CDP (Chrome DevTools Protocol). Definir esse valor como 2 desabilita o CDP no nível do Chrome, o que quebra silenciosamente a automação.

Criando um navegador com políticas gerenciadas

As próximas células criam um navegador personalizado que aplica a política em todas as sessões. O parâmetro-chave é o enterprise_policies com o tipo definido como MANAGED. A gravação de sessão também é habilitada para revisão posterior:

from bedrock_agentcore.tools import BrowserClient

client = BrowserClient(REGION)
response = client.create_browser(
    name="docs_research_browser",
    execution_role_arn=EXECUTION_ROLE_ARN,
    network_configuration={"networkMode": "PUBLIC"},
    enterprise_policies=[
        {
            "location": {
                "s3": {
                    "bucket": BUCKET_NAME,
                    "prefix": POLICY_KEY,
                }
            },
            "type": "MANAGED",
        }
    ],
    recording={
        "enabled": True,
        "s3Location": {
            "bucket": BUCKET_NAME,
            "prefix": "policy-demo",
        },
    },
)

Demonstrando a aplicação da política com Playwright

O notebook inicia uma sessão de navegador e usa o Playwright para navegar para duas URLs. A primeira, docs.aws.amazon.com, é permitida pela política e carrega com sucesso. A segunda, www.wikipedia.org, é bloqueada e o Chrome exibe uma página de erro. A saída esperada é:

TEST 1: Navigate to docs.aws.amazon.com (ALLOWED)
Page title: Overview - Amazon Bedrock AgentCore
Page text preview: Amazon Bedrock AgentCore ...
Result: PAGE LOADED SUCCESSFULLY

TEST 2: Navigate to www.wikipedia.org (BLOCKED)
Page title:
Result: CHROME POLICY BLOCKED THIS URL

Esse é o valor central das políticas Chrome: a restrição acontece no nível do navegador, independentemente do raciocínio ou das instruções de prompt do agente. Enquanto a célula é executada, é possível acompanhar o navegador ao vivo no console do Amazon Bedrock AgentCore.

Como a gravação de sessão foi habilitada, também é possível reproduzir a sessão depois para observar a aplicação das políticas — com linha do tempo interativa, ações do usuário com timestamp e eventos de rede confirmando que apenas o tráfego permitido teve sucesso.

Consulte o notebook de exemplo para o código completo.

Parte 2: Certificados CA raiz personalizados

Organizações que executam serviços internos com CAs privadas, ou roteiam tráfego por proxies corporativos que interceptam SSL, precisam que os agentes confiem nesses certificados não públicos. O AgentCore Browser e o AgentCore Code Interpreter suportam certificados CA raiz personalizados para esse propósito.

Para demonstração, o tutorial usa https://untrusted-root.badssl.com, um site público que intencionalmente apresenta um certificado assinado por uma CA raiz não confiável. Conexões HTTPS a esse site falham com erros de validação de certificado — exatamente como ocorreria com serviços internos sem o CA raiz correto.

O notebook executa três etapas:

  1. Armazenar o certificado CA raiz no AWS Secrets Manager: o certificado CA raiz não confiável do BadSSL está disponível publicamente (fonte: badssl.com/certs/ca-untrusted-root.crt). O notebook o salva no AWS Secrets Manager para que o Amazon Bedrock AgentCore possa importá-lo para o repositório de confiança de certificados.
  2. Demonstrar a falha sem o CA raiz: o notebook cria uma sessão padrão do AgentCore Code Interpreter e executa código Python que chama urllib.request.urlopen() contra o site não confiável. A conexão falha com um SSLCertVerificationError.
  3. Demonstrar o sucesso com o CA raiz: o notebook cria um AgentCore Code Interpreter personalizado que confia no certificado CA raiz do BadSSL usando o parâmetro certificates:
from bedrock_agentcore.tools import CodeInterpreter, Certificate

ci_client_with_ca = CodeInterpreter(REGION)
response = ci_client_with_ca.create_code_interpreter(
    name="demo_rootca_interpreter",
    execution_role_arn=EXECUTION_ROLE_ARN,
    network_configuration={"networkMode": "PUBLIC"},
    certificates=[Certificate.from_secret_arn(secret_arn)],
)

Após executar o mesmo código urlopen() contra o interpretador personalizado, a saída mostra Status: 200. A conexão é bem-sucedida porque o CA raiz do BadSSL agora é confiável. Nenhuma alteração de código foi necessária — a confiança foi configurada no nível da infraestrutura.

Consulte o notebook de exemplo para o código completo.

Aplicando ao seu ambiente corporativo

A demonstração com o badssl.com espelha dois cenários reais:

  • Serviços corporativos internos: armazene o certificado CA raiz da organização (aquele que assina certificados para o portal de RH, Jira, Artifactory e serviços similares) no AWS Secrets Manager e referencie o ARN do secret em certificates ao criar um navegador ou AgentCore Code Interpreter.
  • Proxies corporativos que interceptam SSL: armazene o certificado CA raiz do proxy (usado por Zscaler, Palo Alto Networks ou similares) no AWS Secrets Manager e referencie o ARN em certificates, combinando com as configurações de proxy.

Os certificados CA raiz personalizados funcionam tanto com o AgentCore Browser quanto com o AgentCore Code Interpreter. No navegador, o certificado é importado para o repositório de confiança do Chrome. No interpretador, o serviço configura variáveis de ambiente como REQUESTS_CA_BUNDLE e SSL_CERT_FILE para que bibliotecas Python confiem na CA personalizada sem contornos no nível do código.

É possível combinar certificados CA raiz com políticas Chrome em um único navegador. O exemplo a seguir cria um navegador conectado a uma Nuvem Privada Virtual (VPC) que confia em uma CA interna e restringe a navegação a uma intranet corporativa:

from bedrock_agentcore.tools import BrowserClient, Certificate

response = client.create_browser(
    name="internal_locked_down_browser",
    execution_role_arn=EXECUTION_ROLE_ARN,
    network_configuration={
        "networkMode": "VPC",
        "vpcConfig": {
            "securityGroups": ["sg-0123456789abcdef0"],
            "subnets": ["subnet-0123456789abcdef0"],
        }
    },
    enterprise_policies=[
        {
            "location": {
                "s3": {
                    "bucket": "org-policies",
                    "prefix": "intranet-only-policy.json",
                }
            },
            "type": "MANAGED",
        }
    ],
    certificates=[
        Certificate.from_secret_arn(
            "arn:aws:secretsmanager:us-west-2:123456789012:secret:corp-root-ca"
        )
    ],
)

Limpeza de recursos

Para evitar cobranças, execute as células de limpeza ao final do notebook. Elas encerram as sessões de navegador ativas e excluem o navegador personalizado, o AgentCore Code Interpreter, a função IAM, o secret do Secrets Manager e o arquivo de política no S3. Sessões do Amazon Bedrock AgentCore Browser geram cobranças enquanto estão ativas. Para detalhes de preços, consulte a página de preços do Amazon Bedrock AgentCore.

Próximos passos

Para começar, crie um navegador com uma lista de permissão de URLs adaptada ao seu caso de uso. A lista de políticas Chrome Enterprise documenta mais de 450 configurações. Para agentes de entrada de dados que interagem com formulários sensíveis, considere desabilitar o preenchimento automático e o gerenciador de senhas. Para agentes que processam documentos em um portal específico, restrinja downloads e limite a navegação ao domínio desse portal.

Se a organização usa infraestrutura de chave pública (PKI) privada, configure certificados CA raiz e teste a conectividade com os serviços internos. Para agentes que operam atrás de proxies que interceptam SSL, combine a configuração de CA raiz com o recurso de configuração de proxy para rotear o tráfego pelo proxy corporativo enquanto confia no seu certificado.

Para mais informações sobre as capacidades do Amazon Bedrock AgentCore Browser, consulte a documentação do Amazon Bedrock AgentCore Browser. Para feedback, abra uma issue no repositório do Amazon Bedrock AgentCore Python SDK.

Importante: o código de exemplo é destinado a desenvolvimento e demonstração. Para implantações em produção, siga o princípio do menor privilégio para permissões IAM, restrinja as políticas de bucket do Amazon S3 a entidades autorizadas, faça a rotação dos certificados do AWS Secrets Manager antes do vencimento e siga o pilar de segurança do AWS Well-Architected Framework.

Fonte

Control where your AI agents can browse with Chrome enterprise policies on Amazon Bedrock AgentCore (https://aws.amazon.com/blogs/machine-learning/control-where-your-ai-agents-can-browse-with-chrome-enterprise-policies-on-amazon-bedrock-agentcore/)

Comments

Leave a Reply

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