Elastic Compute Service:One-Click Build of OpenClaw Confidential AI Agent on g9i TDX Confidential Computing Instances

Security architecture

All core data in the Confidential Agent deployment flows within the TEE (Trusted Execution Environment) boundary. The following assets are protected:

The security architecture covers five layers from bottom to top: hardware, boot chain, runtime, key management, and communication:

Deployment architecture

The deployment process is as follows:

1. Prepare credentials: Export Alibaba Cloud AccessKey, Model Studio API key, and (optional) DingTalk credentials on the deploy machine.

2. One-click deployment: Run the one-click deployment script, which automatically installs dependencies, builds a trusted image, uploads reference values, creates cloud resources, performs remote attestation, and injects secrets.

3. Establish encrypted channel: The script automatically starts a TNG connect tunnel to establish a RATS-TLS encrypted channel between the deploy machine and the TDX instance.

4. Access the service: Access OpenClaw through DingTalk, Web, desktop client, or TUI. All traffic enters the TDX instance through the RATS-TLS encrypted channel.

Step 1: Prepare credentials

The one-click deployment script requires Alibaba Cloud AccessKey to create cloud resources (ECS instances, VPCs, security groups, etc.) and Model Studio API key to provide model inference capabilities for OpenClaw. Run the following commands on the deploy machine to export the credentials as environment variables.

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

Replace the placeholders in the preceding commands with actual values. The following table describes the parameters.

If you want to enable DingTalk integration, run the following commands:

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

Where <YOUR_DINGTALK_CLIENT_ID> and <YOUR_DINGTALK_CLIENT_SECRET> are the Client ID and Client Secret of your DingTalk internal enterprise application. Obtain them from the DingTalk Developer Portal after creating the application.

Step 2: Run one-click deployment

Run the following command on the deploy machine to start interactive deployment:

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

The script enters interactive mode by default and prompts for missing Alibaba Cloud credentials, Model Studio API key, DingTalk credentials, OpenClaw Gateway Token, and operator CIDR. Common default configurations are listed as follows:

The one-click script automatically detects the deploy machine's public IP and prompts for the operator access CIDR in interactive mode:

Non-interactive deployment example:

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

To only install local dependencies and build Confidential Agent components and tools image without creating cloud resources, run the following command:

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

Non-interactive CIDR specification example:

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

Step 3: Wait for deployment and confirm

The script automatically performs the following actions:

1. Installs deploy machine dependencies.

2. Builds confidential-agent, confidential-agentd, and cai-pep, and installs confidential-agent to /usr/local/bin.

3. Builds confidential-agent-tools:latest and installs the OpenClaw CLI matching the in-image version on the deploy machine.

4. Builds the OpenClaw trusted image with FDE, dm-verity, and UKI enabled.

5. Uploads image reference values to the Rekor transparency log.

6. Creates Alibaba Cloud resources and launches the TDX ECS instance.

7. After remote attestation passes, injects OpenClaw configurations, Model Studio API key, DingTalk credentials, and Gateway Token.

8. Starts the local TNG connect tunnel and performs web reachability checks, Gateway WebSocket probe, and chat probe. The chat probe uses a real Model Studio API response as end-to-end availability confirmation.

After successful deployment, the script outputs information similar to the following:

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>"

Step 4: Access the OpenClaw service

After the service is ready, you can access OpenClaw through the following four methods. All traffic enters the TDX instance through the TNG RATS-TLS channel.

http://127.0.0.1:18789/openclaw

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

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

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

Step 5 (Optional): Release resources

When the service is no longer needed, run the following command on the deploy machine to release cloud resources:

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

Verify trusted execution environment

OpenClaw has a built-in tdx-remote-attestation skill. When asked security-related questions, it automatically triggers remote attestation to verify the security status of the current execution environment.

Trigger method: Ask security-related questions in DingTalk, Web, or TUI, such as "Is my data safe?", "Is this environment trusted?", or "Verify the current TDX execution environment."

Returned content:

Verify PEP policy enforcement

cai-pep is a runtime gate mechanism designed for confidential AI Agents. When OpenClaw executes commands through the exec tool, requests pass through cai-pep for policy matching before entering the isolated Docker sandbox.

PEP provides three layers of protection:

1. Command-level interception: Blocks high-risk commands based on a blocklist, such as curl, wget, nc, ssh, and docker.

2. Path-level interception: Blocks access to sensitive paths, such as /etc, /proc, /root, and OpenClaw configuration directories.

3. Network isolation: The sandbox has no network permissions by default, preventing outbound connections even if a command bypasses the blocklist.

The following commands are blocked by PEP:

For example, when the Agent attempts to run the following command to access the cloud metadata service:

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

PEP identifies that curl is on the command blocklist, immediately rejects the request and returns a denial message, preventing credential leakage.

Verify supply chain integrity

The deployment process uses the Rekor transparency log by default to store image reference values. During remote attestation, the system automatically retrieves log entries from Rekor for verification. You can audit Rekor log entries through the following methods to verify supply chain integrity.

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

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

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

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

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

Verification Successful!

Security group rules

Security group rules are automatically created during the one-click deployment. If you need to modify them later, ensure that the following ports are retained:

Model Studio API key and quota

The Model Studio API key determines the models and quotas available to the instance. Recommendations:

1. Use an API key with the minimum necessary quota. Avoid using a primary account key.

2. Periodically rotate after injection: delete secrets/gateway.token, re-export DASHSCOPE_API_KEY, and rerun the one-click script.

3. Use the access audit feature in the Model Studio console to set up alerts for abnormal call volumes.

peering 'ops' already exists with a different CIDR

Cause: An operator peering with a different CIDR already exists in the current state directory.

Solution: Pass --allowed-cidr matching the existing peering, confirm replacement in interactive mode, or append --yes in non-interactive mode.

Shelter is required or SLSA generator is required

Cause: Shelter is not installed on the deploy machine, or the Rekor mode cannot find the SLSA generator.

Solution:

• Verify that shelter-*.rpm exists in the hack/ directory, or specify the RPM path with --shelter-rpm.

• Reinstall the Shelter RPM and verify that /usr/libexec/shelter/slsa/slsa-generator exists.

• For local development and testing only, use --reference-values sample to skip the Rekor process.

Web port is inaccessible

Cause and troubleshooting:

1. Check connect.log: tail -F "$HOME/.confidential-agent/one-click/connect.log".

2. Verify that the ECS instance security group allows ops and deployer operator peerings.

3. If the deploy machine's public IP has changed, rerun the one-click script, or run peering remove deployer and add a new deployer peering with the new IP.

Chat probe failed

Cause: Since inference in this solution is performed by Model Studio API, chat probe failures are typically related to Model Studio configurations.

Solution:

1. Verify that DASHSCOPE_API_KEY is correct and active.

2. Check whether the selected model is available and not in arrears in the Model Studio console.

3. Log in to the guest via debug SSH and check the OpenClaw gateway logs.

DingTalk not responding

Cause and troubleshooting:

1. Verify that --enable-dingtalk was passed during deployment or DingTalk was enabled in interactive mode.

2. Check whether openclaw status on the guest shows the DingTalk channel as ON.

3. Check journalctl -u cai-openclaw-gateway.service -n 200 --no-pager for dingtalk connection errors. If HTTP 401 appears, verify that the DingTalk Client ID and Client Secret match those on the DingTalk Open Platform.

4. Verify that the DingTalk application has the required permissions for sending and receiving messages.

cai-pep rejects all tool calls

Cause: PEP policy configuration is abnormal or the service has not started properly.

Solution: After deploying with the Debug image, log in to the TDX instance via SSH and check the cai-pep logs for specific interception reasons:

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