AIエージェントが社内の資料を読み、その内容を別のサービスへ送ろうとしています。接続してきたプログラムが正規のものだと確認できれば、送信まで許してよいのでしょうか。「誰からの要求か」と「その操作をしてよいか」は、別の問いです。
2026年8月のOCP Korea Tech Dayで、Seokbin Yoon氏は、人以外の主体を識別するNHI（Non-Human Identity）を軸に、AI基盤の信頼を論じました。資料にはTrust Connector代表と西江大学AI・SW大学院特任教授の両肩書が記されています。本稿では、その講演が提起する操作前の認可を、NISTのゼロトラストの考え方とSPIFFEの公式資料に照らして読みます。［1］
簡単にまとめると？
- SPIFFEは、動いているソフトウェアに識別情報を持たせ、相手へ示すための仕組みです。
- 認証情報が有効でも、資料の閲覧、外部送信、削除をすべて許されたことにはなりません。
- 操作を許す判断と、実際に通す・止める役割を分けると、エージェントへ渡す権限の境目が見えます。
SPIFFEは、動いているソフトウェアを見分ける
人が操作する画面のログインだけでなく、ソフトウェアどうしの通信にも、相手を確かめる仕組みが必要です。SPIFFEでは、特定の設定と目的で動くソフトウェアをワークロードと呼びます。一つのサーバーそのものとは限らず、同じサーバー上の個々の処理を分けたり、複数のサーバーで動く同じ仕事をまとめたりする単位です。［2］
ワークロードを表す名前がSPIFFE ID、その識別情報を相手が検証できる形にしたものがSVID（SPIFFE Verifiable Identity Document）です。たとえばX.509証明書の形式を使い、発行元を信頼する根拠に照らして確かめます。Workload APIは短い有効期間の証明書や鍵を渡し、自動更新を支えるため、アプリケーションと長く使う秘密情報を一緒に配る運用を減らせます。［2］
ただし、その仕組みは、別のワークロードに認証情報を盗まれないよう実行環境が隔離されていることを前提にしています。SPIFFEを入れればプログラムの隔離まで完成する、という意味ではありません。［2］
正規の相手でも、すべての操作を許すわけではない
相手の識別情報を確かめる認証と、要求された操作を許す認可を、ここで分けて考えます。NIST SP 800-207は、資源へ接続する前に行う別々の機能として両者を扱っています。一つの資源へアクセスできたことが、別の資源へのアクセス許可にそのまま引き継がれるわけでもありません。［3］
冒頭の例なら、資料を読む権限と、資料を社外へ送る権限は同じではありません。同じエージェントが、同じ有効な認証情報を使っていても、要求の対象と操作が変われば、許される範囲を確かめ直す必要があります。これは仕組みの違いを説明するための例で、特定の製品で行った実験結果ではありません。
Yoon氏の講演は、実行する主体やコードの状態に加えて、誰からどの権限を委ねられたのかを問います。操作前の判断に、使えるツールやデータの範囲、回数などの上限、権限の有効期間を含める提案です。これらは講演者の設計上の整理であり、SVIDを一枚受け取るだけで、人間からの委任内容まで自動的に証明されるわけではありません。［1］
判断する役割と、通す・止める役割
NISTの原図では、要求を判断する側と、資源へ向かう通信を実際に制御する側が分かれています。図の上にあるPolicy Engine（PE）が、組織の方針や状態の情報から許可・拒否・許可の取り消しを決めます。その判断を受けて、Policy Administrator（PA）が通信経路を開く・閉じるための制御を行います。［3］
下部のPolicy Enforcement Point（PEP）は、要求する側と資源の間に置かれ、接続を通す、監視する、終了させる役割です。右側の識別管理や、左側のログ・機器状態などは、判断へ情報を渡す側にあります。相手のIDは判断材料の一つであり、それだけがすべての操作許可を決める構成ではありません。［3］
この図は論理的な役割を示すもので、箱の数だけ製品やサーバーを用意する指示ではありません。NISTも、PEとPAを一つのサービスとして実装する場合を挙げています。AIエージェントへ当てはめるなら、モデルが提案した操作を、資源へ届く前に方針に照らして確かめ、許可された経路だけを通す、と読むことができます。この対応づけは本稿の説明で、NISTの図自体が特定のエージェント製品やツールを規定しているわけではありません。［3］
組織をまたぐ認証にも、権限の判断は残る
SPIFFEには、識別情報の発行と検証の基点をまとめるトラストドメインがあります。SPIREの公式資料は、異なるトラストドメインに属するワークロードどうしを認証するフェデレーションを説明しています。そのため、講演中の「SPIFFEだけでは組織を越える扱いが足りない」という論点を、「SPIFFEは組織間の認証ができない」と読み替えるのは正確ではありません。［1］［4］
相手の発行元を受け入れ、そのワークロードを認証できることと、こちらの資料へどこまでアクセスさせるかは、別に決めることです。短い有効期間の認証情報も、認める操作や対象の範囲を考えなくてよくするものではありません。
AIエージェントへ仕事を任せるとき、まず見える形にしたいのは、どのソフトウェアが、どの資源へ、何を要求し、どの方針で通されたのかというつながりです。NHIの識別情報と操作の認可を分けておくと、「正規のプログラムだから任せてよい」という一段の判断を、確かめられるいくつかの役割へ分けられます。
参考資料
- Seokbin Yoon（윤석빈、Trust Connector代表・西江大学AI・SW大学院特任教授）「The Trust Layer for Open AI Infrastructure: Non-Human Identity (NHI) and Machine Economy Standards」、2026年8月、全38ページ。四つの問いはPDF p.20、ワークロード識別はp.24、操作前の認可はp.26。頁はPDF先頭から数えています。OCP Korea Tech Day公式資料一覧。講演音声・質疑は対象外です。
- SPIFFE「SPIFFE Concepts」。ワークロード、SPIFFE ID、SVID、Workload API、実行環境の隔離に関する前提。2026年10月8日確認。
- Scott Roseほか、NIST SP 800-207「Zero Trust Architecture」、2020年8月。認証・認可と最小権限は本文pp.4–7、PE・PA・PEPとFigure 2はpp.9–10。AIエージェント専用の規格として扱っていません。
- SPIFFE/SPIRE「SPIRE Federation Example」。異なるトラストドメインでのワークロード認証と、検証に使う情報の共有。導入部分を参照し、構築手順の実行検証はしていません。2026年10月8日確認。