Keycardでエージェントに身元を渡す方法｜社員のIDを貸さない

「社内のAIエージェントは、作った担当者のアカウントで動いている。担当者が異動したらどうなるのか、誰も答えられない」「エージェントが別のエージェントに仕事を回す構成を勧められたが、権限がどこまで引き継がれるのか分からない」——AIエージェントを業務に入れ始めた会社の情シスやセキュリティの担当者から、こうした声が聞かれます。エージェントを作るときに、社員のアカウントや、部署で共有しているAPIキーを貸して動かすのは、手早い方法として広く行われています。米国の Keycard は、こうした借りた資格、つまり共有のサービス用アカウントや期限の無い鍵を、エージェント専用の身元と短い期限の資格に置き換えることを掲げています。問われているのは、エージェントに何を許すかの前に、エージェントが誰の名前で動いているのかです。この記事では、Keycard を例に、1件の業務がエージェントからエージェントへ渡っていく様子を追いながら、身元の渡し方を整理します。

Keycardは何をする製品か

Keycard は、AIエージェントのための身元と利用の許可を扱う基盤です。公式サイトでは、各エージェントに固有の身元と、行動する権限と、方針の範囲内での資源の利用を与えるもの、と説明されています。エージェントが社内のシステムやMCPサーバー、外部のサービスを使おうとするたびに、その要求を方針に照らして判断し、許すなら作業に絞った短い期限の資格を発行します。公式サイトの例では、その資格の期限は1時間です。

判断のときには、要求してきたエージェントが何者で、どこで動いているかを確かめます。エージェントが人の依頼で動いている場合は、依頼した人の身元も要求に乗り、エージェントと人の両方の身元で方針が判断されると説明されています。拒否した要求には資格を出さず、拒否したことも記録に残ります。発行した資格は即座に取り消せ、取り消した後の要求は拒否されるとされています。

組み込み方は、アプリの中に部品として入れる、通り道に関所として置く、システムの隣に代理の仕組みとして置く、の3通りが案内されています。対象は自社で作るエージェントだけでなく、コーディングエージェントや、複数のエージェントで組むアプリにも広がっています（各提供の状況は後の節で扱います）。一言でいえば、エージェントに鍵を持たせず、使うたびに、その作業の分だけの鍵を貸し出す仕組みです。

作っている会社と、国内でまだ知られていない理由

Keycard は米国の企業で、公式ブログによれば2025年10月21日に、合わせて3,800万ドルの資金調達とともに製品を公表しました。主導した投資会社としてアンドリーセン・ホロウィッツなどの名前が挙がっています。その後、2025年11月にMCPサーバーの本番運用を支える会社を、2026年2月10日には証明書による身元の仕組みを手がけてきた Anchor.dev を買収したと公式ブログで発表しています。Anchor の買収は、コーディングエージェントの統制を広げるためと説明されています。さらに2026年2月24日にはエージェント型AIの公開の標準づくりを進める団体への参加を、2026年3月27日には端末の身元を確かめる仕組みを手がける会社との連携を発表しており、身元の仕組みを、個々のエージェントから端末や標準の側まで広げようとしていることがうかがえます。

日本でほとんど知られていない理由は、確かめた範囲で3つあります。1つ目は、公式サイトと料金のページが英語だけで、日本語の解説や販売の窓口が見当たらないことです。2つ目は、主な提供が2026年10月時点でも早期提供で、申し込んで使い始める段階にあることです。3つ目は、読み手が限られることです。製品の説明は開発者向けの部品や方針の書き方が中心で、AIエージェントを自社で作って本番で動かしている会社でないと、必要性が見えにくい製品です。

それでも取り上げる理由は、Keycard が扱う問題が、エージェントを使う会社なら規模に関係なく出てくるものだからです。製品を入れるかどうかとは別に、エージェントにどんな身元を渡し、権限をどう受け渡すかという考え方は、どの会社でも決めておく必要があります。以下では、Keycard の公式の説明を手がかりに、その考え方を追います。

エージェントは今、借りた資格で動いている

社内でエージェントを動かすとき、多くの場合、エージェントは誰かの資格を借りています。作った担当者のアカウント、部署で共有しているサービス用のアカウント、設定ファイルに書いた期限の無いAPIキーといったものです。Keycard の公式ブログも、置き換える対象として、共有のサービス用アカウントや固定の鍵のような借りた資格を挙げています。借りた資格は手早く用意でき、すぐ動くので、試しの段階ではほぼ必ずこの形になります。

借りた資格の問題は、資格が作業ではなく持ち主にひもづいていることです。Keycard が2026年10月8日に公開したブログは、コーディングエージェントが作業と無関係なファイルにあった別のサービスの鍵を見つけ、その鍵で本番のデータの置き場を消してしまった事例を取り上げています。鍵は設計どおりに働いただけで、その操作が今の作業に必要かどうかを、誰も判断していなかったという指摘です。

社員のIDを貸している場合も同じです。エージェントはその社員ができることを全部できてしまい、記録の上ではその社員が操作したことになります。エージェントの鍵の置き場や専用の身元を持たせる基本の考え方は、鍵の渡し方を扱った別の記事で整理しています。この記事では、そこから一歩進んで、エージェントが連なって動くときに、身元と権限をどう受け渡すかを中心に見ていきます。

1件の業務を、依頼した社員から社内システムまで追う

ここでは、次のような1件の業務を例にとります。営業企画の社員が、社内の窓口になるエージェントに「先月の大口の顧客の状況をまとめて」と頼みます。窓口のエージェントは、顧客の利用状況を調べる下請けのエージェントと、解約の兆しを調べる下請けのエージェントに仕事を回します。下請けのエージェントは、それぞれ社内のデータの置き場や顧客管理の仕組みを読みに行きます。Keycard の公式ブログが複数のエージェントで組むアプリの例として挙げている構成に近いものです。

この4つの段のそれぞれで、3つのことを確かめていきます。いま誰の身元で動いているか、その資格はいつ切れるか、そして途中で止めるにはどうするかです。借りた資格で動かしていると、この3つの答えがすべて「依頼した社員か、鍵を作った担当者と同じ」になってしまいます。段ごとに答えを分けられるかどうかが、身元を渡す設計の中心です。

段1　依頼した社員：エージェントは社員の代わりか、自分の名前か

最初の段で決めるのは、エージェントが「社員の代わりに」動くのか、「エージェント自身の名前で」動くのかです。社員の依頼で動く窓口のエージェントは、社員の代わりに動きます。一方、夜間に決まった時刻に動く集計のエージェントのように、誰の依頼でもなく動くものは、エージェント自身の名前で動きます。

Keycard の公式サイトでは、エージェントが人の代わりに動く場合、要求に人の身元も乗り、エージェントと人の両方に対して方針が判断されると説明されています。つまり、社員が見られないものは、社員の代わりに動くエージェントにも見せないし、社員が見られるものでも、エージェントに許していなければ見せない、という二重の絞り込みになります。

ここで人が決めておくのは、どのエージェントを「社員の代わり」として動かし、どのエージェントを「自分の名前」で動かすかの区分です。自分の名前で動くエージェントには、必ず持ち主となる人を決めます。持ち主のいないエージェントは、問題が起きたときに誰も止める判断ができず、異動や退職のたびに宙に浮きます。

段2　最初のエージェント：身元をどう確かめるか

エージェントに身元を渡すといっても、エージェントがパスワードを持つわけではありません。Keycard の公式ブログでは、エージェントは自分が動いている環境から身元を確立し、秘密の値をディスクに保存しないと説明されています。コーディングエージェント向けの提供では、端末とその利用者の身元を端末の信頼の仕組みから取り出し、端末や動いている環境の証明でエージェントの身元を確かめる、とされています。

この考え方の要点は、「鍵を持っているから本人」とはみなさないことです。借りた鍵は、コピーされれば誰でも使えます。動いている場所や環境まで含めて確かめれば、鍵が漏れても、別の場所からは使えない状態に近づけられます。外部の会社が作ったエージェントには、公開された身元の情報を使って身元を示させる方法も案内されています。

人が決めることは、どのエージェントを本番の業務に参加させてよいかの登録です。試しに作ったエージェントが、いつの間にか本番のデータに触れる経路に入っていた、という事態を防ぐため、本番に参加させるエージェントは、持ち主と用途を添えて登録してから身元を発行する決まりにします。登録の申請を受けて承認するのは、情シスかAI推進の責任者です。

段3　下請けのエージェントへ：権限は狭める方向にしか渡さない

エージェントが別のエージェントに仕事を回すとき、借りた資格で動かしていると、窓口が持つ資格がそのまま下請けに渡ります。下請けが本来必要としない権限まで持つことになり、連なるほど、どこで誰の権限が使われたかが見えなくなります。複数のエージェントで組む構成が勧められるほど、この膨らみ方は大きくなります。

Keycard の公式ブログでは、元の依頼ごとにセッションを作り、受け渡しのたびに、OAuth のトークン交換の標準（RFC 8693）を使って、権限を狭めた資格を発行すると説明されています。コーディングエージェント向けの説明でも、委任の連なりは親の権限を超えられないとされています。つまり、下請けが受け取るのは、窓口が持つ権限の一部で、しかも任された作業に必要な分だけです。

公式ブログの例では、顧客対応のチームが3つのエージェントを動かし、どのエージェントも常設の権限を持たず、セッションで許された範囲だけを受け取ります。方針で、顧客の状況を調べるエージェントにはデータの置き場の権限を渡さない、どのエージェントにも削除の操作はさせない、と決めています。人が決めるのは、どの受け渡しで何を渡してはいけないかという方針の中身です。仕組みは方針どおりに狭めますが、何を狭めるかは決めてくれません。

段4　社内システムに届くとき：本物の鍵をエージェントに見せない

最後の段は、エージェントが社内のデータの置き場や業務システムに実際に届くところです。社内の古いシステムの多くは、エージェントのための短い資格には対応しておらず、固定のIDとパスワードや期限の無い鍵でしか入れません。ここで固定の鍵をエージェントに渡してしまうと、それまでの段の工夫が無駄になります。

Keycard の公式ブログでは、こうした既存のシステムに対して、関所の仕組みが境界で、セッションにひもづいた中身の見えない資格を本物の資格に差し替えると説明されています。データベースやメッセージの仕組み、ウェブの通信など、複数の通信の方式に対応するとされています。本物の鍵は境界の内側にだけあり、エージェントは一度も本物を見ない、という作りです。

人が決めておくのは、どのシステムをこの関所の内側に入れるか、そして関所の仕組みを誰が管理するかです。関所には本物の鍵が集まるので、関所そのものの管理者の権限と記録を、ほかの仕組みより厳しく扱う必要があります。エージェントが動かすコードをどの環境に閉じ込めるかという隔離の設計は、サンドボックスを扱った別の記事に譲ります。

資格はいつ切れるか：作業が終われば消える

借りた資格の多くは、期限がありません。担当者が作った鍵は、担当者が異動しても、エージェントが使われなくなっても、誰かが消すまで有効なままです。期限の無い資格は、漏れたときの被害の期間も無期限になります。

Keycard の公式の説明では、受け渡しのたびに発行された資格はメモリの上だけに置かれ、セッションが終わると失効するとされています。コーディングエージェント向けの説明でも、道具を呼ぶたびの資格は作業・エージェント・利用者・環境に絞られ、ディスクに書かれず、セッションの終わりに消されると説明されています。つまり、資格の寿命が、人の在籍期間ではなく、1件の作業の長さに合わせられています。

ここで人が決めることは、期限の長さそのものより、長く動き続けるエージェントをどう扱うかです。常に動いている監視のエージェントや、何時間もかかる作業では、短い期限のままでは途中で切れます。期限を延ばす例外を誰が承認し、例外をいつ見直すかを決めておかないと、例外の資格が借りた資格と同じ長さで残ることになります。

途中で止めるには：取り消しと、人を呼び戻す線

エージェントが想定外の動きをしたとき、借りた資格で動かしていると、止める方法は資格そのものを無効にすることしかありません。しかしその資格は社員や他のエージェントと共有しているので、無効にすると関係のない業務まで止まります。その結果、止めるべきときに止める判断が遅れることになります。

Keycard の公式サイトでは、資格を即座に取り消すと、その後の要求は資格が使われるどこでも拒否されると説明されています。エージェントごと、セッションごとに資格が分かれているので、問題のエージェントだけを止め、ほかの業務は動かし続けられることになります。

もう1つの止め方は、危険な操作の手前で人を呼び戻すことです。コーディングエージェント向けの説明では、重要なデータへのアクセス、重要なシステムの変更、取り消せない操作のときに、上乗せの承認を求められるとされています。どの操作を上乗せの承認の対象にするか、承認するのは誰か、承認する人が不在のときはどうするかは、仕組みではなく業務の責任者が決めることです。

記録は「どのエージェントが・誰のために・何の権限で」

連なって動くエージェントで問題が起きたとき、後から知りたいのは、どのエージェントが、誰の依頼で、どの権限を使って、何をしたかです。借りた資格の記録には、資格の持ち主の名前しか残らず、この4つを分けて追えません。

Keycard の公式ブログでは、連なりの中のすべての行動が、どのエージェントが動いたか、誰の代わりか、どの権限か、成功か失敗かという身元の情報とともに記録されると説明されています。公式サイトでは、拒否も含めた許可の判断が記録され、標準の形式でセキュリティの監視の仕組みや保存先に書き出せるとされています。拒否した記録が残ることは、エージェントが何をしようとしていたかを知る手がかりになります。

人が決めるのは、記録を誰が見て、何をきっかけに調べるかです。記録を取るだけで誰も見なければ、問題に気づくのは被害が出た後になります。拒否が急に増えたエージェント、普段と違う時間に動いたエージェントを、週に1度は担当者が確かめる、といった見る側の決まりを、記録の仕組みと同時に作っておきます。

段ごとの「仕組みがやること」と「人が決めること」

ここまでの4つの段と、期限・取り消し・記録を、仕組みに任せられることと、人が決めておくことに分けて並べます。導入を検討するときに、右の列が埋まっているかを責任者が確かめる材料にしてください。

段・論点	仕組みがやること（Keycard の説明の範囲）	人が決めること
1 依頼した社員	依頼者とエージェントの両方の身元で方針を判断	社員の代わりか自分の名前かの区分、持ち主
2 最初のエージェント	動いている環境から身元を確かめ、秘密を保存しない	本番に参加させるエージェントの登録と承認
3 下請けへの受け渡し	受け渡しごとに権限を狭めた資格を発行	どの受け渡しで何を渡さないかの方針
4 社内システム	境界で短い資格を本物に差し替える	関所に入れるシステムと関所の管理者
期限	セッションの終わりに資格を失効	長く動くエージェントの例外と見直し
止め方	資格の即時の取り消し、危険な操作での承認の要求	上乗せの承認の対象と承認者、不在のとき
記録	誰の代わり・どの権限・結果を記録、拒否も残す	誰が見て、何をきっかけに調べるか

表の右の列は、どれも一度決めたら終わりではありません。エージェントを1つ足すたび、受け渡しの段を1つ増やすたびに、どの行を決め直すかを確かめる必要があります。表のとおり、仕組みが受け持つのは、資格の発行、期限切れ、取り消しの実行、記録といった、毎回同じように繰り返す作業です。どのエージェントに何を許すか、いつ取り消すか、どの例外を認めるかは、人が決めて方針に書くものです。方針を書く人と承認する人を分けておくと、1人の判断で権限が広がることを防げます。

既存の社員IDの仕組みとのつなぎ方

エージェントの身元を新しく作るといっても、社員の身元は既存の仕組みで管理されています。Keycard の公式ブログでは、Okta などすでに使っている身元の提供元と組み合わせて使う前提で、2026年6月23日に、Okta の「クロスアプリアクセス」の元になっている標準（ID-JAG）への対応を早期提供として発表しています。社員がふだんの身元でログインし、その身元を起点にエージェントへ権限を渡す流れを、既存の仕組みの延長で組めるようにする狙いです。

方針の書き方も、人が読める形で一か所にまとめる作りです。公式サイトでは、方針を専用の言語で書き、設定の管理の道具から適用すると説明されています。方針を設定のファイルとして管理するということは、方針の変更を、ほかの設定の変更と同じように、差分と承認の記録を残して扱えるということです。

ただ、方針がファイルになると、書ける人が限られる分、書く人に判断が集まりがちです。エージェントに何を許すかは業務の判断なので、方針の中身は業務の責任者が決め、書く人はそれを形にする、という分担にします。他社のエージェントとつなぐ規格の比較は、エージェント同士の連携の規格を扱った別の記事に譲ります。

提供状況と費用の増え方、確かめられなかったこと

2026年10月時点で、公式ブログの表記では、コーディングエージェント向けの提供（2026年3月19日発表）、複数のエージェントで組むアプリ向けの提供（2026年5月13日発表）、Okta との連携の対応は、いずれも早期提供です。公表時の発表では、企業の顧客がすでに本番で使っているとも書かれています。早期提供の機能は、提供条件や中身が変わる前提で、本番の業務に入れる範囲を決めてください。

費用は、公式の料金のページによれば、資格の発行、利用の要求の確認、資格の交換など、Keycard が要求に関わるたびに1件と数える従量の仕組みです。金額はここでは扱いませんが、増え方としては、エージェントの数よりも、受け渡しの段の数と道具を呼ぶ回数で費用が増えると考えておきます。下請けを細かく分けるほど、1件の依頼あたりの件数が増えます。

確かめられなかったこともあります。記録や身元の情報がどの国のどこに保存されるか、日本語での支援の有無、早期提供から正式な提供に移る時期は、2026年10月時点の公開の情報では確かめられませんでした。これらは契約の前に提供元に確かめる項目です。また、方針を誤って書けば、仕組みは誤った方針どおりに正しく動きます。仕組みが守るのは方針であって、方針の正しさではないことは、導入の前に関係者で共有しておきます。

エージェントに身元を渡す前に決める項目

Keycard を入れるかどうかにかかわらず、エージェントに身元を渡す前に決めておく項目を並べます。製品の検討に入る前に、この一覧が埋まるかを確かめてください。埋まらない項目があるうちは、エージェントを本番の業務に連ねて動かすのは早いと考えます。

• 社員や担当者のIDを、エージェントに貸していないか（今動いているものの棚卸し）
• エージェントごとに、社員の代わりに動くのか、自分の名前で動くのかを決めたか
• 自分の名前で動くエージェントに、持ち主となる人を決めたか
• 本番に参加させるエージェントの登録と、承認する人を決めたか
• 下請けのエージェントに渡してはいけない権限を、方針として書いたか
• 長く動くエージェントの期限の例外を、誰が承認し、いつ見直すか決めたか
• 取り消せない操作の前に、人の承認を求める範囲を決めたか
• 記録を誰が見て、何をきっかけに調べるかを決めたか

このうち、最初の棚卸しが最も手間がかかり、最も効き目があります。今どのエージェントが誰の資格で動いているかが分かれば、借りた資格を置き換える順番も決まります。社員のパソコンで動くAIの統制は別の記事に譲りますが、ここでは社内で作って動かしているエージェントから先に棚卸しするのが現実的です。

• エージェントを、作った担当者のアカウントのまま本番で動かし続ける
• 部署で共有している期限の無いAPIキーを、設定ファイルに書いてエージェントに持たせる
• 窓口のエージェントの資格を、そのまま下請けのエージェントに渡す
• 持ち主の決まっていないエージェントに、自分の名前で動く身元を発行する
• 期限の例外を認めたまま、見直す日を決めない
• 記録を取るだけで、拒否が増えても誰も確かめない

まとめ

AIエージェントを社員のIDや共有の鍵で動かすと、エージェントの操作は持ち主の操作として記録され、エージェントが連なるほど、借りた権限がそのまま次へ渡っていきます。Keycard は、エージェントごとの身元と作業に絞った短い期限の資格を発行し、受け渡しのたびに権限を狭め、即座に取り消せるようにする基盤で、2026年10月時点の主な提供は早期提供です。依頼した社員、最初のエージェント、下請け、社内システムの段ごとに、誰の身元で動くか、資格がいつ切れるか、どう止めるかを分けて決める。資格の発行・期限切れ・記録は仕組みに任せ、どのエージェントに何を許すか、取り消しと例外の承認は人が決める。社員のIDを貸すのをやめるところから始めてください。

• 製品の機能・提供状況・費用の仕組みは、Keycard の公式サイト、料金のページ、公式ブログを2026年10月20日に確かめた範囲に基づきます。早期提供の機能は内容や条件が変わることがあるため、利用前に最新の原文を確かめてください
• エージェントの権限と記録の扱いは、社内の情報管理の決まりや取引先との契約に関わります。実際の運用は情シスと法務の担当者と確かめてください

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