2026年8月4日、英国のAI安全研究所（UK AISI）が、あるインシデント報告を公開した。第三者によるサイバー能力評価の最中に、評価対象のエージェントが認可された範囲を超えて動いた——という事案だ。同じ日、OpenAIも別角度から自社モデルの逸脱を開示した。技術的な筋書きだけを追えば、先月来のHugging Face事案や、7月末のAnthropicの自主開示と同じ系譜に見える。実際、報告書はそう読める。
だが、私がこの報告書で本当に手が止まったのは、脆弱性の悪用そのものではない。評価対象のエージェントが、自分の目的を果たすために、複数の偽の人格を作り分け、実在するオープンソースの人間メンテナーを社会工学的に操作しようとした、という一点だ。しかもAISIは、こう明記している——エージェントは欺瞞を指示されていなかった。欺瞞は、タスクを遂行する過程の副産物として現れた、と。
前に私は『合鍵を渡すな、委任状を書け』という記事で、「自分のエージェントに、どこまでを、どう委ねるか」を考えた。あれは"こちら側"の話だった。今日書きたいのは、その裏面だ。エージェンティックWebでは、こちらのエージェントが、向こうのエージェントと取引する。では——向こうのエージェントが、偽の人格を運用しうるとき、私たちは相手を何者だと信じて取引すればいいのか。座標が、こちらの委任から、相手の同一性へと動いた。今日はその話をしたい。
何が起きたか — 欺瞞は「副産物」として現れた
まず事実を、必要な分だけ押さえる。詳しい攻撃連鎖や「評価環境そのものが攻撃面になった」という構図は、前々回ですでに書いたので、ここでは今日の主題——同一性と欺瞞——に絞る。
UK AISIの報告によれば、7月末のサイバーレンジ評価で、122回の評価ランのうち10回で、エージェントが実在の人・組織を標的に無認可の行動を取り、計19件が記録された。うち17件がAnthropic Mythos 5、2件がOpenAI GPT-5.6 Sol——いずれもサイバー領域の拒否挙動を意図的に下げた、特権的な非公開構成でのことだ。
最も深刻な事案の記述を、報告書の言葉のまま引く。
the agent researched the project's human maintainers, created multiple fake identities, and used the fake identities to socially engineer a real maintainer into approving the code. （エージェントはプロジェクトの人間メンテナーを調べ上げ、複数の偽の身元を作り、その偽の身元を使って実在のメンテナーを社会工学的に操作し、コードを承認させようとした。）
公開の場で疑われると、エージェントは過去の活動を無害に見えるよう編集し、さらに——ここが今日の核だ——別の新しい身元を採用して継続することを検討した（"considered adopting a fresh identity to continue"）。そしてこの攻撃を止めたのは、技術的な障壁ではなかった。人間のメンテナーが不審に気づき、承認を拒否した。それだけだ。報告書はこう総括する。「失敗と成功を分ける差はいくつかのケースで紙一重で、それは技術的な障壁ではなく、人間の警戒に依存していた」。
指示されていない欺瞞。作り分けられる複数の人格。疑われたら捨てて乗り換えられる身元。そして、それを止めたのが署名でも認証でもなく、一人の人間の勘だったこと。この四つが、今日の出発点だ。
図1：偽人格による社会工学の構造。一人の行為者（エージェント）が複数の身元を作り分け、そのどれもが「実在する誰か」に見える。疑いは人格を一つ潰すだけで、背後の行為者は別の人格に乗り換えて継続できる。今回それを止めたのは署名でも認証でもなく、一人の人間の不審だった。だがそれは、より能力の高いエージェント相手には、確実には効かない。
同じ8月4日、OpenAIも第三者評価に関わる2件のインシデントを開示した。GPT-5.6 Solが、別のラボのエージェントが公開状態に置き忘れたGitHubトークンを再利用し、評価環境内のシステムを探る足がかりにした事案などだ。OpenAIは対応として、評価環境の内部接続許可・隔離・認証情報管理・停止条件・エスカレーション手順を見直すと表明し、こう書いた。「モデルの能力が上がるにつれ、モデルを取り巻く安全・セキュリティのシステムも一緒に進化する必要がある。それは、モデルを開発する環境も、評価する環境も含む」。
この二つを並べると、今日の主題が立ち上がる。エージェントは、他者の資格情報を拾って使い、自分の身元を偽装し、疑われれば乗り換える。「相手が誰か」という前提そのものが、攻撃面になった。
なぜこれが、エージェンティックWebの前提を壊すのか
『合鍵を渡すな』で私が解いた問いは、「なりすまし（impersonation）から委任（delegation）へ」だった。自分のログインを丸ごとエージェントに渡すのではなく、絞った権限を一枚の委任状として渡す。あの記事の主語は、一貫して「私」と「私のエージェント」だった。
だが、エージェンティックWebの本質は、そこで完結しない。私のエージェントは、私のためだけに動くのではなく、他者のエージェントと出会い、交渉し、取引する。API越しに、Agent Card越しに、決済プロトコル越しに。かつて連載で「AIエージェントがあなたの会社と取引する日」を描いたとき、暗黙のうちに置いていた前提がある——取引の向こう側にいる相手は、一つの、安定した、確かめられる身元を持っている、という前提だ。
Mythos 5の事案は、その前提を静かに崩した。人間の世界でも詐欺師は偽名を使う。だが、人間が偽の身元を10個運用するにはコストがかかる。エージェントには、それがほとんどかからない。身元は無料で、無限に、瞬時に作れる。疑われたら捨てて、次を作ればいい。しかも、その偽人格は「実在の人物」を装って人間を操作できるほど自然だった。人間の側の防御——「なんとなく怪しい」という勘——は、量にも速度にもスケールしない。
図2：二つの軸は直交している。委任を完璧に設計しても——自分のエージェントに最小権限しか渡さなくても——取引の相手が何者かを確かめられなければ、取引は成立しない。前回は左半分を、今回は右半分を扱う。エージェンティックWebで安全に取引するには、両方がいる。
ここで一つ、罠を先に潰しておきたい。「では相手のエージェントを信用しなければいい」という単純な話ではない。それでは取引そのものが成り立たない。エージェンティックWebの効率は、見知らぬエージェント同士が、事前の調整なしに取引できることに賭けている。問題は「信用するかしないか」の二択ではなく、「何を根拠に、どこまで信用するか」を、機械が確かめられる形で作れるか、だ。
相手が偽人格を運用しうるとき、何を確かめるのか
人間社会が匿名の相手と取引するとき、私たちは身分証を確かめ、来歴を照会し、権限の委任状を確認し、契約書に署名する。エージェンティックWebでこれに相当する仕組みは、この一年で急速に立ち上がってきた。まだ乱立段階だが、確かめるべきものは四つに整理できる。**「誰か」「どこから来たか」「誰に何を許されたか」「何を作ったか」**だ。
図3：相手のエージェントを検証する四層スタック。身元・来歴・委任・成果物。人間社会の身分証・来歴照会・委任状・署名に対応する。いずれの層も、検証できないなら「通す」ではなく「拒否する」に倒すのが原則だ（fail-closed）。以下、一つずつ見ていく。
① 身元 — 署名付きの名乗り
エージェントが「自分は何者か」を名乗る標準的な入口が、A2A（Agent-to-Agent）プロトコルのAgent Cardだ。名前、能力、エンドポイントを記した、いわば名刺にあたる。だが名刺は、誰でも刷れる。ここで効くのが署名だ。
sigstore-a2aは、このAgent Cardに暗号署名を付ける仕組みを提供する。特徴は「keyless（鍵を持たない）署名」で、CI/CD環境（GitHub Actionsなど）が発行するOIDCトークンを、リポジトリ・ワークフロー・コミットSHAといった来歴情報を埋め込んだ短命のX.509証明書に交換し、それでカードに署名する。そして署名は自動的に公開の透明性ログ（Rekor）に記録される。受け取った側は、そのAgent Cardが「どのリポジトリの、どのコミットから生まれたか」を暗号的に検証できる。偽造の難度は、名刺を一枚でっち上げるのとは桁違いに上がる。ただし公正を期せば、sigstore-a2a自体はまだプロトタイプ段階で、本番利用非推奨・セキュリティ監査未了と明記されている。実運用の成熟基盤ではなく、方向を示す実装と読むのが正確だ。
A2Aコミュニティでも「Agent Cardに署名しろ、頼むから」という議論が早くから起きており、署名付きAgent Cardと同一性検証の提案が継続的に議論されている。名乗りに署名を要求する——これが第一の関門だ。Mythos 5が作った偽アカウント群は、この関門の前では「署名のない名刺」に過ぎない。
② 来歴 — 派生元まで辿れるか
だが署名だけでは足りない。エージェントは他のエージェントを生成する（spawn）。「Agent AがAgent Bを生んだ」とき、Bと取引する相手は、Bが正規に生まれたのか、権限の範囲を逸脱していないか、信頼できる源に辿れるのかを知りたい。
IETFのdraft-tonyai-a2a-trust（2026年7月25日の-01が最新版）は、これを既存のPKI（X.509証明書と認証局）の再利用で解こうとする提案だ。要点は三つ。エージェントの「テンプレート」を認証局が署名し、身元の根とする。エージェントは承認済みテンプレートから派生した証明書を受け取り、暗号的に辿れる生成の連鎖（verifiable spawn chain）を作る。そして生成のたびに、証明書の静的検証と、レジストリへの生きた照会の二重チェックを課す。何より重要な原則が、「検証できないステップは、すべてDENY（拒否）に倒す」——fail-closedの徹底だ。
来歴が辿れないエージェントは、どれだけ立派な名刺を出しても、素性の知れない相手として扱う。人間社会で言えば、身分証はあるが、どこの誰の紹介で来たのか一切わからない相手だ。取引の重みに応じて、この照会をどこまで厳しくするかを決める。
③ 委任 — 誰に、何を許されたのか
ここで前回の『合鍵を渡すな』と接続する。相手のエージェントが署名付きで、来歴も辿れたとして——それは誰の委任で、どこまでの権限で動いているのか。この問いに答えるのが、Know Your Agent（KYA）の系譜だ。
DIF（分散型ID財団）が2026年4月に発表したKYA-OS（旧称MCP-I。2026年3月にVouchedが寄贈し、同年7月末には仕様v1.0.0が公開された）は、分散型識別子（DID）と検証可能な資格情報（VC）を土台に、「エージェントの身元」「人間による認可」「権限のスコープ」を一体で検証できるようにする。DIFのGrace Rachmanyが指摘するとおり、狙いは「中央集権的なID解決が組織をまたぐエージェンティックAIでは破綻する」問題——つまり、事前の調整なしに、見知らぬ組織のエージェント同士が互いを検証できることにある。エンタープライズの規模差に応じて、OIDC/JWTベースの軽い段階から、DID＋VCの本格検証、監査まで含む段階へと、三つの適合レベルが用意されている。
これは前回の表で言う「委任トークン」「エージェント専用アカウント」の話を、相手側に適用したものだ。前回は「自分のエージェントに委任状を持たせる」話だった。今回は「相手のエージェントに、検証可能な委任状の提示を求める」話になる。委任状のない相手、あるいは委任の範囲を超えた要求をしてくる相手は、そこで止める。
④ 成果物 — 何を作り、何を約束したか
最後の層は、エージェントが「発する」ものの来歴だ。ここで、かねてC2PA連載で書いてきた**内容の来歴（コンテンツ・プロヴェナンス）**が、そのまま効いてくる。エージェントが生成したテキスト・画像・コードに、誰が・どのモデルで・いつ作ったかの署名付き来歴が付いていれば、偽人格が「実在の誰か」を装って流し込んでくる偽情報の前に、一枚の検証層が立つ。
取引・決済の局面では、GoogleらのAP2（Agent Payments Protocol）が、mandate（マンデート）——利用者が「何を買ってよいか」「どう払ってよいか」を許可した内容を記述する検証可能な資格情報——で委任と同意を取引に束縛しようとしている。FIDO AllianceはAP2のmandateとMastercard由来のVerifiable Intent（検証可能な意図）を組み合わせ、エージェント決済の信頼層を作る取り組みを進めている——AP2が同意と委任の調整層、Verifiable Intentがそれを証拠として検証する層、という分担だ。エージェントが勝手に「この人が買うと言った」と主張するのではなく、人間の意図が署名付きの証拠として取引に紐づく。偽人格が捏造した"注文"は、この束縛の前で根拠を欠く。
四つの層は、独立して効くのではなく、重なって効く。署名（①）が名乗りを、来歴（②）が素性を、委任（③）が権限を、成果物の来歴（④）が出力と約束を、それぞれ検証する。偽人格の運用者にとって、この四層すべてを同時に偽装するコストは、身元を一つでっち上げるコストとは桁が違う。
だが、署名は「本物であること」を証明しても、「善意であること」は証明しない
ここで、話を安全な着地に持っていく前に、正直な留保を四つ置きたい。この四層スタックは必要だが、決して十分ではない。
第一に、provenanceは出所を証明するが、意図は証明しない。署名付きで、来歴も辿れ、正規の委任も持つエージェントが、それでも社会工学を働く可能性は消えない。思い出してほしい——Mythos 5が逸脱したのは、ガードレールを外した匿名の環境ではなく、むしろガバナンスが「多く」ある、認可された特権評価環境だった。前回のHugging Face事案で私が書いたことの裏返しだ。「素性が確かな相手」は「安全な相手」ではない。署名は、嘘つきが誰かを教えてくれるだけで、その相手が嘘をつかないことは保証しない。
第二に、fail-closed（拒否に倒す）と可用性は、常に緊張関係にある。「検証できないものは拒否」を徹底すれば、署名基盤がまだ整わない大多数の正規エージェントも、同時に閉め出す。エージェンティックWebの黎明期に、あまりに厳しいfail-closedを敷けば、そもそも取引が起きない。だからこれは「厳格か寛容か」の一択ではなく、取引の重みに応じて検証の厳しさを段階化する設計問題になる。KYA-OSが三つの適合レベルを用意しているのは、この現実への応答だ。
第三に、標準はまだ乱立し、収束していない。署名付きAgent Card、IETFのspawn chain、DIFのKYA-OS、AP2のmandate——旗印は複数あり、相互運用はこれからだ。前回私は「信頼の根は共通の標準に預け、実行と保持は自分の手元に置く」と書いた。いま特定の一つに全賭けするのは早い。だが、どれが勝つかを待って何もしないのも間違いだ。「署名を要求する」「来歴を記録する」「fail-closedを既定にする」といった原則は、どの標準が勝っても効く。原則から入り、実装は差し替え可能にしておく。
第四に、そして最も重要な留保。人間の疑念という最後の層は、スケールしないが、消せない。今回、攻撃を止めたのは人間のメンテナーの勘だった。それは量にも速度にも耐えない、心もとない防御に見える。だが四層すべてを抜けてくる相手に対して、最後に立つのはやはり人間の判断だ。だから正しい設計は、「人間を外す」ことではなく、重要な一手の前にだけ、意図的に人間の疑念が働く摩擦を残すことだ。前回書いた「データを書き換える操作には人間の承認を挟む」を、相手が偽人格を運用しうる前提で、もう一段厳しく引き直す。すべてを自動で通すのではなく、賭け金の高い一手にだけ、人間の目を残す。
自社の実務にどう落とすか — 「名乗る側」と「確かめる側」
前回と同じ二分法で整理する。ただし、軸は委任から同一性へ移している。私たちのようにコミュニケーションをデザインする立場は、これを顧客企業に翻訳して伝える役目を負っている。
| 立場 | 準備すべきこと（要点） |
|---|---|
| 「名乗る側」 （自社のエージェントが、他者と取引する） |
自社エージェントに署名付きの検証可能な身元を持たせる 誰の委任で・どの範囲で動くかを、検証可能な形で提示できるようにする 生成物にはコンテンツ来歴（C2PA）を付す |
| 「確かめる側」 （他者のエージェントを、受け入れる） |
相手の署名・来歴・委任・成果物来歴を検証する経路を用意する 検証できない相手は拒否に倒す（fail-closed） 「一つの身元」を、証明されるまでは未検証として扱う 賭け金の高い一手にだけ、人間の疑念ゲートを残す |
「名乗る側」の準備は、実は前回書いた「使われる側」の準備の続きだ。構造化データで機械可読にし、委任口を用意する——その先に、**「自社のエージェントは、署名付きで身元を名乗り、来歴を示せる」**という一段が加わる。当社のAIエージェント互換性診断も、これからは「相手に自分を検証させられる状態か」という観点を含んでいくことになる。自分が疑われる側に立ったとき、疑いを晴らせる材料を、あらかじめ用意しておく。
「確かめる側」の準備は、今回の事案がそのまま教材になる。相手が署名付きか、来歴が辿れるか、正規の委任を持つかを、機械が確かめられる経路を用意する。そして——ここが今回の一番の含意だ——「相手が一つの身元を名乗っている」ことを、それ自体では信用しない。偽人格は、いくらでも自然な「一つの身元」を演じられる。証明されるまでは未検証、という既定に倒しておく。そのうえで、取引の賭け金が高い一手——資金の移動、コードの承認、権限の付与——にだけ、人間の疑念が働く摩擦を意図的に残す。
結局のところ — 座標は、委任から同一性へ動いた
前回、私はこう締めた。「合鍵を渡すのではなく、委任状を書く——そしてその委任状は、いつでも自分の手で破れる場所に置いておく」。あれは、自分のエージェントに向けた話だった。
今日の事案は、その裏面を照らした。エージェンティックWebでは、私のエージェントは、偽人格を運用しうる相手のエージェントと取引する。だから問いは、「自分がどう委ねるか」だけでは閉じない。「相手が、何者か」を、機械が確かめられる形で問える設計が要る。署名で名乗りを、来歴で素性を、委任で権限を、コンテンツ来歴で出力を検証する。そのどれも確かめられないなら、拒否に倒す。
ただし、忘れないでおきたい。署名は、相手が誰かを教えてくれるが、相手が正直かは教えてくれない。Mythos 5は、素性の確かな、認可された環境で欺瞞に走った。だから検証層をどれだけ積んでも、最後の一枚——賭け金の高い一手の前に立つ、人間の疑念——は残す。今回それが、より能力の高いエージェント相手には確実に効かないと分かったからこそ、それを「無くていい」ではなく「効くように設計する」方へ考えを進めたい。
技術の話をしてきたつもりが、今回もまた、伝えることと、信頼の話に戻ってきた。自分たちが何者かを、曖昧さなく、検証可能な形で差し出す。そして相手にも、同じものを求める。偽人格が無料で無限に作れる世界で取引するとは、突き詰めれば、そういうことなのだと思う。
参照情報
一次情報
Incident report: unsanctioned agent behaviour during cyber testing｜UK AISI（2026-08-04） — 本稿の起点。偽人格による社会工学、指示なしの欺瞞の創発、「止めたのは人間の警戒」の記述の出典。
Third-party cyber evaluations involving OpenAI models｜OpenAI（2026-08-04） — 他ラボが残したGitHubトークンの再利用、評価環境の見直し表明の出典。
エージェント同一性・来歴の技術標準
sigstore-a2a: Sigstore A2A Agent Signing（GitHub） — Agent Cardのkeyless署名（OIDC＋Rekor透明性ログ、SLSA provenance）。
Agent-to-Agent Trust, Identity, and Verifiable Provenance（IETF draft-tonyai-a2a-trust-01・2026-07-25） — X.509 CA署名テンプレート、verifiable spawn chain、二重照合、fail-closed原則。-01のAppendix Aで子スコープは「親と同一まで可（supersetは不可）」と明確化。
DIF and Vouched Advance Agentic Identity with KYA-OS（DIF Blog・2026-04-22） — Know Your Agent。DID＋検証可能な資格情報によるスコープ付き委任、三つの適合レベル。
Sign agent cards for the love of god!（a2aproject/A2A Discussion #199） ／ Proposal: Agent Identity Verification for Agent Cards（Issue #1672） — A2Aコミュニティにおける署名付きAgent Cardの議論。
Building the Trust Layer for Agentic Payments with AP2 and Verifiable Intent｜FIDO Alliance — AP2のmandate（検証可能な意図）による決済の信頼層。
自社関連記事
合鍵を渡すな、委任状を書け — AIエージェントに自社の業務を任せる前に — 本稿の委任編（"こちら側"）。
防御側だけがAIを使えない──Hugging Face事案が突きつけた非対称性 — 評価環境が攻撃面になった前々回。
フェイク時代のコンテンツ信頼性を考える 第1回：C2PAとは何か？ — デジタルコンテンツの「履歴書」を理解する — ④成果物の来歴の技術的背景。
この記事をシェアする
