メインコンテンツにスキップ
MCP 呼び出し元識別

誰があなたの MCP server を呼び出しているのかを把握する

あなたの MCP server は、あなたが制御していない AI client に tools を公開します。Proof of Actor は、各 call の背後に何があるのか、どの evidence がそれを支えているのかを示し、tool ごとに policy を設定できるようにします。

早期アクセスを取得仕組みを探る
Toshendra Sharma

著 Toshendra SharmaFounder & CEO, AgentCredia · Updated November 13, 2026

あなたの tools は、見えない caller に開かれている

[an MCP server は、あなたの product を AI client から利用可能にします。hosts、clients、servers の間でやり取りされる JSON-RPC 2.0 messages を使って、assistant や agent が見つけて call できる tools、resources、prompts を公開します。これは Model Context Protocol specification に記されているとおりです。まさにそのために teams はこれらを構築します。AI agent がすでに作業している workflows の中に、あなたの product を組み込むからです。

それは同時に、あなたが構築しておらず、直接観測もできない client から server が call を受けることを意味します。1 つの tool は、ローカルで試している developer、サインイン済みの person のために動く desktop assistant、夜通し長い task を実行する autonomous agent、あるいは server の弱点を探る何かによって呼び出されるかもしれません。protocol は、どの tool がどの arguments で呼ばれたかは教えてくれます。しかし、それだけでは、その call の背後にどの kind of actor がいるのか、どれだけ信頼すべきかまでは教えてくれません。

MCP server caller identification は、その gap を埋めます。Proof of Actor は、各 tool call に evidence-backed な actor result を追加するため、server は誰に何を許すかを informed に判断できます。問題をより詳しく知りたい場合は、who is calling your MCP server を読み、teams がどのように適用しているかは MCP servers use case を参照してください。

用語についての注意. "Caller identity" は cloud infrastructure においてもよく知られた意味を持ちます。たとえば AWS STS の GetCallerIdentity は、operation を call する際に使われた IAM user または role についての詳細を返します。これは、どの cloud credential が call したかに答えます。このページの MCP server caller identification が答えるのは別の問いです。あなたの MCP server への tool call の背後にいる actor は Human なのか、Human + AI なのか、Agent なのか、それとも Unknown なのか、そしてその答えをどの evidence が支えているのか、という問いです。

MCP callers が異なる理由

MCP callers は、policy にとって重要な点で browser visitor や従来の API client とは異なります。

  • ほとんど常に automated です。 問いは「human か bot か」ではなく、「どの agent が、どのように振る舞い、どの evidence を持っているか」です。
  • 多くは person のために動きます。 assistant は user の依頼で tool を call しているのかもしれませんし、自律的に動いているのかもしれません。その 2 つは異なる扱いが必要です。
  • 自分自身を説明します。 MCP の lifecycle specification では、client が clientInfo object を name と version 付きで initialize request に送ります。その declaration は有用な context ですが、proof ではありません。
  • tools は impact が非常に大きく異なります。 search tool と records を削除する tool を、同じ policy で扱うべきではありません。

良い MCP caller identification は、この 4 つすべてを尊重しなければなりません。

Proof of Actor は MCP callers をどう識別するか

あなたの server からの signals

あなたの MCP integration は、各 call について利用可能な context を Proof of Actor に渡します。つまり、client の declared details、transport と request context、client が提供する cryptographic request signatures - たとえば RFC 9421 で定義された HTTP Message Signatures - そして呼び出される tool です。各 signal には、その出所がラベル付けされます。

basis 付きの classification

Proof of Actor は、Human、Human + AI、Agent、Unknown の 4 classes のいずれかを、結果の basis とともに返します。

  • verified は、公開された key に対する request signature のような cryptographic check が通った場合;
  • declared は、client またはあなたの application がそう述べた場合。たとえば session 内の client name です;
  • inferred は、結果が call の patterns に基づく場合;
  • unknown は、evidence が判断を支えない場合です。

declared された client name は、決して verification として提示されません。evidence が薄い場合、結果は自信のある推測ではなく Unknown になり、server は何を扱っているのかを正確に把握できます。

あなたの tools が使える結果

actor result は tool call と並んで届き、server の logic ですぐに使える状態になります。observation mode ではそれを記録します。準備ができたら、tool-level policy がそれに基づいて動作します。

チームが得るもの: Detect, Understand, Route

Detect

すべての tool call で利用可能な caller evidence を取得し、verified、declared、inferred の evidence を区別したまま保持します。

Understand

どの client がどの tool を、どのくらいの頻度で、どの evidence とともに call しているのかを把握し、それが時間とともにどう変化するかを見ます。主に Unknown caller を引き寄せる tool、behaviour を変える client、そして verification 可能な identity を伴う call の割合を把握できます。

Route

tool ごと、risk tier ごとに policy を記述します。一般的な pattern は次のとおりです。

  • Low-impact tools たとえば search や read-only lookups: 広く allow し、標準の rate limit を適用する。
  • Moderate-impact tools たとえば draft を作成するもの: verified と declared の caller を allow し、Unknown を rate-limit する。
  • High-impact tools たとえば data の削除、settings の変更、または user に代わって message を送信するもの: 最も強い authorization を要求し、caller が Unknown であるか autonomous に動いている場合は confirmation か review を追加する。

protecting sensitive actions without blocking agents の guide では、こうした tier の設計方法を示しています。

identity evidence, credentials, authorization は別物です

MCP security は、3 つの問いを区別したままにすると最もうまく機能します。

  1. identity evidence: どの kind of client が call しているのか、そしてそれを何が証明するのか。これを Proof of Actor が提供します。
  2. credentials: この call はどの account か token で行われているのか。これをあなたの MCP server の authentication が提供します。MCP の authorization specification では authorization は optional とされ、HTTP-based transports では OAuth 2.1 に基づき、MCP server は access tokens を検証する resource server として機能します。
  3. authorization: この caller は、この account に対して、この arguments で、この tool を使ってよいのか。これをあなたの permission model が提供します。

認識された client は、自動的に authorized であるわけではありません。有効な signature があっても、その session の背後にいる person が、この特定の action について authority を委任したことは示しません。delegated authority と agent authorization についてさらに読むことができます。Proof of Actor は 1 つ目の問いに対して、より良い context を server に与え、その結果として 2 つ目と 3 つ目への答えがより informed になります。

client name だけを信頼しない理由

どの client も、どんな name でも送れるからです。declared name を proof と見なすと、なりすましを招きます。悪意のある client は、人気の assistant の name をコピーするだけでよいからです。Proof of Actor はその name を declared evidence として記録し、存在するより強い evidence と組み合わせて basis を伝えます。すると policy は、verified caller に declared だけの caller よりも広い余地を与え、どちらにも当てはまらない場合は Unknown の fallback を適用できます。

observation mode から始める

あなたの MCP server に Proof of Actor を導入しても、どの tool の応答も変わりません。result は記録されるだけなので、どの caller が tool を呼んでいるのか、evidence がどれほど強いのか、どこで policy が役立つのかを確認できます。確信が持てたら、1 つの high-impact tool に policy を有効化し、結果を観察し、その後で拡張します。How It Works では全体の flow を説明し、Detection & Limitations では各 kind of evidence で何ができ、何ができないのかを説明しています。

MCP servers と APIs を運用する teams 向けに構築

Proof of Actor は、既存の authentication、rate limiting、logging と並んであなたの server の内側に入ります。integration は各 founding team に hands-on で提供されるため、setup は transport、hosting、tool design に適合します。MCP Servers と APIs の use case は、同じ approach があなたの tools と your API にどう適用されるかを示しています。

公開するすべての tool について尋ねるべきこと

tool-level policy を書く前に、あなたの MCP server が公開する各 tool を短い checklist で見直すと役立ちます。

  • この tool は何を変更できるのか? read-only tools と、data を変更したり、message を送ったり、billing に影響したりする tools は、異なる扱いが必要です。
  • 誰のためのものか? サインイン済みの person の代理で動く assistant のための tools もあれば、autonomous workflows のためのものもあります。想定される caller が、適切な policy を形作ります。
  • ミスのコストはどれくらいか? 誤った search result は小さな損失です。誤った deletion はそうではありません。各 tool を risk tier に割り当てます。
  • どの evidence を要求すべきか? declared された client で十分か、それとも tool に verified identity と最も強い authorization の両方が必要かを決めます。
  • Unknown のときはどうするか? 各 tool について明示的な fallback を選びます。allow する、rate-limit する、user に確認を求める、review に回す、のいずれかです。
  • うまく動いていることをどう確認するか? 何かを enforce する前に、observation mode で見る outcome を決めておきます。

tool ごとにこれらへ一度答えることで caller identification は明確で検証可能な rules になり、統合先の clients に server の behavior を説明しやすくなります。

founding developer program に参加する

Proof of Actor は private beta です。選定された founding development team には、合意された利用上限の範囲内で最大 12 months の free access が提供され、tool-level policy の設計にあたって当社 engineers から直接支援を受けられます。

MCP server を運用していて、誰がそれを呼び出しているのか知りたい場合は、apply for early access してください。あなたの server、公開している tools、最も重視している calls についてお知らせください。

Sources

開発者向け

What your code receives

Every interaction resolves to one result record. Your application reads the class and the basis and applies its own policy.

Result record
{
  "route": "GET /api/v1/catalog",
  "class": "agent",
  "basis": "verified",
  "evidence": [
    { "signal": "http_message_signature", "result": "valid", "keyid": "assistant.example" },
    { "signal": "client_declaration", "value": "assistant.example" }
  ],
  "observed_at": "2026-11-13T10:42:07Z"
}
class
Human, Human + AI, Agent, Unknown。
basis
証拠の強さです: Verified, Declared, Inferred, Unknown。
evidence
結果の背後にあるsignalsです。理由をチームが確認できます。

observation modeから始めます。結果をlogの横に記録し、policyを選ぶまで何も変更しません。 Node.js integration guideを読む

よくある質問

なぜ MCP server に caller identification が必要なのですか?

MCP server は、人物の代理として動くか、あるいは自律的に実行される AI client に tools を公開します。tool call の背後にどの種類の caller がいるのかを知れば、影響の小さい tool は自由に許可し、影響の大きいものにはより多くを求めることができます。

MCP session の client 名は verification ですか?

いいえ。client 名は client による declaration です。Proof of Actor はそれを declared evidence として記録し、暗号学的に verified された identity とは明確に区別します。

caller identification は MCP authorization の代わりになりますか?

いいえ。caller identity の evidence、使用される credential、そして caller が何を許可されているかは、それぞれ別の問いです。Proof of Actor は最初の問いに context を加え、authorization はあなたの server に委ねます。

Proof of Actor は tool call を block しますか?

policy がそう定めた場合のみです。すべての integration は observation mode から始まり、準備ができたら tool-level policy を有効化します。

どのように試せますか?

early access に申し込んでください。選定された founding developer team には、合意された利用上限の範囲内で最大 12 months free が提供され、実装支援も受けられます。

誰があなたの app を使っているかを把握します。

少数のfounding developer向けのprivate betaです。

早期アクセスを取得価格を見る

先に話しますか? 創業者に相談する