AIエージェントにビジネスデータへの安全なアクセスを提供する方法

アーキテクチャ：エージェントはクライアントであり、システムは権威である

形から始めてください。なぜなら、ほとんどのミスは形に関するミスだからです。人はエージェントに何かを依頼します。エージェントはどのツールを呼び出すかを決定します。すべての呼び出しはエージェントではなくビジネスシステムに属する権限レイヤーを通過し、その後にファイナンスやCRMなどのモジュールに到達します。エージェントはデータベースに触れず、データベースの資格情報を保持せず、利用できないツールを見ることもありません。

この図の背後にある原則は一文です：エージェントは代表する人物の権限で行動し、それ以上のことはしません。この記事の他のすべては、モデルが誤っているとき、読んだ文書に指示が含まれているとき、またはトークンが漏洩したときに、その文を圧力の下で真実にする方法です。

LLMアプリケーションのためのOWASP Top 10は、このアーキテクチャが防ぐ失敗を名付けています：過剰な権限であり、これは過剰な機能（仕事に必要なツールを超える）、過剰な権限（必要以上の下流アクセス）、過剰な自律性（高影響アクションの前に独立したチェックがない）に分解されます。その緩和策は権限レイヤーの仕様のように読まれます：ユーザーのコンテキストで実行し、ツールとその権限を最小限に抑え、モデルに依存するのではなく下流システムで承認を強制し、高影響アクションには人物の承認を必要とします。

5つのコントロールとそれぞれの位置

制御は新しいものではありません。これは、システムアクセスを持つ人物に既に適用している制御であり、その人物のために行動するクライアントに適用されます。表は各制御が何に答え、どこで強制され、欠如した場合の失敗がどのように見えるかを示しています。場所の列が重要です。プロンプトで強制される制御は提案に過ぎません。

本人確認：OAuthを介して個人として接続し、共有キーでは決して接続しない

モデルコンテキストプロトコルの認可仕様は、これについて明確です。リモートサーバーはOAuth 2.1リソースサーバーとして機能し、クライアントはPKCEを使用した標準の認可フローを通じてトークンを取得します。クライアントはリソースパラメータを使用してトークンがどのサーバーのものであるかを明示し、サーバーは各トークンが特定のサーバーのために発行されたものであることを検証し、他のものは拒否しなければなりません。仕様は、サーバーが発行していないトークンを受け入れて下流に転送するトークンパススルーを明示的に禁止しています。これは、監査証跡と信頼境界の両方を破壊するからです。

実際には、これが「一度サインイン、トークンを貼り付ける必要なし」という意味です。ユーザーはワークスペースのアドレスをエージェントに追加し、通常のサインインページに送信され、接続を承認し、エージェントは自分の名前を持ち、そのワークスペースに対してのみ機能するトークンを受け取ります。AnthropicのClaudeにおけるカスタムコネクタに関するガイダンスは、サーバーが要求するスコープを確認し、可能な限り制限し、信頼できるサーバーにのみ接続することです。代わりに、企業全体のAPIキーをエージェント設定に貼り付けるように求めるベンダーは、最初のコントロールをスキップし、他の4つをはるかに難しくしています。

スコープ：提供前にフィルタリングし、実行時に再確認する

エージェントは、サーバーにツールリストを要求することで、自分ができることを発見します。適切な設計は、個々の人に対してその質問に答えます：簿記担当者のエージェントが受け取るリストは、ディレクターのエージェントが受け取るリストとは異なり、どちらもその役割が見ることのできないモジュールのツールは含まれていません。これは、機能を最小限に抑えるためのOWASPのアドバイスを具体化したものであり、もう一つの利点があります：ツールが一度も表示されないモデルは、それを呼び出すように議論されることはありません。

リストをフィルタリングするだけでは不十分です。なぜなら、役割が変わり、セッションが持続し、クライアントがキャッシュするからです。各呼び出しが到着するたびに、同じチェックがその時点でのユーザーの権限に対して再実行されなければなりません。以下は、請求書を読み取ることはできるが、支払いを記録することはできない役割のためにプロトコルが定義する形のツールリストです。欠落しているツールがポイントです。

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      { "name": "searchInvoices",
        "description": "Search invoices by number, reference, contact, amount, status, date range.",
        "inputSchema": { "type": "object", "properties": { "query": { "type": "string" }, "outstanding_only": { "type": "boolean" } } },
        "annotations": { "readOnlyHint": true } },
      { "name": "getInvoice",
        "description": "Read one invoice in full: status, totals, dates, contact and lines.",
        "inputSchema": { "type": "object", "properties": { "invoice_id": { "type": "string" } }, "required": ["invoice_id"] },
        "annotations": { "readOnlyHint": true } }
    ]
  }
}

// recordPayment, sendInvoiceReminders and deleteInvoice exist in the system.
// They are not in this list because this person's role cannot use them.
// If the agent calls one anyway, the server answers with a permission error.

MCP仕様が定義する形のツール/リスト応答で、Sois会計モジュールのツール名が含まれています。仕様はまた、クライアントはサーバーが信頼できない限り、readOnlyHintのような注釈を信頼できないものとして扱わなければならないとも述べており、これはサーバーがルールを強制するものであり、注釈ではないというもう一つの理由です。

プロンプトインジェクション：データは応答することができる

エージェントに特有の脅威は、彼らが読むデータに指示が含まれている可能性があることです。顧客からのメールが、エージェントに外部アドレスにサプライヤーリストを転送するように指示する行で終わる場合や、すべての請求書を支払い済みとしてマークするように指示する文書があります。モデルは従うかもしれませんし、従わないかもしれませんし、どのプロンプトもそれを保証することはできません。これが、プロンプトインジェクションがOWASPリストの最初にある理由であり、AnthropicとOpenAIの両方がコネクタガイダンスで警告している理由です。

防御はアーキテクチャにあり、モデルではありません。ユーザーが使用できるツールのみが提供されるエージェントは、ユーザーが見ることのできないものを転送することはできません。請求書を支払い済みとしてマークする呼び出しは、システムによってその時点でのユーザーの権限に対してチェックされ、モデルが要求されたと信じていることに対してではありません。重要なツールは、クライアントが最初にユーザーに確認を求めるようにマークされています：ChatGPTは現在、書き込みアクションの前に会話で手動確認を必要とし、OpenAIのガイダンスはデータを変更するツールに対して承認を維持することを推奨しています。Claudeはツールごとに承認を求め、「常に許可」を信頼できるサーバーに予約することを勧めています。そして、ログはその試みを記録するため、ブロックされたインジェクションは後で可視化され、静かにはなりません。

予算とログ：エージェントの作業を人の作業と同様にレビュー可能にする

予算は二つの理由で重要です。明らかな理由はコストです：あいまいな結果を与えられたエージェントは、何かが止めるまでツールを呼び出し続け、OWASPは無制限の消費を独自のリスクとしてリストしています。より微妙な理由は、爆風半径です：統合ごとの上限は、妥協したり混乱したエージェントが人が気づく前にどれだけのことができるかを制限します。ユーザー自身のエージェントが推論を行う場合、AIコストは彼らにかかります。システム自身のエージェントがそれを行う場合、上限は統合ごとに設定され、アクションごとに可視化されるべきです。

ログは、これを約束から監査可能なものに変えます。各呼び出しは、エージェントが誰のために行動したか、どのツールを使用したか、入力、結果、時間を記録する必要があります。これは、システムが人々の行動を記録するのと同じ場所で行われます。テストは、財務責任者が先月エージェントが顧客のアカウントに対して何をしたかを、同僚に対してできるのと同じくらい簡単に見つけられるかどうかです。MCP仕様は、クライアントに監査のためのツール使用をログに記録するよう求めています。ビジネスシステムはそれに関してクライアントに依存すべきではありません。なぜなら、クライアントは記録システムではないからです。

任意のシステムに対して実行できるチェックリスト

これらをどのベンダーにも持っていってください、私たちを含めて。各項目は「はい」または「いいえ」であり、各項目には質問ではなくテストがあります。

1. エージェントはOAuthを通じて特定の人物として接続します, 会社全体のキーを貼り付けることなく。テスト: 外部MCPクライアントから接続し、サインインページが何を求めているかを確認してください。
2. ツールリストは役割によって異なります。 テスト: 制限されたユーザーとして接続し、管理者として接続して、エージェントが提供される内容を比較してください。
3. ツールが実行されると、チェックが繰り返されます。 テスト: 接続中のユーザーから権限を削除し、再度アクションを試みてください。
4. アクセスは閉じられた状態で失敗します。 テスト: 役割が持つべきでないツールを呼び出し、結果ではなく拒否されることを確認してください。
5. 支出は統合ごとに上限を設定できます。 アクションごとに確認できます。テスト: 小さな上限を設定し、それが適用されるのを見てください。
6. すべてのアクションは特定の人物に対して記録されます。入力と結果を含む、システムが他のすべてをログに記録します。テスト：実行したログを読み取ります。
7. 重要なツールは確認のためにマークされています。 そのため、クライアントは人に尋ねます。テスト：エージェントにお金を送るか、記録を削除するように依頼し、最初に確認されることを確認してください。

Soisはこのリストを通過させるために構築されたシステムの一つであり、記事の上部にある形状がその形です。ワークスペースはMCPサーバーであり、任意のMCPクライアントはワークスペースアドレスを追加し、OAuthを介して一度サインインすることで接続します。ツールは提供される前に役割によってフィルタリングされ、実行時に再度確認されます。アクセスは閉じられた状態で失敗します。支出は統合ごとに上限を設定できます。すべてのアクションはログに記録され、プラットフォーム上に構築されたネットワークは独自のデータベース、ストレージ、ドメイン、キーを持っています。それでもチェックリストを実行してください。チェックリストの価値は、誰の言葉も受け入れないことです。

人々が尋ねる質問

この文書は、記載されている製品が変更される際にレビューされます。次回の予定レビュー： 2026年12月4日.