ソリューション概要: AI 検知からエンフォースメントまで
このソリューション概要では、AI の可観測性と AI ガバナンスの間で「ループを閉じる」方法を説明します。 Attribute™ は、ほぼリアルタイムの AI 可観測性とアトリビューションを提供し、すべてのトークン・推論・トレーニング実行を、それを発生させた API キー・ワークロード・顧客までトレースします。Attribute が重要な事象 (暴走する API キー、監視されずトークンを消費し続けるエージェント、予算超過) を検知すると、この CloudFlow をウェブフック経由で呼び出します。 フローはリクエストを検証し、重複を除外し、人による承認を取得したうえで、問題のある API キーを該当プロバイダーに対して失効させます。
課題
AI 採用が進むと、組織内の長期利用クレデンシャルの数が増加します。OpenAI の管理者およびプロジェクトキー、Anthropic の組織キー、Amazon Bedrock の長期クレデンシャル、Gemini の API キーなどです。それぞれが実際の支出とリスクを生み出します。キーの漏えい、リトライループで誤設定されたエージェント、あるいは静かに予算を超過していくワークロードなどが、誰かがダッシュボードを見る前に数千ドルを消費してしまう可能性があります。
Attribute はこの課題の「可視性」の半分を解決します。実行時に人間と非人間のトラフィックを分離し、消費されたトークンをすべて、そのトークンを使用した API キーとワークロードにアロケーションし、トークンスパイク、暴走エージェント、予算超過といったアノマリーをほぼリアルタイムで検知します。
しかし、検知だけでは「燃焼」を止めることはできません。Attribute のアラートに手作業で対応するには、該当プロバイダーの管理コンソールを探し出し、4 つの異なるプロバイダー API 用の常設クレデンシャルを保持し、当番のエンジニアがランブックに従ってくれることを期待する必要があります。承認ステップが入ることはほとんどなく、誰が・いつ・どのキーを・なぜ失効させたのかを示す一貫した監査証跡が残ることもほとんど ありません。アラート発報からキー失効までの 1 分ごとに、お金とリスクが増え続けます。
ソリューション
Attribute の検知機能と CloudFlow のエンフォースメントエンドポイントを組み合わせます。Attribute が停止すべき API キーを特定すると、そのキーの識別情報と理由を含めてフローのウェブフックを呼び出し、その後の処理はフロー側で行います。
1 つのリクエスト契約で 4 つのプロバイダーに対応。 呼び出し元は、プロバイダーに依存しない JSON ペイロードで、失効させるキーを記述します。フローがそれを正しい OpenAI、Anthropic、AWS、Google Cloud の API 呼び出しに変換するため、呼び出し側システムはプロバイダーのクレデンシャルやプロバイダー固有の API を扱う必要がありません。
アクション前のバリデーション。 すべてのリクエストは、サポートされるプロバイダー、キー種別、プロバイダー固有のスコープ要件など、厳格なスキーマに基づいて検証されます。形式不正またはサポート外のリクエストは、何も実行される前に即座に失敗します。
設計上の冪等性。 リクエストには呼び出し元で生成されたリクエスト ID が付与され、台帳に記録されます。リトライや重複配送が発生しても、同じキーが 2 回失効されることはありません。
すべての失効前に人による承認。 指定された承認者がメールからリクエストを確認するまで、キーには一切手を触れません。メールには、プロバイダー、キー ID、Attribute が提示した理由、アノマリーの参照情報といった完全なコンテキストが含まれます。
組み込みの監査証跡。 実行・拒否・重複・失敗を含むすべてのリクエストが、各ステップの出力およびトリガーとなった Attribute の参照情報とともに 実行履歴 に記録されます。
ウェブフック契約自体はシステムに依存しないため、同じエンドポイントを、シークレットスキャナー、SIEM の相関ルール、自前のガバナンスサービスなど、他の検知ソースにも利用できます。
このフローは、Webhook trigger、Code、Datastore、Branch、Switch ノードと、承認ゲート付きの OpenAI、Anthropic、AWS、Google Cloud アクションを組み合わせて構成されています。
このフローは、あらかじめ構築されたテンプレートとして提供されています。CloudFlow テンプレートライブラリで Revoke AI provider API keys via webhook を検索して選択し、ドラフトフローを作成するか、テンプレートへの直接リンクを利用してください。その後、組み込みのセットアップ手順に従って、5 つのフローバリアブル (4 つのプロバイダー接続と承認者メールアドレス) を設定し、リクエスト台帳となるテーブルを作成・選択し、公開してください。
作り方
最も手早い方法はテンプレートを使うことです。テンプレートの README に、セットアップ手順がすべて記載されています。このセクションでは、テンプレートを利用する場合でも、自分でゼロから構築する場合でも、フローが何で構成されているかを説明します。
開始前に、次の準備が必要です。
-
OpenAI と Anthropic の Admin API コネクションに加え、管理対象のアカウントおよびプロジェクトでキー削除を許可する AWS と Google Cloud の権限。付与する権限はキー失効に必要な最小限にしてください。
-
リクエスト台帳として機能する Datastore テーブルと、一意な
requestKey列。 -
承認者のメールアドレス、および呼び出し元システム (Attribute もしくはその他の検知ソース) 向けの DoiT API キー。ウェブフック URL と API キーはシークレットとして扱ってください。
フローは次の 4 つのステージで構成されています。
-
受信と検証: Webhook trigger が JSON リクエストを受け取り、Code node がリクエスト契約を強制します (詳細は後述の 仕組み を参照してください)。不正なリクエストでは、実行がわかりやすいエラーメッセージとともに失敗し、その後段は一切実行されません。有効なリクエストは、
openai.project.revokeのようなルーティングキーに正規化されます。 -
重複排除: Datastore node が台帳テーブルでリクエスト ID を検索し、Branch node が新規リクエストと再送リクエストを分岐させます。新規リクエストは台帳上で「確保」され、再送リクエストはプロバイダー側で何もアクションを行わずに実行を終了します。
-
プロバイダー別ルーティング: Switch node がルーティングキーを、プロバイダールートごとのケースと突き合わせます。
openai.admin.revoke、openai.project.revoke、anthropic.organization.revoke、bedrock.bedrockLongTerm.revoke、gemini.gcpApiKey.revokeなどです。1 つのリクエストにつき、必ず 1 つのケースパスだけが有効になります。Default パスがないため、どのケースにも一致しないリクエストは、副作用を伴わずに実行を終了します。
-
承認と実行: 各ケースパスの最後 には、キーを失効させるプロバイダーアクションが置かれます。例えば、OpenAI の
admin-api-keys-deleteアクションや、AWS IAM のDeleteServiceSpecificCredentialアクションなどです。各アクションで Require approval for this action を有効にし、承認者を設定し、承認メッセージ内でリクエストのプロバイダー・キー ID・理由・ソース参照を参照してください。また、放置されたリクエストが自動的に拒否されるよう、承認期限を設定してください。
Attribute やその他の本番システムに接続する前に、すべてのプロバイダールートについて、使い捨ての API キーを使ってテストしてください。フローを公開すると、すぐにエンフォースメントが有効になります。
Switch node のページでは、このプロバイダー別ルーティングパターンを実例として利用しています。
仕組み
Attribute がアノマリーを検出すると、それを特定の API キーにアトリビュートし、フローのトリガーノードに表示されている Webhook URL に JSON ペイロードを送信してフローをトリガーし、DoiT API キーで認証します。
curl -X POST "<webhook-url>" \
-H "Authorization: Bearer $DOIT_API_KEY" \
-H "Content-Type: application/json" \
-d @request.json
このペイロードは、失効させる 1 つのキーを表します。
{
"schemaVersion": "1.0",
"requestId": "attribute-anomaly-4711",
"provider": "openai",
"entity": {
"type": "apiKey",
"id": "key_abc123",
"kind": "project",
"scope": {
"projectId": "proj_abc123",
"accountId": "",
"userName": ""
}
},
"action": "revoke",
"reason": "Runaway token consumption: key exceeded its daily budget by 12x",
"sourceReference": "Attribute anomaly 4711"
}
-
schemaVersion:1.0である必要があります。 -
requestId（オプション）: 重複排除のために呼び出し元が生成する識別子です（例: Attribute のアノマリー ID）。すでに処理済みのrequestIdを持つリクエストは、プロバイダー側のアクションを一切行わずに終了するため、同じアノマリーが繰り返し発火してもキーが 2 回失効することはありません。requestIdのないリクエストは、配信のたびに実行されます。 -
providerとentity.kind: 組み合わせてプロバイダールートを選択します。サポートされている組み合わせは次のとおりです。providerentity.kind失効対象 openaiadminOpenAI の管理者 API キー openaiprojectOpenAI のプロジェクト API キー（ entity.scope.projectIdが必須）anthropicorganizationAnthropic の組織 API キー bedrockbedrockLongTermBedrock の長期クレデンシャル（ entity.scope.accountIdは 12 桁の AWS アカウント ID である必要があり、entity.scope.userNameが必須）geminigcpApiKeyGemini API キー（ entity.idはprojects/<project>/locations/global/keys/<key>という完全なリソース名である必要があります） -
entity.id: 失効対象のキーに対するプロバイダー側の識別子です。 -
action:revokeである必要があります。フローは、意味がよく理解された 1 つの動詞のみを意図的にサポートしています。より広い語彙（suspend・disable・delete など）は、プロバイダー固有のセマンティクスに対応しており、それぞれ専用の明示的なルートを設けるのが適切です。 -
reasonとsourceReference（オプション）: 承認メールおよび監査ログに表示される自由記述のコンテキストです。Attribute はここにアノマリーの説明とその参照を設定するため、承認者はそのキーがフラグ付けされた理由を正確に確認できます。
エンドポイントは、run history 内の実行へのリンクをすぐに返し、その結果がそこに記録されます。
| リクエスト | 結果 |
|---|---|
有効で、新しい requestId | 実行は承認ステップで一時停止し、承認後にキーが失効 |
処理済み requestId のリプレイ | プロバイダー側のアクションを行わずに実行完了 |
| 承認が却下または期限切れ | プロバイダー側のアクションを行わずに実行完了 |
| サポートされていない provider・kind・action | 説明的なエラーとともにバリデーションで失敗し、何も実行されない |
CloudFlow は、フローごとに常に 1 つの実行のみを行う点に注意してください。リクエストが承認待ちの間は、同じフローへの新しい Webhook 配信は 409 Conflict レスポンスで拒否され、呼び出し元は後で再試行する必要があります。頻繁なリクエストが想定される場合は、承認の有効期限を短く設定してください。
エンドツーエンドでの確認
このパターンは、検出側がすでに用意されている場合に最も有用です。Attribute™ が、このフローをトリガーするアノマリー（トークン急増・暴走エージェント・キー単位の支出のワークロードへのアトリビューションなど）をどのように可視化し、それを自身の環境向けに CloudFlow とどのように連携させるかを確認したい場合は、デモの予約を行ってください。