Sierra Personal Agent Protocol、35社のパートナーを追加も企業側が主導権を維持

Sierraは、35社の新たなデザインパートナーとともにPersonal Agent Protocolのドラフトを公開し、Poppyを単なる提案から本格的な標準化への取り組みへと前進させた。Sierra Personal Agent Protocolには現在、OpenAI、Bank of America、Mastercard、PayPal、Visa、Cloudflareなどの大手企業からの意見が反映されている。

この発表が重要なのは、パーソナルエージェントがしばしば人間向けに設計されたインターフェースを通じて企業システムに入るためだ。エージェントはページを閲覧し、フォームに入力し、ときには広範なアカウントアクセスを持つ認証情報を利用する。Poppyは、企業がエージェントを認識し、ユーザーが権限を承認し、1つのセッションがWebサイト、API、企業エージェントをまたげる中間的な仕組みを提案している。

同時に、その中間的な仕組みこそが中心的な対立を生む。パーソナルエージェントは有用であるために幅広く一貫したアクセスを必要とする一方、企業はアイデンティティ、権限、チャネル、顧客関係を管理したい。Sierraは、この境界を交渉するために異例なほど幅広い組織を集めた。しかし、それらの企業が最終的にこのプロトコルを導入することはまだ示されていない。

Sierra Personal Agent Protocol、35社のデザインパートナーを追加

Poppyは初期発表から公開技術ドラフトへ進んだが、現時点での参加は本番導入ではなく、設計への意見提供を意味する。

Sierraは2026年10月9日にPoppyドラフトを公開した。同社はまた、金融、小売、旅行、保険、メディア、アイデンティティ、通信、AIにまたがる35社の追加デザインパートナーを発表した。

新たなグループには、Adyen、Atomic、Bank of America、BBVA、Chime、Cigna、Cloudflare、Comcast、DIRECTV、ElevenLabs、FOX、Gap Inc.、GEICO、Hertzが含まれる。さらに、Insurify、Klaviyo、Liberty Mutual、Mastercard、Nordstrom、Notion、Okta、OneSignal、OpenAI、PayPal、Plaid、SiriusXMも名を連ねる。

Synchrony、Target、United Airlines、Venmo、Visa、Wells Fargo、Zapier、Zendesk、1Passwordが追加グループを構成する。これらの組織は、Meta、Genesys、Instinct、NiCE、Rocket、Shopify、Stripe、Walmartなど、初期発表に関与した企業に加わる。

当初のグループと35社の追加企業を区別することは重要だ。Sierraが発表したのは参加企業の総数35社ではない。同社は10月6日、Metaと複数のビジネステクノロジーパートナーとともにプロジェクトを紹介した後、さらに35社を発表した。

Sierraによると、新たな企業は自社の事業要件に基づくフィードバックを提供する。このリストは、通常であれば取引において異なる立場を担う組織を集めている。

銀行と決済ネットワークはアイデンティティ、不正行為、認可、決済を管理する。小売企業は在庫、購入手続き、返品、顧客アカウントを管理する。アイデンティティプロバイダーは認証を統括する。AI企業は、アクセスを要求するパーソナルエージェントを構築する。

それぞれの利害は重なり合うものの、同一ではない。エージェント開発者は、1つの統合で多くの企業に接続できるほど利益を得る。銀行は、各アクションが追跡可能で、制限され、取り消し可能な状態に保たれることで利益を得る。小売企業は、サービス方針や顧客関係の管理を失わずにエージェントトラフィックを受け入れたいと考える。

そのため、パートナー一覧は単に見慣れたロゴを集めたものではない。これはSierraに対し、検出、委任されたアクセス、現実世界のアクションの境界について合意しなければならない当事者への接点を与える。

ただし、デザインパートナーが自動的に実装者になるわけではない。SierraはPoppyの本番利用件数、完了済みの統合、取引量を公表していない。この発表が示すのは設計プロセスへの参加であり、名前が挙がったすべての企業における運用サポートではない。

Sierraは今後1か月間で設計ワークショップを実施し、リファレンス実装を公開するとしている。これらの成果物は、パートナー数よりも強い試金石となる。開発者が実装コストを判断するには、動作するコード、テスト環境、安定した適合性ルールが必要だ。

したがって、今回の公開はプロトコルの成熟度ではなく信頼性を変えるものだ。Poppyには現在、公開仕様と多くの関心を持つ企業がある。一方で、これは依然としてDraft 0.1であり、主要な技術面およびガバナンス面の判断は未決のままである。

Poppyは権限をプロダクトにする

Poppyの主な貢献は、別のエージェント間メッセージング形式ではない。企業が管理するシステム内で行動するエージェント向けの、共有セッションおよび権限モデルである。

Draft 0.1仕様は、パーソナルエージェントを1人のユーザーのために行動するソフトウェアと定義している。企業は、そのエージェントによるサービスとのやり取りを許可する組織として定義される。

参加企業は/.well-known/poppy.jsonにディスカバリードキュメントを公開する。このドキュメントは組織を識別し、その認証オプション、API、Webサイトアクセス、企業エージェント、対応する拡張機能を列挙する。

このパターンは、ほかのwell-knownなWebディスカバリーメカニズムに似ている。Poppyは、エージェント開発者が個別の統合手順を探す必要をなくし、予測可能な単一の開始アドレスをエージェントに提供する。

ディスカバリーは最初の層にすぎない。パーソナルエージェントは特定のユーザー向けにセッションを開き、自身を企業に識別する。この設計により、企業は自動化された活動と、サイトを直接利用する人物を区別できる。

セッションはアカウントアクセスなしで開始できる。たとえば、エージェントはゲストとして商品の在庫状況を確認したり、返品方針について質問したりできる。タスクに個人のアカウント情報やアカウント変更が必要になった場合、ユーザーはサインインする。

Poppyは直接サインイン、デバイスサインイン、仲介型サインインを定義している。直接サインインでは、認証は企業自身のページ上で行われる。デバイスサインインでは、ユーザーがリンクをたどってコードを入力することで、別のデバイスからアクセスを承認できる。

仲介型サインインでは、企業がその方法を許可する場合に、エージェントが認証情報を企業指定のエンドポイントへ送信できる。この選択肢は互換性を提供する一方、ドラフトにおける最も慎重な検討を要するセキュリティ上の問題の1つも生み出す。

認可されると、エージェントはスコープ付きアクセスを受け取る。広範なpoppy:readスコープはアカウント情報の閲覧を対象とし、poppy:writeは交換や予約更新などの変更を対象とする。企業はより限定的な活動のために追加スコープを定義できる。

これらのスコープは、満足できない2つの極端な選択肢の間に権限の段階を設ける。企業はすべてのエージェントを遮断する必要がない。ユーザーも、アカウントを通じて利用可能なすべての機能をエージェントに与える必要がない。

セッションは、対応するインターフェースをまたいでユーザーに追従する。エージェントはWebページ、OpenAPIエンドポイント、MCPサーバー、企業エージェントとの会話の間を移動できる。サインイン前の質問と後のアカウント変更を、1回の訪問の一部として維持できる。

この連続性は双方にとって重要だ。ユーザーは同じ目的を繰り返し説明せずに済む。企業は、セッションがチャネルをまたいでどのように進んだかについて、より一貫した記録を得られる。

Poppyは、人間をエージェントとの会話に加える方法も定義している。メッセージには、AIと人間のどちらが作成したかが示される。パーソナルエージェントは人間の担当者を要請でき、ユーザーはエージェント間の過去のやり取りを読まずに直接の会話へ入ることができる。

欠航便を考えてみよう。パーソナルエージェントは航空会社の対応インターフェースを検出し、セッションを開始して、アカウントアクセスなしに代替便を検索できる。その後、ユーザーはサインインし、予約アクセスを承認して、振替便を確定できる。

小売企業は異なる方針を適用できる。エージェントによる返品開始は許可する一方、保存済み決済情報の変更は遮断することができる。各権限でどの操作が可能になるかは、パーソナルエージェントではなく企業が決定する。

この仕組みは、プロトコルが企業にとって魅力的である理由を説明する。Poppyは、企業に外部エージェントへの方針の明け渡しを求めない。複数の技術チャネルで方針を公開し、適用するための標準的な方法を提供する。

主導権を維持するのはパーソナルエージェントではなく企業

プロトコルはユーザーの選択を約束するが、そのアーキテクチャは、どのエージェントを受け入れ、何を実行可能にするかについて、参加企業に大きな管理権限を与える。

SierraはPoppyを、エージェントアクセスと企業監督の間の妥協策として位置付けている。ユーザーはパーソナルエージェントを選び、そのアカウント権限を承認する。企業は、対応するインターフェース、サインイン方式、スコープ、アクションを決定する。

この分担は高いレベルでは均衡しているように見える。実際の結果は、企業が実装をどのように構成するかに左右される。

企業はWebサイトのみ、選択したAPIのみ、あるいはタスク範囲を限定した企業エージェントのみを公開できる。書き込みアクセスを与えず、読み取りアクセスだけをサポートすることもできる。機密性の高いアクションには直接サインインを要求し、認識していないエージェントを拒否することも可能だ。

したがって、このプロトコルが標準化するのは普遍的なアクセスよりも交渉である。Poppyファイルの公開によって、企業がすべての顧客操作を公開する必要はない。それは、どの入口が存在し、どの条件が適用されるかをエージェントに伝えるものとなる。

このモデルは、現在のWebにおけるコストの高い対立に直接対処する。人間向けインターフェースを利用するエージェントは不正利用のように見える場合があるため、企業はしばしば自動化を検出しようとする。エージェント開発者は、そのような制御下でも機能し続けるためにブラウザーを適応させる。

この競争から、どちらの側も信頼できる情報を得られない。企業は、どのサービスがエージェントを運用しているのか、どのユーザーを代表しているのかを把握できない可能性がある。エージェントは、アクションの失敗が方針、認証、インターフェース変更のどれによるものかを判断できない可能性がある。

Poppyは、この曖昧さの一部を明示的なアイデンティティと方針に置き換える。企業はパーソナルエージェントのクライアントアイデンティティを認識し、それを1人のユーザーに関連付け、承認済みスコープに限定されたトークンを発行できる。

この仕組みにより、正当なエージェントは匿名の自動化と区別しやすくなるはずだ。ただし、不正行為、侵害されたアカウント、プロンプトインジェクション、悪意あるエージェント開発者がなくなるわけではない。セキュリティ管理を適用するための、より構造化された証拠を生み出す。

ユーザーはより明確な選択肢を得るが、その選択肢は企業方針によって制限される。企業が公開しない機能を、個人がエージェントに付与することはできない。同様に、参加企業の1社が別の企業に対し、好むエージェントの受け入れを強制することもできない。

これがSierra Personal Agent Protocolの中核にあるトレードオフだ。一貫したディスカバリーと認可は、正当なエージェントアクセスを拡大し得る。同じ設計は、各企業がそのアクセスを制限する権利も形式化する。

この均衡は、規制対象組織での導入を促す可能性がある。Bank of America、BBVA、Wells Fargo、Cigna、複数の保険会社は、無制限の自動化を非現実的にする義務を負っている。データの閲覧とアカウント変更の間に、監査可能性と明確な区別が必要となる。

決済企業にも同様の動機がある。Mastercard、Visa、PayPal、Venmo、Adyen、Plaid、Synchronyは、どの当事者がアクションを開始したのかを把握する必要がある。また、顧客と取引の間にAIインターフェースが介在しても有効な管理手段を必要としている。

パーソナルエージェントの構築者にとって、この妥協はカスタム統合を減らせるなら依然として魅力的だ。各企業が異なるビジネス操作を公開する場合でも、1つのディスカバリー形式と1つの認可モデルには価値がある。

より大きなリスクは、標準内部の断片化である。企業はカスタムスコープや拡張機能を定義でき、各APIはそれぞれ独自のスキーマを維持する。2つの組織がともにPoppyをサポートしていても、必要な実装作業は大きく異なる可能性がある。

Poppyは、エージェントが到着し、自身を識別し、アクセスを要求する方法を標準化できる。すべての住宅ローン申請、保険請求、フライト変更、小売返品を自動的に標準化することはできない。

この制約がプロジェクトを無意味にするわけではない。むしろ、難しい作業がどこから始まるのかを明確にする。プロトコルは共通の入口を確立できる一方で、その内側で何が起こるかは、業界や個々の企業が引き続き定義する。

既存のエージェント標準は競合ではなく入力である

Poppyが最も信頼性を持つのは、MCP、A2A、OpenAPI、あるいはコマースプロトコルを置き換えるものではなく、既存の標準を活用するオーケストレーション層としてである。

現在、エージェント標準は複数の異なる境界を対象としている。それらを勝者総取りの競争として扱うと、それぞれが解決する問題が見えにくくなる。

Anthropicは、AIアプリケーションと外部ツールまたはデータを接続する標準としてModel Context Protocolを導入した。MCPサーバーは、AIクライアントが発見し呼び出せる機能を公開できる。

Googleはもともと、独立したエージェント間の通信と協働のためにA2A protocolを開発した。A2Aは、ベンダーの境界を越えてエージェント同士がタスク、メッセージ、成果物、ステータス情報を交換することに焦点を当てている。

Poppyが扱うのは、より広範なユーザーと企業の関係である。企業の発見、パーソナルエージェントのアイデンティティ、ユーザーセッション、認可、ウェブ閲覧、API、企業とエージェントの会話、人間への引き継ぎを対象とする。

この違いはPoppyのアーキテクチャに表れている。企業は、利用可能なAPIの一つとしてMCPサーバーを掲載できる。OpenAPIの記述を掲載したり、通常のウェブサイトを提供したり、企業エージェントを公開したりすることもできる。

したがってMCPは、Poppyセッション内の一つの経路である。Poppyは、ツールインターフェースだけでは完全には定義できない、周辺のアイデンティティ、ユーザー認可、チャネルをまたぐ継続性を提供する。

A2Aも同様の関係にある。企業エージェントとパーソナルエージェントには通信手段が必要だが、その会話は訪問全体の一部にすぎない。パーソナルエージェントはページを閲覧したり、従来型のAPIを呼び出したりする場合もある。

コマース標準は別の層を形成する。ShopifyとGoogleのUniversal Commerce Protocolは、商品発見、チェックアウト、注文管理といったコマース活動に焦点を当てている。

SierraはUCPを補完的なものとして明確に説明している。Poppyは、エージェントが誰を代表し、ユーザーが何を認可したかを確立できる。コマースプロトコルは、その後に購入や注文管理に関わる領域固有の操作を定義できる。

この階層型アプローチは実用的だ。企業はすでに多様な技術スタックを抱えている。小売業者は、UCPのコマースワークフロー、MCPのカスタマーサービスサーバー、通常のウェブページを公開しているかもしれない。Poppyは、こうした接点を一つの認識可能なセッションへつなぐことを目指している。

このアプローチは、すべての業務プロセスを自然言語によるエージェントとの会話に押し込むことも避けられる。多くの操作では、構造化APIのほうが依然として効率的で予測可能だ。ウェブアクセスは、モダンなAPIを欠く古いシステムを補完できる。

Sierraによれば、このプロトコルはOAuth、HTTPS、JSON Web Tokens、OpenAPI、MCPを基盤としている。こうした選択により、既存のウェブセキュリティやAPIツールに精通するチームにとって、概念的な障壁が下がる。

既存のコンポーネントを利用しても、相互運用性が保証されるわけではない。周辺のプロファイルは、二つの独立した実装が一貫して動作するほど正確でなければならない。トークンのオーディエンス、スコープの強制、再試行、障害状態に関する曖昧さは、依然として互換性のないシステムを生み得る。

このため、プロトコルのリファレンス実装は重要になる。開発者に必要なのは、文章による要件だけではない。エージェント登録、発見の検証、トークン交換、ブラウザーセッション、会話の引き継ぎについて、テスト可能な例が必要だ。

適合性についても同じことが言える。企業ごとに任意機能を異なる方法で解釈すれば、パーソナルエージェントには組織固有のロジックがなお必要になる。有用な標準は、基本的な互換性のためにどの挙動が必須なのかを示さなければならない。

Poppyの幅広いパートナーグループは、こうした詳細の解決に役立つ可能性がある。一方で、参加者が競合するプラットフォーム、規制環境、顧客関係を代表しているため、合意形成を遅らせる可能性もある。

最良の結果は、一つのプロトコルが他のすべてのプロトコルを置き換えることではない。各層が明確な責任を持つスタックである。Poppyは、そのスタック全体でアイデンティティ、権限、セッションの継続性を予測可能にできれば成功する。

ドラフトには難しいセキュリティ上の問題が残されている

Poppyはセキュリティの枠組みを提供するが、Draft 0.1は、ソフトウェアが顧客のアカウントを通じて行動できることによるリスクを排除するものではない。

仕様書は、安定版になる前であればDraft 0.1のどの部分も変更され得ると警告している。この層での認可エラーは、購入、予約、金融申請、個人データに影響を及ぼし得るため、その警告は重要だ。

Poppyは短命のセッショントークンを用い、リクエストをエージェントのアイデンティティに結び付ける。また、リクエスト元がトークンに関連付けられた鍵を保持していることを証明する、Proof-of-Possession保護も説明している。

こうした制御はトークンの再利用を減らし、企業が自動化された活動を追跡する助けとなり得る。ただし、その有効性は正しい実装、安全な鍵保管、公開されるすべてのインターフェースでの一貫した検証に依存する。

チャネル横断のセッションは利便性を高める一方で、強制適用の対象範囲を広げる。企業は、API、ブラウザーエンドポイント、エージェントとの会話全体で、同じアカウント状態と権限境界を適用しなければならない。

APIでは強制されるがウェブページでは無視されるスコープは、迂回経路を生む。企業エージェントがセッションの権限外の操作を実行する場合も、別の問題となる。

仲介型サインインには、特に注意深い検討が必要だ。このモデルでは、パーソナルエージェントが認証情報を企業に送信する前に処理する。仕様書は、エージェントに対し、秘密フィールドを保護し、表示やログ記録を避けるよう求めている。

この要件は有用だが、すべてのエージェントが認証情報を安全に扱うことを証明するものではない。企業は、仲介型サインインが機密性の高いアカウントにとって許容できない露出を生むと判断するかもしれない。

直接サインインは、ユーザーが企業自身のページで認証するため、より明確な境界を提供する。パーソナルエージェントが別のデバイスで動作する場合、デバイスサインインも同様の分離を実現できる。

権限設計も別の問題を提示する。大まかなreadとwriteスコープは単純だが、実際のサービスには結果が大きく異なる操作が含まれる。

ニュースレターの設定変更と住所変更は、どちらも書き込み操作である。ジャケットの返品と送金も同様に書き込み操作だ。企業には、影響の大きい操作のために、より細かなカスタムスコープや追加承認が必要になる。

カスタムスコープは制御を改善する一方で、相互運用性を損なうおそれがある。エージェントは、ユーザーに説明する前に各スコープの意味を理解しなければならない。類似の操作でも、企業によって異なる名称が付けられる可能性がある。

ユーザーの理解も同様に重要だ。人々は詳細を確認せずにアクセス許可のプロンプトを承認することが多い。エージェントの追加は、一度の承認が繰り返しの自律的な操作を支え得るため、リスクを高める。

信頼できるインターフェースは、どのエージェントがアクセスを要求しているのか、どのアカウントを使うのか、何を読み取れるのか、何を変更できるのかを説明しなければならない。また、取り消しも容易にすべきだ。

ドラフトは取り消しをサポートし、後続セッションの開始に使う長期アカウントトークンについても説明している。この利便性は、ユーザーのアカウントとパーソナルエージェントの間に永続的な関係を生み出す。

企業とエージェント提供者は、こうした関係について明確な記録を必要とする。ユーザーは、有効な接続、付与されたスコープ、最近の操作、有効期限を確認できるべきだ。

プロンプトインジェクションは、プロトコルが直接制御できる範囲の外にある。エージェントは、ウェブページ、メッセージ、外部文書から悪意ある指示を受け取る可能性がある。有効な認証があっても、エージェントの最終的な判断がユーザーの意図に沿うことは保証されない。

この懸念は、エージェントが複数の情報源からの情報を組み合わせる場合に特に重要になる。優れたパーソナルナレッジマネジメントはコンテキストを改善できるが、コンテキストが増えるほど、情報開示と行動に関する境界をより強固にする必要がある。

人間による確認は、購入、予約、アカウント変更のリスクを減らせる。しかし、すべての小さな手順で確認を求めれば、パーソナルエージェントが約束する効率性を損なう。

そのためプロトコルには、安全なトークン交換以上のものが必要だ。実装には、リスクベースの承認、取引記録、回復プロセス、エージェントが高額なミスをした際の明確な責任が必要となる。

銀行、決済、アイデンティティ、保険、クラウドセキュリティのデザインパートナーは、こうした問題のストレステストに役立つ可能性がある。ただし、その名前だけで問題が解決されるわけではない。

独立したセキュリティレビューも、もう一つの重要なシグナルとなる。公開された脅威モデル、相互運用性テスト、文書化された障害は、信頼や制御に関する声明よりも多くの証拠を提供するだろう。

Poppyは、その制御が敵対的な条件下でも一貫性を保つかどうかで評価されるべきだ。成功したデモンストレーションは有用だ。回復可能な失敗のほうが、より多くを示すことも多い。

Poppyの将来を決める三つのシグナル

実際に動作するコード、実企業での導入、独立したセキュリティテストが、Poppyがインフラになるのか、野心的なドラフトにとどまるのかを決める。

最初のシグナルは、Sierraが約束したリファレンス実装である。同社は、今後1か月のデザインワークショップ後に公開する予定だとしている。

有用なリリースには、やり取りの両側が含まれるべきだ。開発者には、サンプルのパーソナルエージェント、参加企業のサービス、発見用ドキュメント、認証フロー、スコープ強制のテストが必要になる。

実装では障害も示すべきだ。期限切れトークン、取り消されたアクセス、不十分なスコープ、重複メッセージ、人間への引き継ぎ、中断されたストリームは、本番システムでは通常の状態である。

明確なコードと適合性テストは、企業が使い慣れたツールでプロトコルを実装できるというSierraの主張を強めるだろう。遅延や、狭く台本化されたデモは、その主張を弱める。

二つ目のシグナルは、名前が挙がっているパートナーによる採用である。パートナーが管理するドメイン上の公開poppy.jsonファイルは、また一つの設計発表よりも重みを持つ。

初期導入ですべての操作をサポートする必要はない。小売業者は、商品に関する質問と返品状況から始められる。航空会社は、予約変更を許可する前に、スケジュール情報を公開できる。

重要なのは、独立したパーソナルエージェントが非公開の統合なしに、こうした機能を発見して利用できるかどうかだ。アクセスにカスタム契約や文書化されていない挙動がなお必要なら、この標準はポータビリティを実現していない。

パーソナルエージェント側では、OpenAIとMetaが特に重要である。両社の参加は広範な配布の可能性を生む。いずれの名前も、消費者向け製品がPoppyをサポートすることを保証するものではない。

企業側では、銀行、決済会社、小売業者、旅行事業者が重要となる。これらの導入判断は、どの認証・権限モデルが規制や不正利用の審査を生き残るかを明らかにするだろう。

三つ目のシグナルは、セキュリティモデルが管理されたデモンストレーションを超えて機能することを示す証拠である。公開された脅威モデル、第三者監査、相互運用性イベント、テスト後に文書化された修正に注目すべきだ。

アカウント操作を可能にするプロトコルは、厳しい検証を招く。それは健全なことだ。研究者は、発見の検証、トークンバインディング、カスタムスコープ、ブラウザーセッション、認証情報の取り扱い、エージェントなりすまし防御をテストできるべきである。

この三つのシグナルは互いを強化する。リファレンスコードはテストを可能にする。実際の導入は運用上の問題を明らかにする。独立したレビューは、弱点が多くのサービスに広がる前に特定する。

パートナー一覧は、Sierra Personal Agent Protocolに強力な出発点を与えている。パーソナルエージェントが質問への回答から取引の完了へ移行する際に最も影響を受ける業界を網羅している。

それでも、標準が成功するかどうかは発表時の勢いではなく、繰り返し実装されるかにかかっている。企業は有用な機能を公開しなければならない。エージェント開発者はプロトコルを一貫してサポートする必要がある。ユーザーは、自らが付与する権限を理解し、信頼できなければならない。

開発者にとって当面の対応は、ドラフトを精査し、そのセッションモデルを既存の認証アーキテクチャと比較することだ。具体的な非互換性、欠落している障害状態、あるいは不明確なセキュリティ要件を指摘するフィードバックが最も有益となる。

エンタープライズの購入担当者は、参加が設計へのフィードバック、パイロット導入、あるいは本格導入の確約のどれを意味するのかをベンダーに確認すべきだ。これらの用語は、まったく異なる水準の支援を表している。

パーソナルエージェントのユーザーは、実際にどこで制御が可能になるのかを注視すべきだ。有効な接続を確認できるか、実行できるアクションを制限できるか、履歴を確認できるか、複数の製品を行き来せずにアクセスを取り消せるか。

Poppyは、エージェントのブロックと偽装が繰り返される不安定な競争を、明示的な協力関係へ置き換えようとしている。それは意義のある目標だ。今後1か月で、Sierraとパートナー各社がその目標を、他社が安全に実装できるコードへと変えられるかが明らかになるはずだ。