Token Securityの棚卸し項目一覧｜持ち主不明の連携を残さない

「マーケが去年作った自動連携が、いまも辞めた担当者の権限で動いているらしい」「AIエージェントの一覧を出せと言われたが、どこを見ればそろうのか見当がつかない」——情報システム部門とマーケ部門のあいだで、AIの利用が広がった会社ほど耳にする声です。問題は、機械の身元が多いことではありません。持ち主が決まっていないことです。誰が作り、誰の資格で動き、誰が止められるのかが分からない身元は、数が少なくても事故の入口になります。この記事では、機械の身元とAIエージェントを洗い出して持ち主と権限を管理する Token Security を例に、すでに社内で動いている連携とエージェントを棚卸しするときに確かめる項目を、運用に乗せる順番で整理します。

Token Security は、社内で動く機械の身元とAIエージェントを洗い出す道具

Token Security は、人ではないもの、つまりサービスアカウント、APIキー、自動化の仕組み、AIエージェントといった機械の身元を対象にした、身元管理の製品です。2024年5月に700万ドルの資金とともに表舞台に出て、2025年1月には2,000万ドルの資金調達を発表しました。米国の報道では、機械の身元を狙う攻撃への対策を掲げる会社として紹介されています。

公式サイトの説明では、製品の役割は大きく三つに分かれます。社内・クラウド・その混在の環境からエージェントと機械の身元を見つけ出すこと、それぞれの身元が持つ権限と、本来の目的との差を理解すること、そして権限の絞り込みや持ち主の付け替え、使われなくなった身元の廃止といった管理を、作られてから役目を終えるまで続けることです。身元・人・秘密の鍵・権限・データを一つの関係図にまとめ、ある身元が乗っ取られた場合にどこまで影響が広がるかを示す、とも説明しています。

人の身元を管理する仕組みは、多くの会社ですでに整っています。入社で発行し、異動で変え、退職で止める流れが人事の手続きとつながっているからです。ところが機械の身元には、入社も退職もありません。作った人の都合で生まれ、作った人がいなくなっても残る。Token Security は、この抜け落ちた部分を埋める道具として位置づけられています。

2025〜2026年の動き：ライフサイクル管理、目的に沿った権限、RSACの最終候補

ここ1年あまりの発表を並べると、製品の重心が機械の身元全般から、AIエージェントへ移ってきたことが分かります。2025年5月に機械の身元の安全を扱うMCPサーバーを公開し、同年7月にはAIの利用を見つけ出す機能、11月にはAIエージェントの身元を作成から廃止まで管理する機能を発表しました。

2026年2月には、米国の大規模なセキュリティ会議であるRSACの新興企業コンテスト、イノベーション・サンドボックスで上位10社の最終候補に選ばれ、3月の会議で発表しています。同じ3月には、エージェントの権限をそのエージェントが何をするために作られたかに合わせて絞る、目的に沿った権限管理の機能を発表しました。報道によれば、その中身は、エージェントと持ち主と権限の継続的な発見、宣言された目的と実際の動きの把握、目的に合わせた最小限の権限の設定、目的の外にはみ出す動きの検知と制限、権限の膨らみや持ち主不在を防ぐ管理の五つです。

その後も、6月に身元管理の担当者向けにAIでアプリを組み立てる機能を出し、10月には企業向けの身元管理の支援会社との提携を発表するなど、更新は続いています。公式のニュース欄は2026年10月時点でも新しい発表が載っており、終了や新規受付停止の告知は見当たりませんでした。

問題：動いているエージェントと連携アカウントの持ち主が分からない

Token Security が出資し、クラウドセキュリティ・アライアンス（CSA）が実施した調査が、2026年4月に公表されています。2026年1月にIT・セキュリティの担当者418人から回答を得たもので、82％が、それまで把握していなかったAIエージェントを社内で見つけたと答えました。過去1年にエージェントに関わる事故を少なくとも1件経験した組織は65％で、その影響として最も多かったのはデータの露出でした。

目を引くのは、認識と実態のずれです。自社はエージェントを十分に見えていると答えた組織が68％あった一方で、エージェントを廃止する正式な手続きを持つ組織は21％にとどまり、決められた範囲を超えた動きを自動で止められると答えたのは11％でした。役目を終えたのに権限と鍵を持ったまま残るエージェントを、調査は「引退の負債」と呼んでいます。

この調査は製品を売る側の会社が費用を出したもので、回答数も大きくはありません。数字はそのまま自社に当てはめるより、傾向を示すものとして読むのが妥当です。それでも、見えていると思っているのに見つかる、作る手続きはあっても止める手続きがない、という形は、多くの会社で思い当たるはずです。

マーケ部門が作った連携が、棚卸しから漏れやすい理由

持ち主不明の身元が最も生まれやすいのは、情報システム部門の外で作られた連携です。マーケ部門は、問い合わせフォームと顧客管理、広告と分析、メール配信と営業の連絡を、業務の自動化ツールやAIエージェントでつなぐことが多くあります。そのとき多くの場合、担当者が自分のアカウントでログインして許可を出す形で接続されます。

この形の接続は、情報システム部門の台帳に載りません。台帳にあるのは人のアカウントであって、その人が許可した先で何が動いているかまでは記録されないからです。担当者が異動しても、許可はその人の名前で残り、連携は動き続けます。退職でアカウントを止めた瞬間に、誰も知らない連携が一斉に止まるという形で初めて発覚することもあります。

連携の仕組みそのものにも危うさがあります。Token Security の研究者は2026年2月、Zapier の機能を足がかりにアカウントの乗っ取りにつながりうる一連の弱点を報告しました。Zapier は修正を済ませており、悪用された形跡は見つかっていないと報じられています。ここで大事なのは特定のツールの良し悪しではなく、連携の道具は多くの鍵を一か所に集めるので、そこに何がつながっているかを把握しておく必要がある、という点です。

確認項目1：何が動いているか──一覧の範囲を決める

棚卸しの最初の項目は、何を一覧に載せるかの範囲です。Token Security は、クラウド、開発の自動化の流れ、社内のシステム、AIの提供元などとつながって身元を探すと説明しています。ただ、道具が見つけられるのは、道具をつないだ先にあるものだけです。マーケ部門が個別に契約した業務ツールの中の連携が範囲に入っているかは、導入前に必ず確かめます。

一覧に載せる対象は、少なくとも次の種類に分けて考えると漏れが減ります。

• サービスアカウント：システム同士をつなぐために作った、人ではない専用アカウント
• APIキーと接続用の鍵：業務ツールに発行し、別のツールに貼り付けた文字列
• 個人の許可による接続：担当者がログインして許可を出した、外部ツールからの接続
• AIエージェント：社内のAI基盤や業務ツールの中で作られ、他の仕組みを操作するもの
• MCPサーバーとAIの拡張：生成AIに社内の仕組みを読ませるために置いた接続口

道具の検出結果と、各部門への聞き取りは必ず突き合わせます。道具が見つけたのに誰も知らないものは持ち主不明の候補になり、部門が使っていると言うのに道具が見つけていないものは、道具の範囲の外にあることを示しています。後者は、接続の追加か、手作業の台帳で補うかを決めます。

確認項目2：誰の資格で動いているか──借りた権限か、専用の身元か

次に確かめるのは、それぞれの身元が誰の資格で動いているかです。専用のサービスアカウントで動いているのか、それとも特定の社員のアカウントの許可を借りて動いているのかで、その後の扱いが大きく変わります。

社員の許可を借りている連携は、その社員と同じ範囲に触れられます。マーケの責任者の資格でつないだAIエージェントなら、顧客管理の全件、広告の予算、配信の送信ボタンまで届く可能性があります。Token Security の最高技術責任者は、AIエージェントは、作った人の権限をまるごと引き継ぐべきではないという趣旨の発言をしており、製品もこの借りた権限を見つけて分けることを狙いにしています。

この項目で決めるのは、借りた権限のまま残すか、専用の身元に移すかです。すぐに移せないものもありますが、少なくとも「誰の名前で動いているか」が一覧に書かれていれば、その人の異動や退職のときに連携を確かめる手順を人事の手続きに足せます。名前が分からない状態だけは残さない、というのがこの項目の合格線です。

確認項目3：持ち主は誰か──作った人・承認した人・費用を持つ部門

持ち主という言葉は、実務では三つの役割に分かれます。作った人、使うことを承認した人、費用と結果に責任を持つ部門です。作った人だけを持ち主にすると、その人の異動とともに持ち主がいなくなります。一覧には三つを分けて書き、少なくとも承認者と部門は、個人ではなく役職でたどれるようにします。

Token Security は、エージェントごとに人の持ち主を決めておくことを製品の使い道の一つに挙げ、持ち主のいない身元を見つけ出すと説明しています。ただし、道具が示せるのは「作成した記録に残っている人」や「最近使った人」といった手がかりです。その人が本当に責任を持つべき人かどうかは、道具には判断できません。最終的な持ち主の割り当ては、部門長の確認を経て人が決めます。

持ち主が見つからない身元は、すぐに消すのではなく「持ち主不明」として別に扱います。一定の期間、関係しそうな部門に確認を回し、それでも名乗り出る人がいなければ、権限を絞ったうえで停止の候補にする。この流れを決めておけば、持ち主探しが担当者の善意に頼らずに済みます。

確認項目4：何に触れられるか──権限と、乗っ取られたときの広がり

4番目は、その身元が触れられる範囲です。ここでは、付与されている権限の一覧だけでなく、その身元が乗っ取られたら次にどこへ届くかまで見ます。Token Security は、身元・人・鍵・権限・データの関係を一つの図にまとめ、影響の広がりを示すと説明しています。

マーケの連携でよくあるのは、権限が業務の必要より広く取られている状態です。フォームの回答を顧客管理に登録するだけの連携が、顧客管理の全項目の読み書きと削除の権限を持っている。レポートを作るだけのエージェントが、広告の設定を変える権限まで持っている。接続の画面で最初に出てきた権限をそのまま許可した結果であることが多く、作った人も広さに気づいていません。

この項目では、権限を三つに分けて書き出すと判断しやすくなります。読むだけの権限、書き込む権限、そして削除・送信・支払いのように取り消しにくい操作の権限です。取り消しにくい操作の権限を持つ身元は、利用頻度に関係なく優先して確かめます。

確認項目5：目的と実際の動きは合っているか──判断はAIに任せない

5番目は、身元が本来の目的どおりに動いているかです。Token Security は、エージェントについて宣言された目的と、実際に観測された動きを把握し、目的の外にはみ出す動きを検知して制限すると説明しています。目的の決め方の詳細や、どの程度自動で止めるかの設定は公開情報からは確認できなかったため、導入前の確認事項になります。

ここで注意したいのは、目的そのものを書くのは人だという点です。「月次のレポートを作る」と目的を書いたエージェントが、顧客の一覧を外部に送ろうとすれば、それは明らかに目的の外です。しかし、目的の書き方があいまいなら、検知の線もあいまいになります。目的は、触れるデータ・行う操作・出力の届け先の三点で書くと、はみ出しが判定しやすくなります。

また、はみ出しを検知したあとの判断をAIや道具に任せきりにしない設計も必要です。業務の繁忙期にいつもと違う量のデータを読むのは、正当な場合もあります。自動で止めるのは取り消しにくい操作に限り、それ以外は持ち主に確認を送って人が判断する、と線を引いておくと、正当な業務を止めすぎずに済みます。

権限の削り方：いきなり消さず、段階で狭める

棚卸しで広すぎる権限が見つかったとき、最初にやりがちなのが一斉の削除です。しかし、持ち主の分からない連携には、実は毎月の締めの処理や、年に一度のキャンペーンで使うものが混じっています。消してから困る人が名乗り出るという形は、業務を止めるうえに、次の棚卸しへの協力も得にくくします。権限は、次の順で段階的に狭めます。

Token Security は、危険度や状況に応じて修正の手順を起動する機能を持つと説明しています。こうした自動の修正も、最初は提案を出させて人が承認する形で使い、削った結果の確認が回るようになってから、自動にする範囲を少しずつ広げるのが安全です。

止める担当と止め方：持ち主不明の身元を見つけたとき

権限を削るより先に決めておくべきなのが、止める担当と手順です。事故の疑いがある身元を見つけたとき、誰が止める判断をし、誰が実際に止め、止めたことを誰に知らせるのか。この三つが決まっていないと、見つけても誰も手を出せないまま時間が過ぎます。

止め方には段階があります。鍵の無効化、接続の許可の取り消し、エージェント自体の停止、そして関連する人のアカウントの一時停止です。影響の小さい順に手順を書いておけば、夜間や休日でも当番が迷わずに動けます。持ち主不明の身元は、止めたことで困る人が出るかもしれないので、止めた事実と戻し方を、関係しそうな部門にすぐ知らせるところまでを手順に含めます。

棚卸しの現場で見かける、避けたい対応をまとめておきます。

• 持ち主の分からない連携を、確認なしに一斉に削除する
• 退職者のアカウントを止めたあと、その名前で動いていた連携を確かめない
• 道具が「持ち主候補」と示した人を、本人の確認なしに持ち主として登録する
• 止める担当を情報システム部門だけにし、夜間に連絡がつかない状態にする
• 検知の通知を共有の受信箱に流すだけで、誰が読むかを決めない

止める権限を持つ人を絞りすぎるのも問題です。情報システム部門の担当者が1人しか止められない状態では、休暇中に何も手を打てません。止める権限は複数人に、止める判断の基準は文書に、と分けておくのが現実的です。

情シスとマーケの分担：誰が何を持つか

機械の身元の管理は、情報システム部門だけでは回りません。どの連携が業務に必要か、どの権限が使われているかを知っているのは、作って使っている部門だからです。一方で、全社の一覧を持ち、止める判断の基準を決めるのは情報システム部門です。一覧と基準は情シス、中身の説明と持ち主の責任は事業部門という分け方が基本になります。

作業	情報システム部門	マーケ部門	Token Security などの道具
一覧の作成	対象の範囲を決め、道具をつなぐ	道具の外にある連携を申告する	接続先から身元を見つけ出す
持ち主の決定	持ち主不明の扱いと期限を決める	作った人・承認者・責任部門を答える	作成の記録などから候補を示す
権限の見直し	削る手順と承認の流れを決める	業務に必要な範囲を説明する	使われていない権限を示す
停止	止める判断と実施、連絡	止めたときの業務影響を答える	はみ出した動きを検知・通知する
新しい連携	登録の様式と審査の基準を持つ	作る前に目的と権限を申請する	未登録の新しい身元を見つける

表の右端の列は、道具が人の代わりに決めることではありません。道具は候補と証拠を出し、決めるのは左の二つの列です。この分担を文書にしてから道具を入れると、道具が出す大量の指摘を誰が受け止めるかで揉めずに済みます。

Token Security を入れる前に確かめること：接続の権限と外に出るもの

機械の身元を見つける道具は、その性質上、多くの仕組みに広く接続します。つまり、道具そのものが最も多くの鍵に近い場所に置かれることになります。導入前には、道具に渡す接続の権限が読み取りだけなのか、権限の変更や停止のような書き込みも含むのかを確かめます。公開情報からは接続の方式の詳細は確認できなかったため、提供元への確認が必要です。

外に出るものも整理します。身元の一覧、権限の設定、利用の記録は、それ自体が攻撃者にとって価値のある地図です。これらがどこに保存され、どの国のどの事業者が扱うか、契約終了時にどう消されるかを、契約前に文書で受け取ります。

もう一つ、Token Security は自社の機能を生成AIの画面から呼び出せるMCPサーバーを提供しており、公式サイトでは Claude、ChatGPT、Gemini、Cursor から使えると説明しています。便利な一方で、身元の一覧を生成AIに読ませる経路を新しく作ることでもあります。使うなら、誰の生成AIのアカウントから、どの範囲の情報を読めるかを、ほかの連携と同じ基準で一覧に載せます。

費用と規模：既存のID管理や手作業で足りる範囲

確認できた範囲では、Token Security の公式サイトに公開の価格表は見当たらず、費用は問い合わせになります。この種の製品は、管理する身元の数や接続する環境の数で費用が増えることが多いため、見積もりの前に自社の身元の数をおおまかに把握しておくと比較がしやすくなります。公式サイトは、機械とAIの身元が人の身元の50倍に上ると書いていますが、根拠は示されておらず、自社で数えるのが確実です。

手作業で足りるかどうかの目安は、連携の数と変化の速さです。全社の連携が数十件で、新しく作る頻度も月に数件なら、表計算の台帳と四半期ごとの聞き取りで十分回ります。すでに使っている人のID管理の仕組みにも、アプリの許可の一覧などを確認できる機能がある場合が多く、まず既存の仕組みでどこまで見えるかを確かめるのが先です。

専用の道具を検討すべきなのは、生成AIの利用が部門ごとに広がり、エージェントが毎週のように増える段階です。この段階では、手作業の台帳は作った翌月には古くなります。ただし、道具を入れても持ち主を決める作業と止める手順の整備はなくなりません。道具の費用に加えて、指摘を処理する人の時間を見込んで判断します。

棚卸しを一度で終わらせない：運用に乗せる仕組み

棚卸しは、一度やって終わりにすると半年で元に戻ります。新しい連携は毎月生まれ、人は毎月異動するからです。定着させるには、作るとき、人が動くとき、定期の三つの入口で一覧を更新する仕組みが要ります。

作るときの入口は、新しい連携やエージェントの申請です。目的、触れるデータ、使う権限、持ち主の三点セットを書いてもらい、情報システム部門が審査します。人が動くときの入口は、異動と退職の手続きです。人事の手続きに「この人の名前で動いている連携の確認」を一行足すだけで、持ち主不明の多くは防げます。定期の入口は、四半期ごとの見直しで、道具の検出結果と一覧の差を確かめます。

• 申請の様式は、マーケ部門が5分で書ける量に抑えます。重すぎる様式は、申請を避けた個人の接続を増やします
• 四半期の見直しでは、件数よりも「持ち主不明」「取り消しにくい権限を持つ身元」の数の推移を見ます
• 廃止の手続きを、作る手続きと同じ重さで文書にします。調査で正式な廃止手続きを持つ組織が約2割だったことを思い出してください

最後に、棚卸しの結果を経営層に報告する形を決めておくと、取り組みが続きます。持ち主不明の数が減ったことは、事故が起きなかったことより説明しやすい成果です。数字で示せる成果があると、次の予算と人員の判断につながります。

棚卸しで埋める確認項目の一覧

ここまでの項目を、一覧の列として使える形にまとめます。Token Security のような道具を入れる場合も、手作業の台帳で始める場合も、この列が埋まらない身元は「未確認」として残すのが原則です。

• 種類：サービスアカウント／APIキー／個人の許可による接続／AIエージェント／MCPサーバー
• 所在：どのツール・どの環境にあり、どこへつながっているか
• 資格：専用の身元か、誰の個人アカウントの許可を借りているか
• 持ち主：作った人・承認した人・費用と結果に責任を持つ部門（役職でたどれる形）
• 目的：触れるデータ・行う操作・出力の届け先
• 権限：読む／書く／削除・送信・支払いなど取り消しにくい操作
• 鍵：期限の有無、最後に入れ替えた日、入れ替えの担当
• 停止：止める担当、止める手順、止めたときの連絡先
• 最終確認日：誰がいつ確かめたか

一覧は、全件を一度に埋めようとしないことが大切です。取り消しにくい権限を持つものと、持ち主が分からないものから埋めていけば、限られた時間でも危険の大きい順に手が打てます。道具が出した結果は、この列のどこを埋める材料になるかで評価すると、導入効果も測りやすくなります。

まとめ

Token Security は、サービスアカウントやAPIキー、AIエージェントといった機械の身元を洗い出し、持ち主と権限と目的をひもづけて管理する製品です。2025年から2026年にかけて、エージェントの身元の管理、目的に沿った権限の機能を相次いで加え、RSACのイノベーション・サンドボックスの最終候補にも選ばれました。けれども、道具が示せるのは候補と証拠までです。マーケ部門が個人の資格でつないだ連携を一覧に載せ、誰の資格で動き、誰が持ち主で、どこまで触れ、目的に沿っているかを確かめ、取り消しにくい権限から段階的に削る。止める担当と手順を先に決め、作るとき・人が動くとき・定期の三つの入口で一覧を更新する。持ち主を決めること、権限を削る判断、止める判断は人が持ち、道具には判断させない。この線を引いてから導入するかどうかを決めるのが、遠回りに見えて確実な順番です。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。