跳转到主要内容
MCP 调用方识别

了解是谁在调用你的 MCP server

你的 MCP server 会向你无法控制的 AI 客户端暴露工具。Proof of Actor 会告诉你每次调用背后是什么、哪些证据支持这个结果，并让你按工具设置策略。

获取抢先访问了解其工作原理
Toshendra Sharma

作者 Toshendra Sharma创始人兼 CEO，AgentCredia · Updated November 13, 2026

你的工具向你看不见的调用方开放

Model Context Protocol specification 定义了 MCP server 让 AI 客户端可以使用你的产品。它暴露工具、资源和提示，让助手和 agent 能够发现并调用它们，在主机、客户端和 server 之间通过 JSON-RPC 2.0 messages 进行交互。这正是团队构建它的原因: 它把你的产品放进 AI agent 已经在其中工作的工作流里。

这也意味着你的 server 会接收到来自你没有构建、也无法直接观察的客户端的调用。单个工具可能被本地测试的开发者调用，被代表已登录用户工作的桌面助手调用，被整夜运行长任务的自主 agent 调用，或者被试探你的 server 弱点的某个程序调用。协议会告诉你调用了哪个工具，以及使用了什么参数。但它不会单独告诉你，调用背后是什么类型的 actor，或者你应该在多大程度上信任它。

MCP server 调用方识别弥补了这个缺口。Proof of Actor 会为每次工具调用添加一个有证据支撑的 actor 结果，因此你的 server 可以更有依据地决定谁能获得什么。若想更深入了解这个问题，请阅读 谁在调用你的 MCP server，并查看 MCP servers use case 了解团队如何应用它。

关于术语的一点说明。 "调用方身份" 在云基础设施中也有一个广为人知的含义。例如，AWS STS GetCallerIdentity 返回用于调用该操作的 IAM user 或 role 的详细信息。那回答的是哪个云凭据发起了调用。本页所说的 MCP server 调用方识别回答的是另一个问题: 调用你的 MCP server 的工具请求背后是什么类型的 actor, Human, Human + AI, Agent 还是 Unknown，以及什么证据支持这个答案。

MCP 调用方有何不同

MCP 调用方在与策略相关的方面不同于浏览器访客和传统 API 客户端。

  • 它们几乎总是自动化的。 问题不再是 "human 还是 bot?"，而是 "是哪个 agent，以什么方式行动，依据什么证据?"
  • 它们通常代表某个人行动。 某个助手可能是因为用户要求它才调用你的工具，也可能是自主行动。这两种情况应区别对待。
  • 它们会自我描述。 MCP lifecycle specification 规定客户端在其 initialize request 中发送一个包含名称和版本的 clientInfo 对象。这种声明很有用，但它只是声明，不是证明。
  • 工具的影响差异极大。 搜索工具和删除记录的工具不应共享同一策略。

好的 MCP 调用方识别必须同时尊重这四点。

Proof of Actor 如何识别 MCP 调用方

来自你的 server 的信号

你的 MCP 集成会把每次调用可用的上下文传给 Proof of Actor: 客户端声明的细节、传输和请求上下文、客户端提供的任何加密请求签名，例如 RFC 9421 中定义的 HTTP Message Signatures，以及正在被调用的工具。每个信号都会标明其来源。

带依据的分类

Proof of Actor 会返回 Human, Human + AI, Agent 或 Unknown 四类之一，并附上结果依据:

  • Verified: 当加密校验通过时，例如基于已发布密钥的请求签名验证通过;
  • Declared: 当客户端或你的应用声明了这一点时，例如会话中的客户端名称;
  • Inferred: 当结果基于调用模式推断得出时;
  • Unknown: 当证据不足以支持判断时。

客户端声明的名称绝不会被当作验证结果。证据不足时，结果会是 Unknown，而不是自信的猜测，你的 server 也能准确知道自己正在处理什么。

你的工具可以使用的结果

actor 结果会与工具调用一起返回，供你的 server 逻辑直接使用。在观察模式下，你会记录它。等你准备好后，工具级策略再基于它执行。

你的团队会得到什么: Detect, Understand, Route

Detect

捕获每次工具调用可用的调用方证据，并将 Verified, Declared 和 Inferred 证据区分开来。

Understand

查看哪些客户端调用了哪些工具、调用频率如何、使用了什么证据，以及这些情况如何随时间变化。识别主要吸引 Unknown 调用方的工具、行为发生变化的客户端，以及带有可验证身份的调用占比。

Route

按工具和风险等级编写策略。典型模式包括:

  • 低影响工具，例如搜索或只读查询: 广泛放行，并配合标准速率限制。
  • 中等影响工具，例如创建草稿: 允许 Verified 和 Declared 调用方，对 Unknown 做速率限制。
  • 高影响工具，例如删除数据、修改设置或代表用户发送消息: 要求最强授权，并在调用方为 Unknown 或自主运行时增加确认或复核。

关于 在不阻止 agent 的情况下保护敏感操作 的指南展示了如何设计这些层级。

身份证据、凭据和授权是彼此独立的

当以下三个问题保持区分时，MCP security 的效果最好:

  1. 身份依据: 谁在调用，以及有什么证据证明? Proof of Actor 提供这一点。
  2. 凭据: 这次调用使用的是哪个 account 或 token? 这是你的 MCP server 的 authentication 提供的。MCP authorization specification 将 authorization 设为可选，并且对于基于 HTTP 的 transport，它以 OAuth 2.1 为基础，由 MCP server 作为 resource server 来验证 access tokens。
  3. 授权: 这个调用方是否可以使用这个工具、这些参数以及这个 account? 这是你的 permission model 提供的。

被识别的客户端并不自动等同于被授权的客户端。有效签名并不能说明会话背后的人已针对这项特定操作授予权限。阅读更多关于 delegated authority 和 agent authorization 的内容。Proof of Actor 为第一个问题提供更好的上下文，从而让你对第二个和第三个问题的回答更有依据。

为什么不直接信任客户端名称?

因为任何客户端都可以发送任意名称。把声明的名称当作证明会招致仿冒: 恶意客户端只需要复制一个流行助手的名称即可。Proof of Actor 会把名称记录为 Declared evidence, 将其与现有的更强证据结合起来，并告诉你依据是什么。然后你的策略就可以给 Verified 调用方比仅自我声明的调用方更多权限，并在两者都不满足时使用 Unknown 兜底。

从观察模式开始

在你的 MCP server 中安装 Proof of Actor 不会改变任何工具的响应方式。结果会被记录下来，这样你就能看到谁在调用你的工具、证据有多强，以及哪些地方适合引入策略。当你有把握时，可以先在一个高影响工具上启用策略，观察结果，再逐步扩展。How It Works 介绍完整流程，而 Detection & Limitations 解释了每类证据可以建立什么、不能建立什么。

为运行 MCP servers 和 APIs 的团队打造

Proof of Actor 位于你的 server 内部，与你现有的 authentication、rate limiting 和 logging 并行工作。我们会与每个创始团队一起进行手把手集成，因此配置会贴合你的 transport、hosting 和工具设计。MCP Servers 和 APIs use cases 展示了同样的方法如何适用于你的工具和你的 API。

在你暴露的每个工具上都要问的问题

在编写工具级策略之前，最好用一份简短清单来检查你的 MCP server 暴露的每个工具:

  • 这个工具能改变什么? 只读工具和会修改数据、发送消息或影响计费的工具，应得到不同对待。
  • 它是给谁用的? 有些工具是供代表已登录用户行事的助手使用的; 另一些则面向自主工作流。预期调用方会影响正确的策略。
  • 一次错误会带来多大代价? 错误的搜索结果代价很小。错误删除则不是。把每个工具映射到相应的风险等级。
  • 应该要求什么证据? 决定声明的客户端是否足够，还是该工具需要 Verified identity 加上你最强的授权。
  • 遇到 Unknown 怎么办? 为每个工具选择明确的兜底: 放行、速率限制、要求用户确认，或转交复核。
  • 你如何知道它在起作用? 在你真正执行任何策略之前，先决定在观察模式下要关注哪些结果。

每个工具都回答一遍这些问题，就能把调用方识别变成清晰、可测试的规则，也更容易向集成它的客户端解释你 server 的行为。

加入创始开发者计划

Proof of Actor 目前处于 private beta。入选的创始开发团队可在约定的用量限制内获得最长 12 个月的免费访问，并在设计工具级策略时获得我们工程师的直接支持。

如果你在运行 MCP server，并想知道是谁在调用它，请 申请提前体验。告诉我们你的 server、你暴露的工具，以及你最关心的调用场景。

来源

面向开发者

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
结果背后的信号，让您的团队看清原因。

从观察模式开始: 将结果记录在日志旁边，在您选择 policy 之前不做任何更改。 阅读 Node.js 集成指南

常见问题

为什么 MCP server 需要调用方识别？

MCP servers 会向代表人类操作或自主运行的 AI 客户端暴露工具。知道工具调用背后是哪一类调用方，可以让你放行低影响工具，并对高影响工具要求更多条件。

MCP 会话中的客户端名称算验证吗？

不算。客户端名称是客户端做出的声明。Proof of Actor 会将其记录为 Declared evidence，并将其与经过加密验证的身份区分开来。

调用方识别会取代 MCP 授权吗？

不会。调用方身份证据、使用的凭据，以及调用方被允许执行什么，是三个不同的问题。Proof of Actor 只为第一个问题补充上下文，而把授权留给你的 server。

Proof of Actor 会拦截工具调用吗？

只有在你的策略这样设置时才会。每个集成都从观察模式开始，等你准备好后再启用工具级策略。

我该如何试用？

申请提前体验。入选的创始开发团队在约定的用量限制内可获得最长 12 个月的免费使用，并配有上手集成支持。

了解谁在使用您的 app。

面向少数 founding developers 的私有 beta。

获取抢先访问查看定价

想先聊聊？ 联系创始人