「本人であること」と「操作してよいこと」を、分けて考える。

「ログインできるようになった」ことと、「必要な操作だけを許可できるようになった」ことは、別の確認項目です。ツールをつなぐ場面でも、この区別を保つと要件を整理しやすくなります。

四つの問いで、許可を具体化する

アクセス制御を設計するとき、次の四つを一組として書き出す方法を提案します。

1. 誰が：利用者本人か、代理で動くサービスか。
2. 何に：どの文書、フォルダ、プロジェクトに対する操作か。
3. 何をするか：閲覧、編集、共有、削除のどれか。
4. いつまで：継続的な許可か、一度限りの実行か。

「編集者」のような役割名だけでは、対象の範囲や期限が曖昧になることがあります。役割と実際の操作を対応づけることで、確認する条件が見えてきます。

代理の処理では、利用者の境界を保つ

たとえば、エージェントが利用者の代わりに文書を検索する場合、サービス自体に接続権限があるだけでは十分な判断材料になりません。依頼した利用者が、その文書を閲覧できるかを合わせて扱う必要があります。

MCPの認可仕様を読む際も、接続に使う認可の仕組みと、業務上の許可条件を対応づけて整理すると、実装で確かめるべき点を見つけやすくなります。仕様を確認する

権限を外すときの動作まで確認する

追加できることだけでなく、不要になった権限が反映されることも検証の対象です。退職、担当変更、プロジェクト終了を例に、誰がどこで権限を外し、その結果をどう確認するかを決めておきます。

設計レビューでは、正常にアクセスできる例と、アクセスを拒否する例を対にして用意すると議論が進みます。「許可したはず」の裏側にある「拒否できるはず」も、実際の操作で確かめるためです。