Amazon Bedrock AgentCore abre uma prévia ao vivo do app que o agente de código está construindo

A AWS documentou, em 30 de outubro de 2026, como abrir no navegador o app que um agente de código constrói dentro do Bedrock AgentCore, com portas e assinatura SigV4 controlando quem acessa.

A AWS documentou, em 30 de outubro de 2026, como abrir no navegador o app que um agente de código constrói dentro do Bedrock AgentCore, com portas e assinatura SigV4 controlando quem acessa.

Quem revisa código gerado por agente conhece o ciclo: o agente escreve arquivos num sandbox, alguém copia o resultado para algum lugar que abre, e o feedback espera um deploy. Num post publicado no DEV Community, o autor neticslabs descreveu um jeito de cortar essa espera dentro do Amazon Bedrock AgentCore, resumindo um walkthrough que a própria AWS publicou no blog de machine learning em 30 de outubro de 2026.

O mecanismo central chama-se Session endpoint: uma URL autenticada que dá acesso direto a portas específicas dentro da microVM isolada onde a sessão do agente roda. Se você constrói, revisa ou orquestra agentes de código no trabalho, o detalhe que interessa não é a demo bonita, é o desenho de controle de acesso por trás dela.

O que você vai construir

Este tutorial monta um fluxo mínimo para abrir, no seu próprio navegador, a aplicação Vite que um agente está editando dentro de uma sessão do AgentCore runtime. Você vai liberar duas portas no runtime, subir um proxy local que assina cada requisição com SigV4, invocar o agente, capturar a URL da sessão e acompanhar o hot reload do Vite enquanto o agente salva arquivos.

O resultado prático é o mesmo que o post da AWS descreve: uma página abre localmente, mostra o site mudando em tempo real, e qualquer tentativa de acessar uma porta fora da lista permitida volta com um erro explícito.

Pré-requisitos

• Uma conta AWS com acesso ao Amazon Bedrock AgentCore habilitado na região escolhida (o post não confirma disponibilidade em sa-east-1, então verifique na página de regiões do serviço antes de seguir).
• Permissão IAM mínima anexada à role que você vai usar: bedrock-agentcore:InvokeAgentRuntimeProxy, concedida tanto no runtime quanto no seu endpoint.
• AWS CLI v2 configurado com credenciais válidas (aws configure).
• Python 3.11 ou superior, com boto3, flask e requests instalados (pip install boto3 flask requests).
• Node.js 20 com um projeto Vite já criado (npm create vite@latest).
• Familiaridade básica com assinatura SigV4, porque o proxy local depende dela.

Passo a passo

1. Configure o app Vite para aceitar conexões externas. Dentro da sessão do agente, o servidor de desenvolvimento precisa escutar em 0.0.0.0, porque um processo escutando em localhost não responde ao proxy do Session endpoint.

// vite.config.js
export default {
  server: {
    host: "0.0.0.0",
    port: 8090,
  },
};

2. Crie o runtime com a lista de portas liberadas. allowedPorts aceita de uma a cinco entradas, cada uma uma porta única ou um intervalo entre 8000 e 12000. No exemplo da AWS, a porta 8090 serve o site e a 8081 serve uma rota de status do próprio agente; a porta 8080, usada pelo InvokeAgentRuntime direto, fica fora da lista de propósito.

import boto3

control = boto3.client("bedrock-agentcore-control")

response = control.create_agent_runtime(
    agentRuntimeName="coding-agent-preview",
    allowedPorts=[8090, 8081],
)
runtime_arn = response["agentRuntimeArn"]

3. Invoque o runtime e capture a URL da sessão. Ela chega no cabeçalho de resposta X-Amzn-Bedrock-AgentCore-Runtime-Session-Endpoint-Url, e os SDKs já expõem esse valor como sessionEndpointUrl.

runtime = boto3.client("bedrock-agentcore")

resp = runtime.invoke_agent_runtime(
    agentRuntimeArn=runtime_arn,
    payload=b'{"task": "build landing page"}',
)

session_url = resp["ResponseMetadata"]["HTTPHeaders"][
    "x-amzn-bedrock-agentcore-runtime-session-endpoint-url"
]
print(session_url)

4. Suba o proxy local que assina cada requisição. Um navegador não consegue adicionar um cabeçalho SigV4 sozinho, então a assinatura precisa acontecer em algo que você controla. É exatamente para isso que existe este passo.

from flask import Flask, request, Response
import requests
from botocore.auth import SigV4Auth
from botocore.awsrequest import AWSRequest
from botocore.session import Session

app = Flask(__name__)
SESSION_URL = session_url  # capturado no passo 3

@app.route("/", defaults={"path": ""})
@app.route("/<path:path>")
def proxy(path):
    target = f"{SESSION_URL}/{path}"
    aws_req = AWSRequest(method=request.method, url=target, data=request.get_data())
    SigV4Auth(Session().get_credentials(), "bedrock-agentcore", "us-east-1").add_auth(aws_req)
    forwarded = requests.request(
        method=request.method,
        url=target,
        headers=dict(aws_req.headers),
        data=request.get_data(),
    )
    return Response(forwarded.content, status=forwarded.status_code)

app.run(port=3000)

5. Abra localhost:3000 no navegador. A página carrega o site servido pela porta 8090 dentro da sessão, e o WebSocket de hot reload do Vite atravessa o mesmo proxy, então o site muda na tela conforme o agente salva arquivos, sem passo de deploy entre uma coisa e outra.

Testando

Duas chamadas simples confirmam que o controle de acesso está funcionando como o post descreve. A primeira testa uma porta fora da lista liberada:

curl -i https://9999--<session-id>.runtime.bedrock-agentcore.us-east-1.on.aws/

O retorno esperado é 403 AccessDenied, com o corpo vazio e o código do erro num cabeçalho de resposta, não no corpo. A segunda testa uma requisição sem assinatura válida, feita direto, sem passar pelo proxy que assina:

curl -i https://8090--<session-id>.runtime.bedrock-agentcore.us-east-1.on.aws/

Aqui o retorno pode ser 403 AccessDenied ou 401 AuthenticationRequired, dependendo de qual credencial faltou. Vale rodar esse teste de porta fora da lista toda vez que mudar o allowedPorts: é o teste de regressão mais barato de todo o fluxo.

Limpando os recursos

O runtime existe como uma microVM gerenciada, e mesmo sem um valor de preço divulgado, o cuidado de encerrar os recursos logo após o teste evita cobrança por tempo ocioso. Apague nesta ordem:

1. Encerre a sessão do agente, se o seu fluxo mantiver uma aberta além da chamada de invoke_agent_runtime.
2. Delete o runtime criado no passo 2:

control.delete_agent_runtime(agentRuntimeArn=runtime_arn)

1. Remova a policy IAM que você anexou só para este teste, em vez de deixá-la presa a uma role de uso geral.
2. Pare o processo Flask local (Ctrl+C) e revogue qualquer credencial temporária usada só para assinar as requisições.

Próximos passos

O ponto que fica claro depois de montar esse fluxo é que a URL de prévia é, antes de tudo, uma decisão de controle de acesso com uma lista de portas anexada. Três ajustes valem a pena antes de usar isso em qualquer coisa além de um teste:

• Dê um TTL explícito às sessões que carregam uma prévia, em vez de deixá-las abertas por padrão.
• Restrinja a permissão InvokeAgentRuntimeProxy ao ARN do runtime específico, não a um padrão amplo que cobre todos os runtimes da conta.
• Lembre que o Session endpoint só funciona com runtimes em microVM, responde por HTTPS público e não aceita conexão de entrada via AWS PrivateLink; times que dependiam de rede privada precisam rever essa premissa antes de levar o padrão para produção.

Equipes que rodam agentes na própria infraestrutura enfrentam uma decisão parecida, só que sobre quem guarda a credencial que o proxy confere: lá, o sandbox e a prévia ficam dentro de hardware que o próprio time já opera, o que muda quem controla essa fronteira. A documentação completa do recurso está no devguide do Bedrock AgentCore, e vale a leitura antes de soltar esse padrão fora de um ambiente de teste.

Fonte: DEV Community — #aws