Turnkey、AIエージェントの認証情報アクセス向けにManaged Secretsを提供開始

TurnkeyはManaged Secretsを提供開始し、エンクレーブを基盤とするウォレットインフラを、アプリケーションやAIエージェントの稼働に必要なAPIキー、パスワード、決済情報、復旧用情報にまで拡張した。10月29日の発表により、同社は秘密鍵の管理を超え、ソフトウェアが再利用可能な認証情報をインフラ内のあちこちに分散させることなく行動できる権限を与えるという、より広範な課題に取り組む。

この製品では、チームが認証情報を取得できるサービスと、その要求に人間または複数当事者による承認を必要とするかどうかを決められる。金融アプリケーションであれば、認証済みの取引バックエンドに取引所のAPIキーを渡しつつ、AIアシスタントの会話や実行環境にはそのキーを渡さない、といった運用が可能になる。

エンクレーブの境界内で認証情報へのアクセスを管理

環境変数や設定ファイルに保存された認証情報は、ソフトウェアが利用するうえでは便利だが、それらを読み取るプロセスが侵害されると、内容が漏えいするおそれがある。保管庫を使えば保存場所とアクセス制御を一元化できるが、認証情報がどこで読み取り可能になり、その時点でどのシステムを信頼しなければならないかという問題は残る。

Managed Secretsでは、認可の確認をTurnkeyのセキュアエンクレーブ内で行う。クライアントはシークレットをインポートする前に暗号化し、エンクレーブは保存用に再暗号化する。要求を受け取ると、エンクレーブは関連するポリシーと承認を評価したうえで、結果を指定された受信者の鍵に向けて暗号化する。要求元と受信者は別々のサービスでもよい。

この分離は重要だ。アプリケーションは、処理の開始や承認の取得を担いながら、その処理を完了するために使われる認証情報を復号する能力を持たずに済む。承認者の署名は情報の開示を許可するものであり、開示されたシークレットへのアクセス権を自動的に与えるものではない。

インポートとエクスポートを支える暗号技術

Turnkeyのセキュアチャネルに関するドキュメントでは、ハイブリッド公開鍵暗号（HPKE）に基づくプロトコルが説明されている。この方式は、公開鍵による鍵共有と認証付き暗号化を組み合わせ、機密情報を中継システム経由で暗号文として送信できるようにする。インポート時にはクライアントがエンクレーブ署名付きの鍵情報を検証し、エクスポート時には署名付き要求に含まれる公開鍵を使って暗号化する。

受信者の鍵は使い捨てを前提としている。Turnkeyは、このルールを守る責任はクライアント側にあると説明している。プロトコルでは、不具合のあるクライアントが宛先鍵を再利用するのを防げない。そのため、エンクレーブに加え、クライアントの実装もセキュリティモデルの一部となる。

Managed Secretsの製品ページには、保存中の各シークレットをAES-256-GCMで暗号化すると記載されている。APIは、個別の認証情報にも複数のシークレットをまとめて要求する場合にも対応する。要求されたシークレットのうち1つでも認可されていなければ、バッチエクスポート全体が失敗するため、一部しか承認されていない一式が開示されることはない。

受信者が依然として重要である理由

「エージェントは認証情報を見ずに利用できる」という表現は、連携のパターンを示すものであり、受信側のすべてのプロセスが平文を読み取れない状態に保たれるという保証ではない。Turnkeyの開発者向けドキュメントには、平文がエンクレーブ内と、シークレットをインポートまたはエクスポートするクライアント上に存在し得ることが明記されている。

別個の実行サービスが受信者の鍵を保持していれば、認証情報を復号して利用しながら、その情報をモデルから隔離できる。エージェント自身のランタイムがその鍵を保持している場合は、そのランタイムが認証情報を復号できる。したがって、受信者だけでなく、そのメモリやログも保護する必要がある。

もう一つの境界がある。ポリシーは、申告された決済ドメインなど、要求のコンテキストを確認できるが、その申告が真実かどうかをTurnkeyが独立して検証するわけではない。署名付きの申告によって、誰がその内容を主張したかは確認できる。それでもアプリケーション側では、その主張と実際の操作を結び付ける信頼性の高い確認が必要だ。

ワークフローに合わせて変更できる承認

チームは、取得を直接許可する、人による要求の承認を必須にする、または複数のエージェント役割間の合意を必須にするといった設定ができる。基盤となるシークレットを再インポートせずにポリシーを変更できるため、厳重な監督のもとでワークフローを開始し、後から選択した要求を自動化することも可能だ。

Turnkeyのプログラム可能なアクセスに関するガイドでは、ブラウザーエージェントと決済エージェントが要求に共同署名する例が紹介されている。復号可能なカード情報を受け取るのは決済エージェントだけだ。承認の前に、ブラウザー側のコンポーネントは、提示されたドメインが利用中のページのドメインと一致するかを確認する。この例は、承認の数を単に数えるより、役割を独立させて検証することが重要である理由を示している。

エージェントの役割には、権限を限定した有効期限付きのセッション認証情報を使うことができ、運用者は実行中のインスタンスを個別に失効させられる。ただし、今後のアクセスを失効させても、受信者がすでに復号したシークレットを消去することはできない。下流での認証情報のローテーションは、別途必要な運用上の対策となる。

ウォレットインフラから金融業務の自動化へ

Turnkeyが既に採用しているセキュリティアーキテクチャでは、AWS Nitro Enclavesを使用し、ハードウェアによる隔離と再現可能なビルド、リモートアテステーションを組み合わせている。再現可能なビルドによりソフトウェアのビルドを比較できる一方、アテステーションはエンクレーブ内で実行されているコードに関する証拠を提供する。Managed Secretsは、この基盤をブロックチェーンの署名鍵以外の認証情報にも適用する。

同社は、取引会社、フィンテックのバックエンド、AIエージェントの開発者、MPCカストディアンを想定ユーザーとして挙げている。取引所の認証情報とOAuthトークンは継続的なサービス利用を支え、キーシェアのバックアップと復旧キーはレジリエンスに対応する。これらは、同じストレージ基盤を共有する場合でも、承認要件と受領者要件が異なる、それぞれ別個の用途だ。

フィンテックチームにとって重要なのは、アクションの要求、アクセスの承認、利用可能な認証情報の受け取りを、より明確に分けられることだ。Managed Secretsは、その分離を実現するためのインフラを提供する。そこから得られる保護の有効性は、適用範囲を絞ったポリシー、信頼できる承認者、そして最終的にシークレットを使用するサービスが十分に保護されているかどうかに左右される。