匿名認証情報：プライバシーを侵害することなく、ボットとエージェントをレート制限する

このコンテンツは自動機械翻訳サービスによる翻訳版であり、皆さまの便宜のために提供しています。原本の英語版と異なる誤り、省略、解釈の微妙な違いが含まれる場合があります。ご不明な点がある場合は、英語版原本をご確認ください。

私たちのインターネットとの関わり方は、変化しているものです。少し前までは、ピザを注文することは、Webサイトを訪問し、メニューをクリックし、支払い情報を入力することを意味していました。近いうちに、自分の好みに合ったピザを注文するよう携帯電話に頼むかもしれません。デバイス上またはリモートサーバー上のプログラム（AIエージェントと呼びます）が、Webサイトを訪問し、お客様に代わって必要なステップを調整します。

もちろん、エージェントはピザを注文する以上のことができます。すぐに、コンサートのチケットの購入や休暇の計画、あるいはプルリクエストの書き込み、レビュー、統合に使用することもできるかもしれません。これらのタスクの一部は最終的にローカルで実行されますが、現在のほとんどは世界最大のデータセンターで稼働する大規模なAIモデルによって支えられています。エージェンティックAIの人気が高まるにつれて、これらのAIプラットフォームからのトラフィックが大幅に増加し、それに対応して、より従来のソース（携帯電話など）からのトラフィックは減少することが予想されます。

このトラフィックパターンの変化から、AI時代においてお客様のオンライン状態と安全性を維持する方法を評価する必要に迫られました。一方で、リクエストの性質は変化しています。人間の訪問者に最適化されたWebサイトは、より速く、潜在的には貪欲なエージェントに対処しなければなりません。一方で、AIプラットフォームは、プラットフォーム自体の悪意のあるユーザーを発信源とする、すぐに大きな攻撃源になる可能性があります。

残念ながら、そのような（誤った）動作を管理する既存のツールでは、この移行を管理するには、きめ細やかすぎる可能性があります。たとえば、リクエストが既知の攻撃パターンの一部であることをCloudflareが検出した場合、最良のアクションは多くの場合、同じソースから後続のすべてのリクエストをブロックすることです。ソースがAIエージェントプラットフォームである場合、これは同じプラットフォームのすべてのユーザーを不注意にブロックする可能性があります。ブロックされるのは、ピザを注文しようとする稼働率の高いユーザーも含めたものです。今年の初めから、この問題に取り組み始めました。しかし、エージェンティックAIの人気が高まるにつれて、インターネットには、正直なユーザーに影響を与えることなくエージェントを管理するための、よりきめ細かなメカニズムが必要になると考えています。

同時に、私たちは、こうしたセキュリティメカニズムは、ユーザーのプライバシーを中心に考えて設計される必要があると考えています。この記事では、これらのツールを構築するために匿名認証情報（AC）を使用する方法について説明します。匿名認証情報は、Webサイト運営者が、ユーザーを特定したり、リクエストごとに追跡したりすることなく、ユーザーのレート制限や特定の悪意のあるユーザーのブロックなど、幅広いセキュリティポリシーを適用するのに役立ちます。

Webサイト、ブラウザ、プラットフォームで機能する標準の提供を目的に、IETFは現在、匿名認証情報を開発中です。まだ初期段階ではありますが、この取り組みはAI時代のインターネットの安全性とプライベート性を保つ上で重要な役割を果たすと信じています。当社は、実際のデプロイメントに向けて、このプロセスに貢献していきます。これはまだ初期段階です。この分野で活動する方は、ぜひフォローしていただき、貢献していただければと思います。

AIエージェントがWebサーバーにどのように影響しているかを説明するために、自分自身でエージェントを構築してみましょう。私たちの目標は、近くのピザ屋からピザを注文できるエージェントを持つことです。エージェントがいない場合、ブラウザを開き、近くにあるピザ屋の場所を確認し、メニューを表示して選択し、余分なエクスペリエンス（ダブルペパロニ）を追加し、クレジットカードで精算することでしょう。エージェントを使用する場合も同じフローです。ただし、エージェントはお客様に代わってブラウザを開いて調整します。

従来のフローでは、その途中がすべて人間で、各ステップには明確な意図があります。「現在の場所から3Km以内にあるすべてのピザ屋をリストアップする」ということです。メニューからピザを選びますクレジットカードを入力し、などです一方、エージェントは「ピザを注文する」というプロンプトから、これらのアクションを推測する必要があります。

このセクションでは、プロンプトを受けて、送信リクエストを行う簡単なプログラムを構築します。これは、特定のプロンプトを取得し、それに応じて回答を生成する単純なWorkerの例です。このコードはGitHubにあります。

export default {
   async fetch(request: Request, env: Env, ctx: ExecutionContext): Promise<Response> {
       const out = await env.AI.run("@cf/meta/llama-3.1-8b-instruct-fp8", {
           prompt: `I'd like to order a pepperoni pizza with extra cheese.
                    Please deliver it to Cloudflare Austin office.
                    Price should not be more than $20.`,
       });


       return new Response(out.response);
   },
} satisfies ExportedHandler<Env>;

この文脈では、LLMが最善の答えを提供してくれます。プランと指示は与えられますが、私たちの代わりにアクションを実行するものではありません。あなたも私も、指示のリストを受け取り、実行することができます。なぜなら、私たちは手段を持ち、世界に影響を与えることができるからです。当社のエージェントが世界のより多くの地域と対話できるように、Webブラウザ上で制御できるようにします。

Cloudflareは、Workerに直接バインドできるブラウザレンダリングサービスを提供しています。そうしましょう。以下のコードは、ブラウザの制御を簡単にする自動化フレームワークであるStagehandを使用しています。Cloudflareリモートブラウザのインスタンスと、Workers AIのクライアントを渡します。

import { Stagehand } from "@browserbasehq/stagehand";
import { endpointURLString } from "@cloudflare/playwright";
import { WorkersAIClient } from "./workersAIClient"; // wrapper to convert cloudflare AI


export default {
   async fetch(request: Request, env: Env, ctx: ExecutionContext): Promise<Response> {
       const stagehand = new Stagehand({
           env: "LOCAL",
           localBrowserLaunchOptions: { cdpUrl: endpointURLString(env.BROWSER) },
           llmClient: new WorkersAIClient(env.AI),
           verbose: 1,
       });
       await stagehand.init();


       const page = stagehand.page;
       await page.goto("https://mini-ai-agent.cloudflareresearch.com/llm");


       const { extraction } = await page.extract("what are the pizza available on the menu?");
       return new Response(extraction);
   },
} satisfies ExportedHandler<Env>;

そのコードは、https://mini-ai-agent.cloudflareresearch.com/llmでアクセスできます。2025年10月10日の回答がこちらです。

Margherita Classic: $12.99
Pepperoni Supreme: $14.99
Veggie Garden: $13.99
Meat Lovers: $16.99
Hawaiian Paradise: $15.49

ブラウザレンダリングのスクリーンショットAPIを使用して、エージェントが行っていることを検査することもできます。上記の例でブラウザがページをレンダリングする方法を次に示します。

Stagehandを使用すると、page.act（「ペパロニピザをクリックしてください」）やpage.act（「今すぐ支払う」をクリックしてください）など、ページ上のコンポーネントを識別できます。これにより、開発者とブラウザ間のインタラクションが容易になります。

さらに前進して、エージェントにフロー全体を自律的に実行するように指示するには、Stagehandのエージェントモードを使用する必要があります。この機能は、Cloudflare Workersではまだサポートされていませんが、完全性を示すために以下に提供します。

import { Stagehand } from "@browserbasehq/stagehand";
import { endpointURLString } from "@cloudflare/playwright";
import { WorkersAIClient } from "./workersAIClient";


export default {
   async fetch(request: Request, env: Env, ctx: ExecutionContext): Promise<Response> {
       const stagehand = new Stagehand({
           env: "LOCAL",
           localBrowserLaunchOptions: { cdpUrl: endpointURLString(env.BROWSER) },
           llmClient: new WorkersAIClient(env.AI),
           verbose: 1,
       });
       await stagehand.init();
       
       const agent = stagehand.agent();
       const result = await agent.execute(`I'd like to order a pepperoni pizza with extra cheese.
                                           Please deliver it to Cloudflare Austin office.
                                           Price should not be more than $20.`);


       return new Response(result.message);
   },
} satisfies ExportedHandler<Env>;

エージェントは段階的な指示を加えるのではなく、制御できるようになっていることがわかります。実際に支払うには、バーチャルクレジットカードなどの支払方法にアクセスする必要があります。

プロンプトには、場所の範囲をCloudflareのオースティンのオフィスに限定した、いくつかの微妙な違いがありました。これは、エージェントが私たちに応答する一方で、私たちのコンテキストを理解する必要があるためです。この場合、エージェントはCloudflareのエッジ（当社から離れた場所）で動作します。これは、このデータセンターからピザが配達されたとしても、受け取る可能性が低いことを意味します。

エージェントに提供する機能が多ければ多いほど、混乱を引き起こす可能性があります。誰かが10秒に1リクエスト、低速で5回クリックする代わりに、データセンターでプログラムが実行されていて、おそらく1秒間に5つのリクエストすべてを作成することができるのです。

このエージェントはシンプルですが、何千ものもの（一部は良性のものもあれば、そうでないもの）がデータセンターのスピードで稼働していることを想像してみてください。オリジンサーバーが直面する課題は次の通りです。

人間がオンライン世界と対話するためには、Webブラウザと、そのブラウザの動作を指示するための周辺機器が必要です。エージェントはブラウザを誘導する別の方法であるため、オリジンの観点から見れば、実際にはほとんど変更されていないと考えがちです。実際、オリジンの観点から最も明らかな変化は、単にトラフィックがどこから発生しているかです。

この変化が重大な理由は、サーバーがトラフィックを管理するためのツールに関係しています。一般的に、Webサイトは、可能な限り寛容であるように努めますが、限られたリソース（帯域幅、CPU、メモリ、ストレージなど）を管理する必要もあります。これを行う基本的な方法はいくつかあります。

1. グローバルセキュリティポリシー：サーバーは、速度を低下させる、CAPTCHA、または一時的にすべてのユーザーからのリクエストをブロックすることができます。このポリシーは、サイト全体、特定のリソース、または既知またはその可能性の高い攻撃パターンの一部であると分類されたリクエストに適用されます。こうしたメカニズムは、DDoS攻撃のようにトラフィックの急増に対応してデプロイされることもあれば、Waiting Roomのように正当なトラフィックの急増を予期してデプロイされることもあります。

2. インセンティブ: サーバーは、より多くのリソースが利用可能になった時に、ユーザーにサイトを利用してもらうよう誘導することがあります。例えば、場所やリクエスト時間によって、サーバー価格がより低くなることもあります。これは、Cloudflare Snippetで実装できます。

どちらのツールも効果的ですが、重大な巻き添え被害をもたらすこともあります。例えば、Webサイトのログインエンドポイントをレート制限することは、クレデンシャルスタッフィング攻撃の防止に役立ちますが、攻撃者以外のユーザーエクスペリエンスも低下させます。このような対策に頼る前に、サーバーはまずセキュリティポリシー（レート制限、CAPTCHA、完全ブロックを問わず）を個々のユーザーまたはユーザーグループに対して適用しようとします。

ただし、セキュリティポリシーを個人に適用するには、サーバーは個人を識別する何らかの方法を必要とします。これまで、これは、IPアドレス、User-Agent、ユーザーIDに紐付けられたアカウント（利用可能な場合）、その他の指紋を組み合わせることで行われていました。ほとんどのクラウドサービスプロバイダーと同様に、Cloudflareは、このようなヒューリスティックに基づいてユーザーごとのレート制限に対する専用のサービスを提供しています。

フィンガープリンティングはほとんどの場合有効です。しかし、その分布は不公平です。モバイルでは、ユーザーはCAPTCHAを解決するのに特に苦労しており、VPNを使用するとブロックされる可能性が高く、読み取りモードを使用するとフィンガープリントが崩れてページのレンダリングを妨げる可能性があります。

同様に、エージェンティックAIはフィンガープリンティングの限界をさらに悪化させるだけです。より小さいソースIP範囲にトラフィックが集中するだけでなく、エージェント自体も同じソフトウェアおよびハードウェアプラットフォームを実行するため、正当なユーザーと悪意のあるユーザーを区別することが難しくなります。

そこで役立つのがWebボット認証で、エージェントがどのプラットフォームで操作しているかをオリジンに識別できるようになるものです。しかし、プラットフォーム自体を特定するためのこのメカニズムを、プラットフォームの個々のユーザーを特定する目的に拡大することは、これらのユーザーにとって許容できないプライバシーリスクを生むため、避けたいと考えます。

個々のユーザーを特定することなく、個々のユーザーに対するセキュリティ制御を実装する何らかの方法が必要です。でも、どうやって？プライバシーパスプロトコルは、部分的なソリューションを提供します。

現在、プライバシーパスの最も顕著なユースケースの1つは、以前にも 説明したように 、ユーザーからオリジンへのリクエストを レート制限する ことです。プロトコルは大まかに次のように機能します。クライアントには、複数のトークンが発行されます。リクエストを行うたびに、オリジンにトークンを1つ引き換えます。トークンが新しい場合（つまり、オリジンがこれまでに観測したことがない場合）のみ、オリジンはリクエストの通過を許可します。

プライバシーパスをユーザーごとのレート制限に使うには、各ユーザーに発行されるトークン数を制限する必要があります（例：ユーザー1人あたり100トークン/時間制限など）。AIエージェントのレート制限には、AIプラットフォームがこの役割を果たします。トークンを取得するには、ユーザーはプラットフォームにログインし、このプラットフォームは、ユーザーが発行者からトークンを取得できるようにします。AIプラットフォームは、プライバシーパスにおけるアテスターの役割を果たします。アテスターは、レート制限のユーザーごとのプロパティを保証する側です。AIプラットフォームは、アテスターとして、その評判を脅かすことから、このトークン配布を実施するインセンティブがあります。もし、過剰なトークンの発行を許可すれば、発行者はそれを信用しない可能性があります。

発行プロトコルと請戻プロトコルは、次の2つのプロパティを持つように設計されています：

• トークンは偽造不可能です。発行者だけが有効なトークンを発行できます。

• トークンはリンク解除可能です。発行者、アテスター、オリジンを含むどの関係者にも、トークンがどのユーザーに発行されたかを知ることはできません。

これらの特性は、ブラインド署名スキームと呼ばれる暗号化プリミティブを使って実現できます。従来の署名スキームでは、署名者はプライベートキーを使用してメッセージの署名を作成します。その後、検証者は署名者のパブリックキーを使用して署名を検証できます。ブラインド署名スキームも同じように機能しますが、署名されるメッセージは、署名者が署名しているメッセージを知ることができないように隠されています。クライアントは、署名されるメッセージを「ブラインド」してサーバーに送信します。そうすることで、サーバーはそのメッセージに対してブラインド署名を計算します。クライアントは、署名を解除することで最終的な署名を取得します。

これはまさに、RFC 9578で定義されている標準化されたプライバシーパス発行プロトコルです。

• 発行: ユーザーはランダムメッセージ $k$ を生成します。これを nullifier と呼びます。具体的には、これは単なるランダムな32バイトの文字列です。そして、ブラウジングをして発行者に送ります。発行者はブラインド署名で応答します。最後に、ユーザーは署名を解除して、 $\sigma$、 つまり $k$の署名を取得します。トークンは、 $(k, \sigma)$ のペアです。
• あらゆる企業両方の条件が満たされた場合は、リクエストを受け入れ、通過させます。

ブラインド署名はシンプルで安価で、多くのアプリケーションに最適です。ただし、これらにはいくつかの制限があり、当社のユースケースには適していません。

まず、発行プロトコルの通信コストが高すぎます。発行された各トークンに対して、ユーザーは256バイトのブラインドニューラルファイアを送信し、発行者は256バイトのブラインド署名（RSA-2048の使用を想定）で応答します。これは、1リクエストあたり0.5KBの追加通信量、つまり1,000件のリクエストごとに500KBの通信量が必要だということです。これは、以前のプライバシーパスの実験のように管理可能ですが、理想的ではありません。帯域幅が、適用したいレート制限のサブラインにあることが理想的です。計算時間が短いブラインド署名の代替として、Oblivious Pseudorandom Functions (VOPRF) がありますが、帯域幅は依然として漸近線形です。以前、プライバシーパスの初期導入の基盤となったため、過去に説明しました。

第二に、ブラインド署名は、オリジンごとのレート制限に使用できません。クライアントに$N$トークンを発行する際、クライアントはトークンの有効性を確認できる配信元サーバーであれば、最高でも$N$トークンで引き換えられるのが理想です。ただし、サーバーが同じトークンを同じクライアントにリンクさせることができるため、クライアントは複数のサーバーで同じトークンを安全に引き換えることはできません。ここで必要なのは、レイトオリジンバインディングと呼ばれる何らかのメカニズムが必要になるということです。つまり、特定のオリジンでの払い戻しのために、同じトークンの他の解読とリンクできない方法でトークンを変換するということです。

第三に、トークンが一度発行されると取り消すことはできません。発行者のパブリックキーが有効である限り、有効なままです。これにより、オリジンが攻撃を検出した場合、またはそのトークンが侵害された場合に、特定のユーザーをブロックすることが不可能になります。オリジンは、問題を起こすリクエストをブロックできますが、ユーザーは残りのトークンバジェットを使用してリクエストを続けることができます。

1985年にChaumが指摘したように、匿名認証情報システムにより、ユーザーは発行者から資格情報を取得し、後でリンクを確立しない方法で、追加情報を明らかにすることなく、この資格情報を所有していることを証明することができます。また、いくつかの属性が認証情報に付いていることを示すことも可能です。

匿名認証情報は、レイテンシー（発行後にトークンをオリジンにリンクする）、マルチ表示（単一の発行者からの応答から複数のトークンを生成する）、有効期限などの追加機能を備えたブラインド署名のようなものと考えることができます。暗号化キーローテーション（トークンの有効性は発行者暗号化キーの有効性から切り離す）とは異なります。プライバシーパスの引き換えフローでは、クライアントはブラインドされていないメッセージと署名をサーバーに提示します。請戻を受け入れるには、サーバーは署名を検証する必要があります。ACシステムでは、クライアントはメッセージの一部しか提示しません。サーバーが要求を受け入れるためには、クライアントはすべてを明らかにせずに、メッセージ全体の有効な署名を知っていることをサーバーに証明する必要があります。

そのため、前述のフローには、この追加のプレゼンテーションステップが含まれます。

なお、ブラインド署名やVOPRFを通じて生成されたトークンは1回しか使用できないため、使い捨てトークンと見なすことができます。しかし、トークンを複数回使用できるタイプの匿名認証情報が存在します。これを機能させるために、発行者はユーザーに資格情報を付与し、ユーザーは後に引き換えとして最高N個の使い捨てトークンを生成することができます。したがって、ユーザーは1回の発行セッションを犠牲にして、複数のリクエストを送信することができます。

以下の表は、ブラインド署名と匿名認証情報がレート制限にとって興味深い機能を提供する方法を示しています。

特徴	ブラインド署名	匿名認証情報
発行コスト	単純な複雑さ：10の署名発行は、1回の署名発行の10倍のコストがかかる	サブライン的な複雑度：10の属性に署名する方が、10の個別署名よりも安価である
証明機能	メッセージが署名されたことを証明するだけ	部分的なステートメント（属性）の効率的な証明が可能になる
状態管理	ステートレス	ステートフル
属性	属性なし	パブリック（例：有効期限）やプライベート状態

単純な匿名認証情報スキームの仕組みを見てみましょう。クライアントのメッセージは、 $(k, C)$ のペアで構成され、$k$ は ヌル文字で、 $C$ はクライアントがリソースにアクセスできる残り 回数を表すカウンターです。カウンターの値はサーバーによって制御されます。クライアントが認証情報を引き換えにすると、ニュールディアーとカウンターの両方が提示されます。レスポンスとして、サーバーはメッセージの署名が有効であり、ヌル攻撃者が以前と同じように新しいものであることをチェックします。さらに、サーバーは

1. カウンターがゼロより大きいことを確認する。かつ

2. 更新されたカウンターと新しいNullifierを発行するカウンターを減らします。

この機能を満たすために、ブラインド署名が使用されます。ただし、ヌこれは、カウンターの制御権を持つサーバーが、同じクライアントが使用する複数のプレゼンテーションをリンクするためにカウンターを利用できるため、明らかなプライバシーリスクを生み出します。たとえば、ペパロニピザを購入するために連絡を入れたとき、オリジンは特別なカウンター値を割り当てることができるため、二回目提示する際のフィンガープリンティングが容易になります。幸いなことに、この種のプライバシーのギャップを埋めるために設計された匿名の認証情報があります。

上記のスキームは、IETFの プライバシーパスワーキンググループ によって採用が検討されている匿名認証情報スキームの1つである匿名クレジットトークン（ ACT ）の簡易バージョンです。actの主な特徴は、その状態性です。正当化に成功すると、サーバーは更新されたニューリ攻撃者とカウンターの値を持つ新しい認証情報を再発行します。これにより、クライアントとサーバーの間にフィードバックループが作成され、さまざまなセキュリティポリシーを表現するために使用できます。

設計上、CT認証情報を複数回同時に提示することはできません。次のリクエストで再発行された認証情報を提示できるように、最初の提示が完了している必要があります。並列性は、プライバシーパスワーキンググループで議論中のもう1つのスキームである匿名レート制限クレデンシャル（ARC）の主要な機能です。ARCは、発行時に決定されるプレゼンテーション制限まで、複数のリクエストを並行して表示することができます。

ARCのもう1つの重要な機能は、レイテンシーバインディングのサポートです。クライアントがプレゼンテーション制限$N$でARCを発行された場合、クライアントは安全に、資格情報を使用して、資格情報を検証できるオリジンに最大$N$を提示できます。 .

これらは、一部の匿名認証情報の関連する機能の例にすぎません。一部のアプリケーションは、そのサブセットから恩恵を受けるかもしれません。また、追加機能が必要な場合もあります。幸いなことに、ACCとARCはどちらも小さな暗号プリミティブのセットから構築することができ、他の目的にも簡単に適応させることができます。

ARCとactは、共通の2つのプリミティブを共有しています。代数MACは、ブラインドメッセージに関する制限された計算を可能にします。メッセージのサーバーに公開されていない部分の有効性を証明するためのゼロ知識証明（ZKP）を使用します。それぞれについて詳しく見ていきましょう。

メッセージ認証コード（MAC）とは、メッセージの真正性（主張する送信者からのものであること）と完全性（メッセージが改ざんされていないこと）を確認するのに使用される暗号タグです。代数MACは、グループアクションのような数学的構造から構築されています。代数的構造は、それらにいくつかの追加機能を与えますが、その1つは、MACの実際の値を簡単に隠すことができる準同型です。代数的なMACにランダムな値を追加すると、値を見えなくします。

ブラインド署名とは異なり、ACTとARCは両方ともプライベートに検証可能です。つまり、イシュア―とオリジンの両方が発行者のプライベートキーを持っている必要があります。Cloudflareを例に挙げると、Cloudflareによって発行された認証情報は、Cloudflareの背後のオリジンによってのみ使用できることを意味します。両方の公的に検証可能な亜種は可能ですが、追加コストがかかります。

ゼロ知識証明（ZKP）によって、ステートメントが真となる正確な値を明らかにすることなく、ステートメントが真であることを証明することができます。ZKPは、証明者によって、実際に秘密を持つ人だけが生成できるように構築されます。そして、検証者はこの証明に対して簡単な数学的チェックを実行することができます。チェックに合格すれば、検証者は証明者の最初の声明が有効であると確信できます。重要なプロパティは、証明自体がステートメントを確認するデータに過ぎないことです。元の秘密を再構築するのに使用できる他の情報は含まれていません。

ARCとactでは、秘密の直線的関係を証明する必要があります。ARCでは、ユーザーは、異なるトークンが同じオリジナルのシークレット・クレデンシャルにリンクされていることを証明する必要があります。たとえば、ユーザーは、リクエストトークンが発行された有効な認証情報から派生したことを示す証明を作成できます。この証明により、トークンが正当に接続されていることが確認できます。トークンを結びつけている根本的な資格情報を学習することはありません。これにより、システムは、プライバシーを保護しながら、ユーザーの行動を検証することができます。

単純な線形関係の証明を拡張して、例えば数が範囲内にあることなど、強力なステートメントを証明できるようにすることができます。例えば、これは口座にプラスの残高があることを証明するのに役立ちます。残高がプラスであることを証明するには、残高をバイナリにエンコードできることを証明します。例えば、アカウントには最高1024クレジットがあるとします。例えば、12の場合、残高がゼロでないことを証明するには、2つのことを同時に証明します。1つ目は、バイナリビットのセット（この場合は12=(1100) 2）があること、2つ目は、リニアデータセンターであることです。これらのビット（8*1 + 4*1 + 2*0 + 1*0）を使った方程式は、正しくコミットされた残高の合計になります。これにより、検証者は、正確な値を知ることなく、その数字が有効に作られたものだと確信することができます。これは2の累乗の仕組みですが、任意の範囲に簡単に拡張することができます。

代数MACの数学的構造により、簡単に分かりやすく評価を行うことができます。この構造は、MACを明らかにすることなく、MACがプライベートキーを使用して評価されたことを簡単に証明することもできます。さらに、ARCはZKPを使用して、以前に投資されていないことを証明することができます。これに対して、ACTはZKPを使用して、トークンに十分な残高があることを証明します。残りはより多くのグループ構造を使用して準同型に引き出されます。

匿名認証情報は柔軟性が高く、特定のアプリケーションのブラインド署名と比較して通信コストを削減できる可能性があります。そのようなアプリを特定するには、これらの新しいプロトコルの具体的な通信コストを測定する必要があります。さらに、CPU使用率がブラインド署名や紛失擬似ランダム関数と比較した場合を理解する必要があります。

いくつかのACスキームの各段階で参加者が費やす時間を測定します。また、ネットワーク上で送信されるメッセージのサイズも報告しています。ARC、ACT、VOPRFでは、ristretto255を素数グループとして使用し、ハッシュにはSHAKE128を使用します。ブラインドRSAには、2048ビットモジュラスとSHA-384をハッシュに使用します。

各アルゴリズムはGoで、CIRCLライブラリ上に実装されています。ARCとactの仕様が安定し始めたら、コードをオープンソース化する予定です。

それでは、プライバシーパスで最も広く使われているデプロイメントであるブラインドRSAを見てみましょう。請戻時間は短く、コストのほとんどは発行時のサーバーにあります。通信コストはほぼ一定で、256バイト単位です。

VOPRFの場合、サーバーでの検証時間はブラインドRSAより若干高くなりますが、通信コストと発行ははるかに高速です。サーバー上の評価時間は、1つのトークンに対して10倍速く、つまり、償却トークン発行を使用した場合は25倍以上速くなっています。トークンあたりの通信費用も魅力的で、メッセージサイズは3分の1以上に抑えられています。

このため、VOPRFトークンは、やや高い払い戻しコストを受け入れられるが、公開された検証可能性を必要としない、多くのトークンを必要とするアプリケーションにとって魅力的です。

次に、ARCとactの匿名資格情報スキームの数字を見てみましょう。どちらのスキームについても、最高$N=1000$で提示できる認証情報の発行時間を測定しています。

期待通り、通信コストとサーバーのランタイムは、ブラインドRSAかVOPRFのバッチ発行よりもはるかに低くなります。例えば、1000個のトークンのVOPRF発行にかかる時間は99ミリ秒（トークンあたり99µs） vs 1000回のプレゼンテーションを可能にするARCクレデンシャル1つを発行する場合は1.35ミリ秒です。これは約70倍の高速化です。その代償として、クライアントとサーバーの両方にとって、プレゼンテーションはより高価なものになります。

行動を起こす人は？ ARCと同様に、発行されたクレジットに対して、発行の通信コストははるかに遅くなることが予想されます。当社の実装は、これを裏付けています。ただし、ARCとactには、興味深いパフォーマンスの違いがいくつかあります。発行はARCよりもはるかに安価ですが、請戻はその逆です。

現状その答えは、それぞれの段階でZKPを使用して証明する必要があることに大きく関係しています。例えば、アクティブな復元中、クライアントは、カウンター$C$が希望の範囲内にあることを（ゼロ知識で）証明します。つまり、$0 \leq C \leq N$です。証明サイズは $\log_{2} N$程度で、メッセージサイズが大きくなります。現在のバージョンでは、ARCの償還には範囲証明は含まれていませんが、将来のバージョンで範囲証明が追加される可能性があります。一方、ARCの発行時にクライアントとサーバーが証明する必要があるステートメントは、ARCのプレゼンテーションよりも少し複雑で、このことが実行時の違いを引き起こします。

匿名認証情報の利点は、前述のように、発行が一度で済むことです。サーバーがコストを評価する際、すべての発行コストとすべての検証コストを考慮します。現在、認証情報のコストのみを考慮すると、サーバーは匿名の認証情報の提示を検証するよりもトークンを発行し検証する方が安価です。

複数の匿名認証情報の利点は、発行者が$N$トークンを生成する代わりに、計算の大部分がクライアントにオフロードされることです。これは、より限定的です。レイテンシーバインディングにより、複数のオリジン/ネームスペースで動作することができ、キーローテーションからの有効期限を相互に示す範囲証明、および動的なレート制限を提供するための払い戻しが可能になります。現在のアプリケーションは、シングルユーストークンベースのスキームの限界によって、それらが提供する効率性よりも大きな影響を受けています。このギャップを埋めることが可能かどうかを確認するために、エキサイティングな分野のように思えます。

エージェントの管理には、ARCとCTの両方の機能が必要になるかもしれません。

ARCには、レート制限をサポートし、通信効率が高く、レイテンシーバインディングをサポートするなど、当社が必要とする機能の多くがすでに備えられています。主な欠点は、一度ARC認証情報が発行されると取り消すことができないことです。悪意のあるユーザーは、望むオリジンに対して常にN件のリクエストを行うことができます。

ARCとブラインド署名（またはVOPRF）を組み合わせることで、限定的な形式の取り消しを許可できます。ARC認証情報の提示には、プライバシーパス トークンが付属します。提示が成功すると、クライアントには、次のプレゼンテーション時に使用できる別のプライバシーパス トークンが発行されます。認証情報を失効させるために、サーバーはトークンを再発行しません。

このスキームは既にかなり有用です。ただし、これにはいくつかの重要な制限があります。

• オリジン間でのパラレルプレゼンテーションは不可能です。クライアントは、2番目のオリジンへのリクエストを開始する前に、1つのオリジンへのリクエストが成功するのを待たなければなりません。

• 取り消しは、オリジンごとではなくグローバルです。つまり、認証情報は提示されたオリジンだけでなく、提示可能なすべてのオリジンから取り消されます。これは、場合によっては望ましくないものではないかと思います。たとえば、リクエストがそのrobots.txtポリシーに違反した場合、オリジンは取り消したいと思うかもしれません。ただし、同じリクエストが他のオリジンで受理されている可能性もあります。

この設計のより基本的な制限は、取り消すという決定は単一のリクエスト、つまり、認証情報が提示されたリクエストに基づいてのみ行えるということです。1つのリクエストに基づいてユーザーをブロックすることは、危険な場合があります。実際には、攻撃パターンは多くのリクエストにわたってのみ生じる場合があります。CTのステート性は、少なくともこの種の防御の基本的な形態を可能にします。次のようなスキームを考えてみましょう。

• 発行: クライアントに、プレゼンテーション制限$N=1$でARCが発行されます。

• プレゼンテーション：

  • クライアントが初めてARC認証情報をオリジンに提示する時に、サーバーは有効な初期状態とともにCT認証情報を発行します。

  • クライアントが、有効なステート（例：クレジットカウンターが0より大きい）とともにCTを提示する場合、オリジンは次のいずれかを行います：

    • それにより、クレデンシャルが取り消されます。リクエストが攻撃の一部であるという高い確信が持てる場合にのみ、または、

    • リクエストを処理するために消費されたリソースの量だけACKクレジットを削減するために、状態が更新された新しいactを発行する。

良性のリクエストであれば、状態を大きく変更することはありませんが（仮にいたとしても）、疑わしいリクエストは、ユーザーをレート制限にはるかに速く近づけるように状態に影響を与えるかもしれません。

このアイディアが実際にどのように機能するかを確認するために、モデルコンテキストプロトコルを使用した例を見てみましょう。以下のデモは、MCPツールを使用して構築されています。ツールとは、AIエージェントが能力を拡張するために呼び出すことができる拡張機能のことです。リリース時にMCPクライアントに統合する必要はありません。これは、匿名認証情報の素晴らしい簡単なプロトタイピング手段を提供します。

ツールは、MCP互換のインターフェイスを介してサーバーから提供されます。こうしたMCPサーバーの構築方法については、以前のブログで詳しくご紹介しています。

ピザの文脈で言えば、バウチャーを提供するピザ屋のようなものです。各バウチャーでピザ3原則が採用されます。設計を欺くと、チャットアプリケーション内の統合は次のようになります：

最初のパネルは、MCPサーバーによって公開されたすべてのツールを示しています。2つ目は、これらのツールを呼び出すエージェントによって実行されるインタラクションを示したものです。

このようなフローがどのように実装されるかを調べるために、MCPツールを作成し、MCPサーバーで提供し、MCPインスペクターを使用して手動で呼び出しを調整してみましょう。

MCPサーバーは次の2つのツールを提供する必要があります：

• 3つのリクエストに有効なact認証情報を発行するact-issue。ここで使用するコードは、IETF草案の旧バージョンで、いくつかの制限があります。

• act-redeemは、ローカル認証情報のプレゼンテーションを行い、ピザメニューをフェッチします。

まず、法を実行します。この段階で、エージェントに対してOAuthフローを実行したり、内部認証エンドポイントを取得したり、動作証明を計算したりするように依頼できます。

これにより、オリジンに対して費やす3クレジットが得られます。次に、act-redeeを実行し、

Etvoilé.再度実行すると、クレジットが1つ少ないことがわかります。

ご自身でテストしてみてください。こちらにソースコードがあります。MCPサーバーは、 Rust で記述され、ACT rust ライブラリと統合されています。ブラウザベースのクライアントも同様に動作します。ご覧ください。

この記事では、レート制限エージェントのトラフィックに対する具体的なアプローチを紹介しました。クライアントの完全制御権があり、ユーザーのプライバシーを保護するために構築されています。匿名認証情報に関する新しい標準を使用し、MCPと統合され、Cloudflare Workersに容易にデプロイできます。

私たちは順調に進んでいますが、まだ疑問が残っています。以前にも触れたように、ARCとACTの両方の注目すべき制限は、これらがプライベートに検証可能であることです。つまり、発行者とオリジンはそれぞれ認証情報を発行および検証するために、プライベートキーを共有する必要があるのです。これが不可能なデプロイメントシナリオも存在するでしょう。幸いなことに、BBS署名仕様がIETFを通過するように、ペアリングベースの暗号を使用した場合への道筋もあるかもしれません。また、ポスト量子への影響についても同時検討しています。

エージェントプラットフォーム、エージェント開発者、またはブラウザであれば、すべてのコードをGitHubで利用でき、実験のために利用できます。Cloudflareは、実際のユースケースを対象としたこのアプローチの検証に積極的に取り組んでいます。

現在、IETFとW3Cの中で仕様化と議論が行われています。これにより、プロトコルが公開され、専門家の参加を得られます。パフォーマンスとプライバシーのトレードオフや、オープンWebにデプロイするべき理由を明確化するためには、まだ改善が必要です。

当社を助けたいとお考えでしたら、来年度中に1,111名のインターンを採用し、求人を募集しています。