Перейти к основному содержимому
ИДЕНТИФИКАЦИЯ ВЫЗЫВАЮЩЕГО В MCP

Узнайте, кто вызывает ваш MCP server

Ваш MCP server предоставляет инструменты AI clients, которые вы не контролируете. Proof of Actor показывает, что стоит за каждым вызовом, какие доказательства это подтверждают, и позволяет задавать политики по каждому инструменту.

Получить ранний доступИзучить, как это работает
Toshendra Sharma

Автор Toshendra SharmaОснователь и CEO, AgentCredia · Updated November 13, 2026

Ваши инструменты открыты для вызывающих, которых вы не видите

МCP server делает ваш продукт доступным для AI clients. Он предоставляет tools, resources и prompts, которые assistants и agents могут обнаруживать и вызывать, используя сообщения JSON-RPC 2.0 между hosts, clients и servers, как описано в спецификации Model Context Protocol. Именно поэтому команды и строят такие server: они помещают ваш product внутрь workflows, где AI agents уже работают.

Но это также означает, что ваш server получает вызовы от clients, которых вы не создавали и не можете наблюдать напрямую. Один и тот же tool может быть вызван developer, который тестирует локально, desktop assistant, действующим от имени signed-in person, autonomous agent, выполняющим длительную задачу ночью, или чем-то, что проверяет ваш server на уязвимости. Протокол сообщает, какой tool был вызван и с какими arguments. Сам по себе он не говорит, какой тип actor стоит за вызовом и насколько ему можно доверять.

Идентификация вызывающего в MCP server закрывает этот пробел. Proof of Actor добавляет к каждому вызову tool результат, подкрепленный evidence, чтобы ваш server мог принимать обоснованные решения о том, кому и что выдавать. Более подробно о проблеме читайте в разделе кто вызывает ваш MCP server, а в use case MCP servers показано, как команды применяют это на практике.

Примечание о терминах. "Caller identity" также имеет хорошо известное значение в cloud infrastructure. AWS STS GetCallerIdentity, например, возвращает сведения об IAM user или role, чьи credentials используются для вызова operation. Это отвечает на вопрос, какой cloud credential сделал вызов. Идентификация вызывающего в MCP server на этой странице отвечает на другой вопрос: какой тип actor, Human, Human + AI, Agent или Unknown, стоит за вызовом tool к вашему MCP server, и какие evidence подтверждают этот ответ.

Чем MCP callers отличаются

MCP callers отличаются от browser visitors и от traditional API clients в способах, важных для policy.

  • Они почти всегда автоматизированы. Вопрос здесь не столько "human or bot?", сколько "какой agent, как именно действует и с какими evidence?"
  • Они часто действуют от имени человека. Assistant может вызывать ваш tool потому, что пользователь попросил его об этом, или он может действовать автономно. Эти случаи заслуживают разного обращения.
  • Они описывают себя сами. В спецификации MCP lifecycle client отправляет объект clientInfo с name и version в своем запросе initialize. Это описание полезно как context, но это заявление, а не proof.
  • Tools сильно различаются по влиянию. Search tool и tool, который удаляет records, не должны иметь одну и ту же policy.

Хорошая идентификация вызывающего в MCP должна учитывать все четыре пункта.

Как Proof of Actor идентифицирует MCP callers

Signals from your server

Ваша интеграция MCP передает Proof of Actor доступный для каждого вызова context: заявленные client details, transport и request context, любые cryptographic request signatures, которые предоставляет client, например HTTP Message Signatures, определенные в RFC 9421, а также tool, который вызывается. Каждый signal помечается тем, откуда он получен.

Классификация с основанием

Proof of Actor возвращает один из четырех классов: Human, Human + AI, Agent или Unknown, вместе с основанием результата:

  • verified - когда криптографическая проверка, например request signature по опубликованному key, прошла успешно;
  • declared - когда это было заявлено client или вашим application, например name client в session;
  • inferred - когда результат основан на patterns в вызовах;
  • unknown - когда evidence не позволяет сделать определение.

Заявленное name client никогда не представляется как verification. Когда evidence мало, результатом становится Unknown, а не уверенное предположение, и ваш server точно знает, с чем работает.

Результат, который могут использовать ваши tools

Результат actor приходит вместе с вызовом tool, готовый для логики вашего server. В режиме observation вы его записываете. Когда будете готовы, ваши tool-level policies начинают действовать на его основе.

Что получает ваша команда: Detect, Understand, Route

Detect

Собирайте evidence вызывающего, доступное в каждом вызове tool, и не смешивайте verified, declared и inferred evidence.

Understand

Смотрите, какие clients вызывают какие tools, как часто, с какими evidence, и как это меняется со временем. Замечайте tools, которые привлекают в основном Unknown callers, clients, которые меняют behavior, и долю вызовов, содержащих verifiable identity.

Route

Пишите policies по каждому tool и по каждому уровню risk. Типичные варианты:

  • Low-impact tools вроде search или read-only lookups: разрешать широко, со стандартным rate limit.
  • Moderate-impact tools вроде создания drafts: разрешать verified и declared callers, ограничивать rate-limit для Unknown.
  • High-impact tools вроде удаления data, изменения settings или отправки messages от имени user: требовать вашу strongest authorization и добавлять confirmation или review, если caller Unknown или действует автономно.

Руководство защита sensitive actions без блокировки agents показывает, как проектировать эти уровни.

Доказательства identity, credentials и authorization - это разные вещи

Безопасность MCP работает лучше всего, когда три вопроса остаются раздельными:

  1. Identity evidence: какой тип client вызывает, и что это подтверждает? Это предоставляет Proof of Actor.
  2. Credentials: под каким account или token выполняется этот вызов? Это обеспечивает authentication вашего MCP server. Спецификация MCP authorization делает authorization необязательной и для HTTP-based transports опирается на OAuth 2.1, при этом MCP server действует как resource server, который проверяет access tokens.
  3. Authorization: может ли этот caller использовать этот tool, с этими arguments, для этого account? Это обеспечивает ваша permission model.

Признанный client автоматически не становится authorized. Действительная signature не показывает, что person за session делегировал authority именно на это действие. Подробнее читайте о delegated authority и agent authorization. Proof of Actor дает вашему server лучший context для первого вопроса, чтобы ваши ответы на второй и третий были более обоснованными.

Почему бы просто не доверять name client?

Потому что любой client может отправить любое name. Если считать заявленное name доказательством, это открывает путь imitation: враждебному client достаточно скопировать name популярного assistant. Proof of Actor записывает name как declared evidence, объединяет его с любым более сильным evidence и сообщает вам basis. После этого ваша policy может давать verified callers больше возможностей, чем callers, которые только заявили себя, и применять ваш fallback для Unknown, когда ни один вариант не подходит.

Начните в режиме observation

Установка Proof of Actor в вашем MCP server не меняет то, как отвечает какой-либо tool. Результаты записываются, чтобы вы могли видеть, кто вызывает ваши tools, насколько сильны evidence и где policies могли бы помочь. Когда будете уверены, включите policy на одном high-impact tool, наблюдайте за результатами, затем расширяйте. How It Works описывает полный flow, а Detection & Limitations объясняет, что может и чего не может установить каждый тип evidence.

Создано для команд, которые работают с MCP servers и APIs

Proof of Actor находится внутри вашего server рядом с существующими authentication, rate limiting и logging. Интеграции выполняются практично вместе с каждой founding team, чтобы настройка соответствовала вашему transport, hosting и design tools. Варианты использования MCP Servers и APIs показывают, как тот же подход применяется ко всем вашим tools и вашему API.

Вопросы, которые стоит задать по каждому открытому tool

Перед тем как писать policies на уровне tools, полезно пройтись по каждому tool, который открывает ваш MCP server, с помощью краткого checklist:

  • Что этот tool может изменить? Tools только для чтения и tools, которые изменяют data, отправляют messages или влияют на billing, заслуживают разного обращения.
  • Для кого он предназначен? Некоторые tools существуют для assistants, действующих от имени signed-in person; другие - для autonomous workflows. Ожидаемый caller определяет правильную policy.
  • Сколько будет стоить ошибка? Неверный search result стоит дешево. Неверное deletion - нет. Отнесите каждый tool к уровню risk.
  • Какие evidence должны быть обязательными? Решите, достаточно ли declared client, или tool должен требовать verified identity плюс вашу strongest authorization.
  • Что происходит при Unknown? Выберите явный fallback для каждого tool: allow, rate-limit, попросить user подтвердить или направить на review.
  • Как вы поймете, что это работает? Решите, какие outcomes вы будете отслеживать в режиме observation до того, как начнете что-то enforce.

Ответы на эти вопросы для каждого tool превращают идентификацию вызывающего в четкие, проверяемые rules и упрощают объяснение behavior вашего server тем clients, которые интегрируются с ним.

Присоединяйтесь к founding developer program

Proof of Actor находится в private beta. Отобранные founding development teams могут получить до 12 months of free access в рамках согласованных лимитов использования, с прямой поддержкой наших engineers, пока вы проектируете tool-level policies.

Если вы управляете MCP server и хотите знать, кто его вызывает, подайте заявку на ранний доступ. Расскажите нам о своем server, tools, которые вы открываете, и о вызовах, которые для вас важнее всего.

Источники

ДЛЯ РАЗРАБОТЧИКОВ

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
Насколько сильны evidence: verified, declared, inferred или unknown.
evidence
Signals, стоящие за result, чтобы ваша team видела, почему.

Начните в observation mode: записывайте results рядом с вашими logs и ничего не меняйте, пока не выберете policy. Прочитать guide по интеграции Node.js

Часто задаваемые вопросы

Зачем MCP server нужна идентификация вызывающего?

MCP servers предоставляют инструменты AI clients, которые действуют от имени людей или работают автономно. Понимание того, какой тип вызывающего стоит за вызовом инструмента, позволяет свободно разрешать инструменты с низким влиянием и требовать больше для инструментов с высоким влиянием.

Является ли имя client в сессии MCP проверкой?

Нет. Имя client - это заявление, сделанное самим client. Proof of Actor записывает его как declared evidence и не смешивает с криптографически verified identity.

Заменяет ли идентификация вызывающего авторизацию MCP?

Нет. Доказательства identity вызывающего, используемые учетные данные и то, что разрешено делать вызывающему, - это разные вопросы. Proof of Actor добавляет контекст к первому и оставляет authorization вашему server.

Будет ли Proof of Actor блокировать вызовы инструментов?

Только если так говорят ваши policies. Каждая интеграция начинается в режиме observation, а tool-level policies вы включаете, когда будете готовы.

Как я могу попробовать это?

Подайте заявку на ранний доступ. Отобранные founding developer teams могут получить до 12 months free в рамках согласованных лимитов использования, с практической помощью по интеграции.

Знайте, кто использует ваш app.

Private beta для небольшой группы founding developers.

Получить ранний доступПросмотреть цены

Предпочитаете сначала поговорить? Свяжитесь с основателями