Permit.ioでAIの操作を許可する方法｜呼び出しごとの関所の置き方

「社員がAIエージェントに顧客管理やチケットの道具をつないで使い始めたが、何をどの権限で呼んでいるのか分からない」「一度ログインして許可したら、あとはエージェントが何でもできてしまうのではないか」——2026年に入り、情シスやAI導入の担当者からこうした声が急に増えました。MCP という共通の接続方式が広がり、エージェントが社内の道具を自分で呼ぶ場面が日常になったからです。問題はログインの確認が甘いことではなく、呼び出しの一回ごとに「この人の代わりに、この操作をしてよいか」を判定する場所がないことです。この記事では、Permit.io が2026年3月に発表した Permit MCP Gateway を例に、エージェントの操作を呼び出しごとに許可する関所の置き方を、手順に沿って整理します。

Permit.io は、アプリの「誰が何をしてよいか」を外に出す基盤

Permit.io は、イスラエルと米国を拠点にする会社で、アプリの中に書かれがちな認可の判定を、外の仕組みとして提供しています。役割による制御、属性による制御、関係による制御の三つの考え方で方針を書き、アプリは判定を問い合わせるだけで済む、という形です。2024年2月には、それまでの調達と合わせて総額1,400万ドルとなるシリーズAの調達を発表しています。

この会社が2026年3月17日に公式ブログで発表したのが、Permit MCP Gateway です。MCP の道具を提供する仕組み（MCPサーバー）の手前に置く関所で、公式は「MCP のための新しい信頼と執行の層」と説明しています。共同創業者で最高経営責任者は発表の中で、エージェントの問題を「誰も承認していないことをする自律的な仕組み」と表現しました。

発表は一度きりではなく、同社の公式ブログは2026年10月にも、人からエージェントへの委任の監査記録に何が要るか、エージェントを特権の利用者として扱うべき理由などの記事を続けて公開しています。製品と発信が直近まで動いていること、買収や提供終了の告知が見当たらないことは、導入を検討する前提として確認できます。

2026年3月の発表：Permit MCP Gateway が呼び出しごとに判定する

公式ドキュメントによると、Permit MCP Gateway は Cursor、Claude Desktop、Claude Code、VS Code などのエージェントと、MCPサーバーの間に入る代理の仕組みです。エージェントの側は接続先を元のサーバーから関所の宛先に変えるだけで、エージェントにもサーバーにも手を入れずに導入できると説明されています。

呼び出しのたびに行うことは、次のように説明されています。まず、ログインした人とエージェントの組み合わせに呼び出しを結び付けます。次に、エージェントに与えた信頼の段階、その人に許された上限、道具の危険度をそろえて判定します。許可された呼び出しだけが元のサーバーに届き、許可も拒否も、すべて記録に残ります。元のサーバーに入るための鍵は関所が持ち、エージェントの側には渡りません。

既定は「拒否」です。公式は、管理者が許可するまで、どの利用者もエージェントも道具を呼べないと書いています。方針を変えると、次の呼び出しから効きます。ここまでが関所の基本で、その上に人の承認、記録、置き場所の選択が載る構造です。以下の手順は、この構造に沿って関所を置いていく順番です。

ログイン時の一度の確認では足りない理由

社員がエージェントを道具につなぐとき、多くの場合は本人がログインし、接続を許可する画面で一度だけ同意します。この同意は「つないでよいか」の確認であって、その後の何百回もの呼び出しの一つ一つを確かめるものではありません。読むだけのつもりでつないだ道具でも、同じ接続で更新や削除の操作が呼べてしまうことがあります。

代理の権限が膨らむ原因や、本人の権限を貸すか専用の利用者を分けるかの比べ方は、別の記事で扱いました。ここで足したいのは、時間の軸です。つないだ時点では正しかった許可も、異動、案件の終了、エージェントの指示文の変更で、すぐに合わなくなります。呼び出しのたびに判定すれば、方針を直した瞬間から次の呼び出しに効きます。

もう一つは、エージェント自身の判断の揺れです。エージェントは与えられた目的のために、人が想定しなかった道具の組み合わせを選ぶことがあります。エージェントに「この操作はやめておく」と判断させるのではなく、判断の外側に関所を置くのが、この記事の前提です。エージェントの自制に頼らない、ということです。

関所の置き方の全体像：6つの手順

Permit MCP Gateway に限らず、呼び出しごとの関所を置くときは、道具の側の整理から始めて、運用の決めごとで終わる順番になります。製品の設定画面から入ると、道具の危険度や承認者が決まらないまま「とりあえず全部許可」で動き出しがちです。設定の前に、決めることを六つに分けておきます。

手順の2と3は、情シスだけでは決められません。道具を持つ業務部門と、権限の規程を持つ部門が同じ席にいる状態で決めます。以下、手順ごとに中身を見ていきます。

手順1：道具を「読む・書く・消す」の3段に分ける

公式ドキュメントでは、関所は道具ごとに危険度を「読み取り」「書き込み」「破壊的」の三段で扱います。この段分けが、後の上限や承認の基準になります。最初の作業は、つなぐMCPサーバーが持つ道具を全部書き出し、一つずつ三段のどれに当たるかを、業務の言葉で決めることです。

迷いやすいのは、名前は読み取りでも中身が重い道具です。たとえば顧客の一覧を出力する道具は、データを変えないので読み取りに見えますが、大量の個人情報を外に出せます。逆に、下書きを作るだけの書き込みは、取り消しが簡単です。危険度は「データを変えるか」だけでなく「取り消せるか」「社外に出るか」「量が多いか」で決めます。

段分けの表は、道具を持つ業務部門が下書きし、情シスと情報管理の担当者が確かめます。MCPサーバーの提供元が道具の説明を変えたり、新しい道具を足したりすると表は古くなるので、サーバーを更新するたびに段分けを見直す決まりも合わせて置きます。どのMCPサーバーを社内で使ってよいかの登録や審査は別の仕組みで行う前提とし、ここでは登録済みのサーバーの道具の段分けに絞ります。

手順2：方針を書く人と持つ人を決める

関所の方針は、「誰の代わりに」「どのエージェントが」「どの道具の」「どの操作を」してよいかの組み合わせです。Permit.io の基盤では、役割、属性、関係のどの考え方でも方針を書けます。たとえば「営業部の社員の代わりに動くエージェントは、顧客管理の読み取りはでき、更新は自分が担当する取引先に限る」といった書き方です。書ける表現が豊かなほど、誰が書いて誰が持つかの決めごとが重要になります。

公式ブログは、この関所が同社の本体と同じ方針の型と執行の考え方の上に作られていると説明しています。すでに Permit.io を自社のアプリの認可に使っている会社なら、アプリの利用者に与えている役割を、そのままエージェントの方針の土台に使えるということです。逆に初めて使う会社は、関所のためだけに役割の体系を作ることになるので、既存の権限の規程との対応表を先に作っておきます。

方針を書く人は、道具と業務を知っている人です。顧客管理なら営業企画、チケットの道具なら開発の責任者が下書きします。一方、方針の変更を承認し、記録を持つのは情シスや情報管理の担当です。書く人と承認する人を分けることで、業務部門が自分の都合で上限を広げることも、情シスが業務を知らずに狭めすぎることも防げます。

方針の変更は次の呼び出しから効くので、変更そのものが本番の操作です。変更の依頼、承認、反映の日時、理由を、方針の変更の記録として残します。エージェントやAIに方針の下書きをさせることはあっても、反映の承認は人が行う形にしておきます。方針を書く仕事を自動化しすぎると、関所が自分で自分の門を開ける形になるからです。

手順3：社員ごとの上限と、エージェントに渡す範囲を決める

公式ドキュメントによると、管理者は利用者ごとに信頼の段階の上限を決め、社員は接続の同意の画面で、その上限までの範囲からエージェントに渡す範囲を選びます。判定のときは、エージェントに与えた段階、その社員の上限、道具の危険度の三つをそろえて見ます。つまり、社員がうっかり広く同意しても、管理者の決めた上限は超えられない仕組みです。

上限を決めるときは、個人ごとではなく、部署と役割ごとの型を作るのが現実的です。営業担当は読み取りと自分の案件の書き込みまで、営業の管理職は加えて部下の案件の書き込みまで、破壊的な道具は原則どの型にも渡さない、といった形です。型に当てはまらない例外は、期限付きで認める決まりにしておくと、例外が恒久化するのを防げます。

同意の画面での本人確認は、公式ドキュメントでは単一ログイン（SSO）や OAuth、メールでのログインに対応すると説明されています。社内の単一ログインにつなげば、退職した社員はその時点で同意の画面に入れなくなります。社員に向けては、同意の画面で何を選べばよいかの短い説明を用意します。多くの社員にとって、エージェントに渡す範囲を選ぶのは初めての経験です。迷ったら狭いほうを選び、足りなければ後から広げるという原則を伝えるだけでも、上限いっぱいまで渡す同意は減ります。異動や退職のときに上限の型を付け替える手順は、人事の異動の連絡と結び付けておきます。

手順4：人の承認を挟む操作を選ぶ

公式ドキュメントでは、人の承認（ヒューマン・イン・ザ・ループ）は企業向けの区分の機能とされています。承認を求める条件は、道具ごとの切り替え、サーバー単位で全部の道具に求める設定、一定の危険度以上の道具に求める設定があり、どれか一つでも当てはまれば呼び出しは止まって承認を待ちます。承認の画面には、道具、サーバー、危険度、エージェントと利用者、実際に渡される引数が表示されると説明されています。

待ち時間の扱いもはっきり書かれています。既定の待ち時間は5分で、残り1分を切ると5分の延長ができます。時間切れは必ず却下で、承認扱いにはならないとされ、エージェントが接続を切れば依頼は取り消されます。却下には理由を付けられ、理由はエージェントに返ります。承認の依頼は管理画面のほか、メールや Slack にも通知できますが、Slack の通知には引数が含まれないとされています。管理者は依頼を一件ずつだけでなく、まとめて承認・却下することもできると説明されています。まとめての承認は便利ですが、引数を一件ずつ見ない運用につながりやすいので、破壊的な道具の依頼はまとめて承認しないという決まりを承認者の手順書に書いておきます。

承認を挟む操作は、取り消せない操作、社外に出る操作、金額や件数の大きい操作から選びます。ただし、承認を増やしすぎると承認者が中身を見ずに通すようになります。1日に承認者が見る件数の上限を決め、それを超えるなら段分けか上限の型を見直すのが現実的です。継続的な連携の仕組みのように、承認を飛ばす「信頼済みのエージェント」の一覧も設定できるので、その一覧に誰を載せるかも承認者と同じ会議で決めます。

• 承認者を情シスの一人に集中させ、休暇の日に業務が止まる
• Slack の通知だけを見て、引数を確かめずに承認する
• 時間切れの却下が続く道具を、承認なしに切り替えて解決する
• 信頼済みのエージェントの一覧に、試しに作った個人のエージェントを載せたままにする

手順5：記録に残す項目と保存期間を決める

公式ドキュメントによると、関所の記録には呼び出しごとに、人、エージェント、道具、MCPサーバー、時刻、許可か拒否か、その理由が残ります。承認については別に履歴があり、判断した管理者、判断の時刻、結果（承認・却下・時間切れ・取り消し）が残るとされています。「誰の代わりに、どのエージェントが、何をしたか」を後からたどれるのが、関所を置く最大の効用です。

記録の種類	残る項目（公式の説明）	社内で足して決めること
呼び出しの記録	人、エージェント、道具、サーバー、時刻、許可か拒否か、理由	保存期間、閲覧できる人、社内の監査の仕組みへの転送
承認の履歴	判断した管理者、判断の時刻、結果	承認の理由を書く決まり、却下の理由の型
方針の変更	公式の説明は関所の記録とは別	変更の依頼者、承認者、理由、反映日時
同意の記録	社員が同意の画面で選んだ範囲	異動・退職時の見直しの記録

保存期間は区分によって異なり、公式ドキュメントでは無償の区分の記録は7日間とされています。有償の区分の期間は公開資料からは分からないので、契約前に確かめます。監査や事故の調査では、半年から数年前の呼び出しをたどることがあるため、関所の記録を社内の記録の仕組みに定期的に移す前提で設計しておくと、製品の保存期間に縛られません。

手順6：関所が止まったときに、止めるか通すかを決める

関所は呼び出しの通り道にあるので、関所が止まれば、エージェントの呼び出しも止まります。ここで決めるのが、止まったときに呼び出しを全部止めるのか、一部を通すのかです。公式ドキュメントを読む限り、関所や判定の仕組みが止まったときの振る舞いは明記されていません。導入前に提供元へ書面で確かめるべき、最も重要な点の一つです。

社内の方針としては、業務ごとに決めます。顧客への請求や本番環境の変更につながる道具は、関所が止まったら止める。社内文書の読み取りのように止まると困るが危険度の低い道具は、エージェントを使わず人が直接操作する手順に切り替える。関所を迂回して直接つなぐ抜け道は作らないことが前提です。抜け道を一度作ると、障害のたびに使われ、関所の意味がなくなります。

• 拒否された呼び出しは、エージェントには決まった誤りの番号で返ると公式は説明している。エージェントがその誤りをどう扱い、利用者にどう伝えるかを試験で確かめる
• 提供元の環境で動かす場合の呼び出しの上限の値は公開されていない。上限を超えると呼び出しが断られるので、繁忙期の件数を伝えて確かめる
• 障害の連絡を受ける当番と、業務部門への周知の手順を、関所を入れる前に決める

抜け道を技術の面で塞ぐ手がかりもあります。公式ドキュメントでは、関所は元のサーバーへ呼び出しを転送するとき、関所を通ったことを示す署名付きの情報を添えると説明しています。元のサーバーの側でこの情報を確かめ、関所を通らない接続を受け付けない設定ができるかを、MCPサーバーの提供元や社内の開発担当と確かめておくと、関所の迂回を仕組みとして防げます。

止まったときの扱いを決めたら、年に一度は実際に関所を止める訓練をします。止めたときにエージェントの利用者がどんな表示を見て、誰に連絡すればよいか分かるかを確かめるだけでも、本番の障害時の混乱は大きく減ります。

何が社外に出るか：置き方の3つの型

関所をどこで動かすかで、社外に出るものが変わります。公式ドキュメントでは、提供元の環境で動かす型、関所と判定の仕組みを自社の網の中で動かす型、管理の仕組みまで含めて自社の中で動かす型の三つが説明されています。自社の網の中で動かす型や完全に自社で動かす型は、企業向けの導入として案内されています。

注意したいのは、提供元の環境で動かす型では、道具の呼び出しの中身、つまり引数と、元のサーバーからの応答が、提供元の管理する基盤を通ると明記されている点です。顧客管理の道具を呼べば、顧客の情報が関所を通ります。また、関所を自社の網の中で動かす型でも、方針と記録の管理は提供元のクラウドに残る構成が示されているので、記録に何が含まれるかを確かめます。

選び方の目安は、関所を通るデータの重さです。社内文書や公開情報の読み取りが中心なら、提供元の環境で動かす型で始めやすいでしょう。個人情報や取引の情報を扱う道具を通すなら、自社の網の中で動かす型を前提に見積もりを取り、記録の保管場所まで含めて情報管理の担当者が判断します。いずれの型でも、提供元が第三者の監査報告を受けていることは公式に示されていますが、関所に固有の扱いは個別に確かめます。

遅れと費用の増え方

呼び出しのたびに判定するので、関所を置くと一回ごとに判定の時間が足されます。同社は別の製品で判定の速さを公表していますが、Permit MCP Gateway の関所全体での遅れは、公開資料では示されていません。エージェントは一つの作業で何十回も道具を呼ぶことがあるため、一回の遅れが小さくても、作業全体では積み上がります。

確かめ方は、試験の段で、関所ありと関所なしで同じ作業をエージェントにさせ、作業全体の時間を比べることです。承認を挟む操作では、承認者の待ち時間が遅れの大半になるので、承認の件数と応答の時間も同時に測ります。遅れが業務に効くなら、承認の条件や段分けを見直します。

費用は、同社の料金の区分で決まり、人の承認や自社の網の中での運用は企業向けの区分とされています。費用が増える要因は、利用者の数、呼び出しの件数、承認の機能、記録の保存期間、置き方の型です。エージェントの利用が広がると呼び出しの件数は急に増えるので、見積もりでは件数がどう料金に効くかを確かめ、半年後の利用の広がりを置いて試算します。

やってはいけない関所の置き方

関所は置いただけで安全になるわけではありません。設定の仕方によっては、記録が残るぶん「管理している」という安心だけが生まれ、実際には何でも通っている、ということが起きます。既定の拒否から始めた関所が、問い合わせのたびに許可を足されて、半年後には全開になっているのが典型です。

• 社員から「動かない」と言われるたびに、上限の型を広げて解決する
• 破壊的な道具を、読み取りと同じ段に入れたまま運用する
• 方針の変更を、承認なしに業務部門の担当者が直接反映できるようにする
• 関所の記録を誰も読まず、保存期間が切れて消えるのを待つ

防ぐには、四半期に一度、上限の型と例外の一覧、拒否された呼び出しの傾向を見直します。拒否が多い道具は、方針が狭すぎるのか、エージェントが不要な呼び出しをしているのかを分けて考えます。許可を足す前に、エージェントの指示文や使い方を直せないかを先に確かめるのが、関所を全開にしないこつです。

やめ方：関所を外すとき、別の仕組みに移るとき

関所をやめるときに最も困るのは、元のサーバーに入るための鍵を関所が持っていることです。公式の説明では、利用者のエージェントは元のサーバーの鍵を持たず、関所が代わりに持ちます。関所を外すと、エージェントは元のサーバーに直接つなぎ直す必要があり、そのときに鍵をどう配るかを決め直すことになります。

やめる順番は、まず書き出しです。方針、上限の型、道具の段分け、呼び出しと承認の記録を、自社の手元に書き出して残します。方針は製品固有の形式で書かれていても、「誰の代わりに、どの道具の、どの操作を」という中身は別の仕組みに移せます。段分けと上限の型は自社の規程として持っておくと、製品を替えても設計をやり直さずに済みます。

次に、関所が持っていた鍵の取り消しです。関所が元のサーバーとやりとりするために発行した鍵を、元の道具の側で無効にします。最後に、社員の同意の記録を見て、つないだままのエージェントが残っていないかを確かめます。契約終了後に記録がいつ消えるかも、契約前に確かめておく項目です。

始める前に確かめる項目

ここまでの手順を、導入の判断の前に提供元と社内で確かめる項目としてまとめます。公開資料で分からない点が多いのは、関所が止まったときの振る舞い、全体の遅れ、有償の区分の記録の保存期間です。この三つは、書面の回答がないまま本番に入れないほうが安全です。

• つなぐMCPサーバーの道具を一覧にし、読む・書く・消すの段分けを業務部門と決めた
• 方針を書く人と、変更を承認する人を分けた
• 部署と役割ごとの上限の型を作り、例外は期限付きにした
• 人の承認を挟む操作と承認者、1日の承認件数の目安を決めた
• 信頼済みとして承認を飛ばすエージェントの一覧を、承認者の会議で決めた
• 記録の保存期間と、社内の記録の仕組みへの移し方を決めた
• 関所が止まったときの振る舞いを提供元に書面で確かめ、業務ごとに止めるか切り替えるかを決めた
• 置き方の型ごとに、呼び出しの中身と記録がどこを通るかを情報管理の担当者が確かめた
• 関所ありとなしで作業全体の時間を比べる試験を計画した
• やめるときの書き出しと鍵の取り消しの手順を書いた

このほか、エージェントの側で、拒否や時間切れの誤りが返ったときに利用者へ何を表示するかも確かめます。拒否の理由が利用者に伝わらないと、社員は関所を「よく分からない障害」と受け止め、抜け道を探し始めます。拒否の理由を短く返し、問い合わせ先を案内する形にしておくと、関所が社内で受け入れられやすくなります。

まとめ

Permit MCP Gateway は、社員のAIエージェントが社内の道具を呼ぶたびに、誰の代わりに、どのエージェントが、どの道具の、どの操作をするのかを判定し、記録を残す関所です。既定は拒否、管理者の決めた上限は社員の同意で超えられず、承認の時間切れは必ず却下という設計は、エージェントの自制に頼らない仕組みとして筋が通っています。ただ、関所の効き目を決めるのは製品ではなく、道具の段分け、方針を書く人と承認する人の分担、上限の型、承認を挟む操作の選び方、記録の持ち方、止まったときの扱いといった社内の決めごとです。関所が止まったときの振る舞い、全体の遅れ、記録の保存期間のように公開資料で分からない点は書面で確かめ、四半期ごとに許可の広がりを見直す。この順番で置けば、関所はエージェントの利用を止める壁ではなく、安心して広げるための土台になります。

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