IDENTIFICAÇÃO DE CHAMADOR MCP

Saiba quem está chamando seu MCP server

Seu MCP server expõe tools para clientes de IA que você não controla. O Proof of Actor informa o que está por trás de cada chamada, quais evidências a sustentam e permite que você defina políticas por tool.

Obter acesso antecipado Explorar como funciona

Por Toshendra SharmaFundador e CEO, AgentCredia · Updated November 13, 2026

Suas tools estão abertas para chamadores que você não pode ver

Um MCP server torna seu produto utilizável por clientes de IA. Ele expõe tools, resources e prompts que assistentes e agents podem descobrir e chamar, usando mensagens JSON-RPC 2.0 entre hosts, clients e servers, conforme descrito na especificação do Model Context Protocol. É exatamente por isso que equipes os constroem: para colocar seu produto dentro dos fluxos de trabalho onde os agents de IA já estão atuando.

Isso também significa que seu server recebe chamadas de clients que você não construiu e não consegue observar diretamente. Uma única tool pode ser invocada por um developer testando localmente, por um desktop assistant agindo em nome de uma pessoa autenticada, por um autonomous agent executando uma tarefa longa durante a noite ou por algo sondando seu server em busca de fraquezas. O protocolo informa qual tool foi chamada e com quais argumentos. Ele não informa, por si só, que tipo de ator está por trás da chamada nem o quanto você deve confiar nele.

A identificação de chamador de MCP server preenche essa lacuna. O Proof of Actor adiciona um resultado de ator baseado em evidências a cada chamada de tool, para que seu server possa tomar decisões informadas sobre quem recebe o quê. Para uma análise mais profunda do problema, leia quem está chamando seu MCP server e veja o caso de uso MCP servers para entender como as equipes o aplicam.

Uma observação sobre os termos. "Caller identity" também tem um significado conhecido na infraestrutura de nuvem. O AWS STS GetCallerIdentity, por exemplo, retorna detalhes sobre o usuário ou role do IAM cujas credenciais são usadas para chamar a operação. Isso responde qual credencial de nuvem fez uma chamada. A identificação de chamador de MCP server nesta página responde a uma pergunta diferente: que tipo de ator, Human, Human + AI, Agent ou Unknown, está por trás de uma chamada de tool para o seu MCP server, e quais evidências sustentam essa resposta.

O que torna os chamadores MCP diferentes

Os chamadores MCP diferem dos visitantes de navegador e dos clients tradicionais de API de maneiras que importam para políticas.

Eles são quase sempre automatizados. A pergunta é menos "humano ou bot?" e mais "qual agent, agindo de que forma, com quais evidências?"
Eles frequentemente agem em nome de uma pessoa. Um assistant pode estar chamando sua tool porque um user pediu, ou pode estar agindo de forma autônoma. Esses casos merecem tratamento diferente.
Eles se descrevem. A especificação de lifecycle do MCP faz o client enviar um objeto clientInfo com name e version em sua request initialize. Essa declaração é um contexto útil, mas é uma declaração, não uma prova.
As tools variam enormemente em impacto. Uma tool de busca e uma tool que exclui records não devem compartilhar uma única política.

Uma boa identificação de chamador MCP precisa respeitar os quatro pontos.

Como o Proof of Actor identifica chamadores MCP

Signals do seu server

Sua integração MCP passa ao Proof of Actor o contexto disponível para cada chamada: os detalhes declarados pelo client, o contexto de transporte e request, quaisquer assinaturas criptográficas de request que o client forneça, como HTTP Message Signatures definidas em RFC 9421, e a tool que está sendo chamada. Cada signal recebe um rótulo indicando sua origem.

Classificação com base

O Proof of Actor retorna uma das quatro classes, Human, Human + AI, Agent ou Unknown, junto com a base do resultado:

Verified quando uma verificação criptográfica, como uma signature de request contra uma key publicada, passou;
Declared quando o client ou sua aplicação informou isso, como o nome do client na sessão;
Inferred quando o resultado se baseia em padrões nas chamadas;
Unknown quando a evidência não sustenta uma determinação.

O nome declarado de um client nunca é apresentado como verificação. Quando a evidência é fraca, o resultado é Unknown em vez de um palpite confiante, e seu server sabe exatamente com o que está trabalhando.

Um resultado que suas tools podem usar

O resultado do ator chega junto da chamada da tool, pronto para a lógica do seu server. No modo de observação, você o registra. Quando estiver pronto, suas políticas no nível da tool agem sobre ele.

O que sua equipe recebe: Detect, Understand, Route

Detect

Capture a evidência do chamador disponível em cada chamada de tool e mantenha distintas as evidências verified, declared e inferred.

Understand

Veja quais clients chamam quais tools, com que frequência, com quais evidências e como isso muda ao longo do tempo. Identifique tools que atraem principalmente chamadores Unknown, clients que mudam de comportamento e a parcela de chamadas que carrega identidade verificável.

Route

Escreva políticas por tool e por nível de risco. Padrões típicos:

Tools de baixo impacto como busca ou consultas somente leitura: permita de forma ampla, com um rate limit padrão.
Tools de impacto moderado como criação de rascunhos: permita chamadores verified e declared, e aplique rate limit para Unknown.
Tools de alto impacto como excluir dados, alterar configurações ou enviar mensagens em nome de um user: exija sua autorização mais forte e adicione confirmação ou revisão quando o chamador for Unknown ou estiver agindo de forma autônoma.

O guia sobre proteger ações sensíveis sem bloquear agents mostra como desenhar esses níveis.

Evidência de identidade, credenciais e autorização são coisas separadas

A segurança MCP funciona melhor quando três perguntas permanecem distintas:

Evidência de identidade: que tipo de client está chamando e o que comprova isso? O Proof of Actor fornece isso.
Credenciais: com qual account ou token esta chamada é feita? A autenticação do seu MCP server fornece isso. A especificação de autorização do MCP torna a autorização opcional e, para transports baseados em HTTP, a fundamenta em OAuth 2.1, com o MCP server atuando como um resource server que valida access tokens.
Autorização: este chamador pode usar esta tool, com estes argumentos, para esta account? Seu modelo de permissões fornece isso.

Um client reconhecido não é automaticamente um client autorizado. Uma signature válida não mostra que a pessoa por trás da sessão delegou autoridade para esta ação específica. Leia mais sobre autoridade delegada e autorização de agent. O Proof of Actor dá ao seu server um contexto melhor para a primeira pergunta, para que suas respostas à segunda e à terceira sejam mais bem informadas.

Por que não confiar apenas no nome do client?

Porque qualquer client pode enviar qualquer nome. Tratar um nome declarado como prova convida à imitação: um client hostil só precisa copiar o nome de um assistant popular. O Proof of Actor registra o nome como evidência declarada, combina isso com qualquer evidência mais forte que exista e informa a base. Sua política pode então dar mais margem a chamadores verified do que a chamadores que apenas se declararam, e aplicar seu fallback Unknown quando nenhum dos dois se aplicar.

Comece em modo de observação

Instalar o Proof of Actor no seu MCP server não altera como nenhuma tool responde. Os resultados são registrados para que você veja quem chama suas tools, quão forte é a evidência e onde políticas ajudariam. Quando estiver confiante, habilite uma política em uma única tool de alto impacto, acompanhe os resultados e então expanda. O How It Works cobre o fluxo completo, e Detection & Limitations explica o que cada tipo de evidência pode e não pode estabelecer.

Construído para equipes que operam MCP servers e APIs

O Proof of Actor fica dentro do seu server ao lado da autenticação, do rate limiting e do logging já existentes. As integrações são entregues de forma prática com cada equipe fundadora, para que a configuração se ajuste ao seu transport, hosting e design de tools. Os casos de uso MCP Servers e APIs mostram como a mesma abordagem se aplica em todas as suas tools e na sua API.

Perguntas para fazer sobre cada tool que você expõe

Antes de escrever políticas no nível da tool, vale revisar cada tool exposta pelo seu MCP server com uma checklist curta:

O que esta tool pode mudar? Tools somente leitura e tools que modificam dados, enviam mensagens ou afetam billing merecem tratamentos diferentes.
Para quem ela serve? Algumas tools existem para assistants agindo em nome de uma pessoa autenticada; outras, para fluxos de trabalho autônomos. O chamador esperado molda a política correta.
Quanto custaria um erro? Um resultado de busca incorreto custa pouco. Uma exclusão incorreta, não. Mapeie cada tool para um nível de risco.
Que evidência deve ser exigida? Decida se um client declarado é suficiente ou se a tool deve exigir identidade verified mais sua autorização mais forte.
O que acontece em Unknown? Escolha um fallback explícito para cada tool: permitir, aplicar rate limit, pedir confirmação ao user ou encaminhar para revisão.
Como você saberá que está funcionando? Decida quais resultados você observará no modo de observação antes de impor qualquer regra.

Responder a isso uma vez por tool transforma a identificação de chamador em regras claras e testáveis, e facilita explicar o comportamento do seu server aos clients que se integram a ele.

Junte-se ao founding developer program

O Proof of Actor está em beta privada. Equipes fundadoras selecionadas podem receber até 12 months de acesso gratuito, dentro dos limites de uso acordados, com suporte direto de nossos engineers enquanto você projeta políticas no nível da tool.

Se você opera um MCP server e quer saber quem o está chamando, candidate-se ao acesso antecipado. Conte-nos sobre seu server, as tools que você expõe e as chamadas que mais importam para você.

Fontes

Model Context Protocol specification (2025-06-18), modelcontextprotocol.io.
MCP lifecycle: initialization and clientInfo, modelcontextprotocol.io.
MCP authorization, modelcontextprotocol.io.
RFC 9421: HTTP Message Signatures, IETF, February 2024.
AWS STS GetCallerIdentity API reference, Amazon Web Services.

PARA DESENVOLVEDORES

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 ou Unknown.
basis: Quão forte é a evidência: Verified, Declared, Inferred ou Unknown.
evidence: Os sinais por trás do resultado, para que sua equipe possa ver o motivo.

Comece no modo de observação: registre os resultados ao lado dos seus logs e não altere nada até escolher uma policy. Leia o guia de integração do Node.js

Perguntas frequentes

Por que um MCP server precisa de identificação de chamador?

MCP servers expõem tools para clientes de IA que agem em nome de pessoas ou operam de forma autônoma. Saber que tipo de chamador está por trás de uma chamada de tool permite liberar tools de baixo impacto com mais flexibilidade e exigir mais para as de alto impacto.

O nome do cliente em uma sessão MCP é uma verificação?

Não. O nome do cliente é uma declaração feita pelo próprio cliente. O Proof of Actor registra isso como evidência declarada e mantém essa informação distinta de identidade verificada criptograficamente.

A identificação de chamador substitui a autorização MCP?

Não. A evidência de identidade do chamador, a credencial usada e o que o chamador pode fazer são questões separadas. O Proof of Actor adiciona contexto à primeira e deixa a autorização com seu server.

O Proof of Actor bloqueia chamadas de tool?

Somente se suas políticas disserem que sim. Toda integração começa em modo de observação, e você habilita políticas no nível da tool quando estiver pronto.

Como posso testar?

Candidate-se ao acesso antecipado. Equipes fundadoras selecionadas podem receber até 12 meses gratuitos dentro dos limites de uso acordados, com suporte prático de integração.

Saiba quem está usando seu app.

Private beta para um pequeno grupo de founding developers.

Obter acesso antecipado Ver preços

Prefere falar primeiro? Fale com os fundadores