Skip to main content
MCP CALLER IDENTIFICATION

Know who is calling your MCP server

Your MCP server exposes tools to AI clients you do not control. Proof of Actor tells you what is behind each call, what evidence supports it, and lets you set policies per tool.

Get Early AccessExplore How It Works
Toshendra Sharma

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

Your tools are open to callers you cannot see

An MCP server makes your product usable by AI clients. It exposes tools, resources and prompts that assistants and agents can discover and call, using JSON-RPC 2.0 messages between hosts, clients and servers as described in the Model Context Protocol specification. That is exactly why teams build them: they put your product inside the workflows where AI agents are already working.

It also means your server receives calls from clients you did not build and cannot observe directly. A single tool might be invoked by a developer testing locally, by a desktop assistant acting for a signed-in person, by an autonomous agent running a long task overnight, or by something probing your server for weaknesses. The protocol tells you what tool was called and with what arguments. It does not, on its own, tell you what kind of actor is behind the call or how much you should trust it.

MCP server caller identification fills that gap. Proof of Actor adds an evidence-backed actor result to each tool call, so your server can make informed decisions about who gets what. For a deeper look at the problem, read who is calling your MCP server, and see the MCP servers use case for how teams apply it.

A note on terms. "Caller identity" also has a well-known meaning in cloud infrastructure. AWS STS GetCallerIdentity, for example, returns details about the IAM user or role whose credentials are used to call the operation. That answers which cloud credential made a call. MCP server caller identification on this page answers a different question: what kind of actor, Human, Human + AI, Agent or Unknown, is behind a tool call to your MCP server, and what evidence supports that answer.

What makes MCP callers different

MCP callers differ from browser visitors and from traditional API clients in ways that matter for policy.

  • They are almost always automated. The question is less "human or bot?" and more "which agent, acting how, with what evidence?"
  • They often act for a person. An assistant may be calling your tool because a user asked it to, or it may be acting autonomously. Those cases deserve different treatment.
  • They describe themselves. The MCP lifecycle specification has the client send a clientInfo object with a name and version in its initialize request. That declaration is useful context, but it is a declaration, not proof.
  • Tools vary enormously in impact. A search tool and a tool that deletes records should not share one policy.

Good MCP caller identification has to respect all four.

How Proof of Actor identifies MCP callers

Signals from your server

Your MCP integration passes Proof of Actor the context available for each call: the client's declared details, transport and request context, any cryptographic request signatures the client provides, such as HTTP Message Signatures defined in RFC 9421, and the tool being called. Each signal is labelled with where it came from.

Classification with a basis

Proof of Actor returns one of four classes, Human, Human + AI, Agent or Unknown, together with the basis for the result:

  • verified when a cryptographic check, such as a request signature against a published key, passed;
  • declared when the client or your application stated it, such as the client name in the session;
  • inferred when the result rests on patterns in the calls;
  • unknown when the evidence does not support a determination.

A declared client name is never presented as verification. When the evidence is thin, the result is Unknown rather than a confident guess, and your server knows exactly what it is working with.

A result your tools can use

The actor result arrives alongside the tool call, ready for your server's logic. In observation mode you record it. When you are ready, your tool-level policies act on it.

What your team gets: Detect, Understand, Route

Detect

Capture the caller evidence available on every tool call and keep verified, declared and inferred evidence distinct.

Understand

See which clients call which tools, how often, with what evidence, and how that shifts over time. Spot tools that attract mostly Unknown callers, clients that change behaviour, and the share of calls that carry verifiable identity.

Route

Write policies per tool and per risk tier. Typical patterns:

  • Low-impact tools such as search or read-only lookups: allow broadly, with a standard rate limit.
  • Moderate-impact tools such as creating drafts: allow verified and declared callers, rate-limit Unknown.
  • High-impact tools such as deleting data, changing settings or sending messages on a user's behalf: require your strongest authorization, and add confirmation or review where the caller is Unknown or acting autonomously.

The guide on protecting sensitive actions without blocking agents shows how to design these tiers.

Identity evidence, credentials and authorization are separate

MCP security works best when three questions stay distinct:

  1. Identity evidence: what kind of client is calling, and what proves it? Proof of Actor provides this.
  2. Credentials: which account or token is this call made with? Your MCP server's authentication provides this. The MCP authorization specification makes authorization optional and, for HTTP-based transports, bases it on OAuth 2.1, with the MCP server acting as a resource server that validates access tokens.
  3. Authorization: may this caller use this tool, with these arguments, for this account? Your permission model provides this.

A recognised client is not automatically an authorized one. A valid signature does not show that the person behind the session delegated authority for this specific action. Read more about delegated authority and agent authorization. Proof of Actor gives your server better context for the first question so your answers to the second and third are better informed.

Why not just trust the client name?

Because any client can send any name. Treating a declared name as proof invites imitation: a hostile client only has to copy the name of a popular assistant. Proof of Actor records the name as declared evidence, combines it with whatever stronger evidence exists, and tells you the basis. Your policy can then give verified callers more room than callers that only declared themselves, and apply your Unknown fallback when neither applies.

Start in observation mode

Installing Proof of Actor in your MCP server does not change how any tool responds. Results are recorded so you can see who calls your tools, how strong the evidence is, and where policies would help. When you are confident, enable a policy on a single high-impact tool, watch the outcomes, then expand. How It Works covers the full flow, and Detection & Limitations explains what each kind of evidence can and cannot establish.

Built for teams operating MCP servers and APIs

Proof of Actor sits inside your server alongside your existing authentication, rate limiting and logging. Integrations are delivered hands-on with each founding team, so the setup fits your transport, hosting and tool design. The MCP Servers and APIs use cases show how the same approach applies across your tools and your API.

Questions to ask about every tool you expose

Before writing tool-level policies, it helps to review each tool your MCP server exposes with a short checklist:

  • What can this tool change? Read-only tools and tools that modify data, send messages or affect billing deserve different treatment.
  • Who is it for? Some tools exist for assistants acting on behalf of a signed-in person; others for autonomous workflows. The expected caller shapes the right policy.
  • What would a mistake cost? A wrong search result is cheap. A wrong deletion is not. Map each tool to a risk tier.
  • What evidence should be required? Decide whether a declared client is enough, or whether the tool should need verified identity plus your strongest authorization.
  • What happens on Unknown? Choose an explicit fallback for each tool: allow, rate-limit, ask the user to confirm, or route to review.
  • How will you know it is working? Decide which outcomes you will watch in observation mode before you enforce anything.

Answering these once per tool turns caller identification into clear, testable rules, and makes it easy to explain your server's behaviour to the clients that integrate with it.

Join the founding developer program

Proof of Actor is in private beta. Selected founding development teams can receive up to 12 months of free access, within agreed usage limits, with direct support from our engineers as you design tool-level policies.

If you run an MCP server and want to know who is calling it, apply for early access. Tell us about your server, the tools you expose and the calls you care about most.

Sources

FOR DEVELOPERS

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 or Unknown.
basis
How strong the evidence is: verified, declared, inferred or unknown.
evidence
The signals behind the result, so your team can see why.

Start in observation mode: record results next to your logs and change nothing until you choose a policy. Read the Node.js integration guide

Frequently asked questions

Why does an MCP server need caller identification?

MCP servers expose tools to AI clients that act on behalf of people or run autonomously. Knowing what kind of caller is behind a tool call lets you allow low-impact tools freely and require more for high-impact ones.

Is the client name in an MCP session a verification?

No. A client name is a declaration made by the client. Proof of Actor records it as declared evidence and keeps it distinct from cryptographically verified identity.

Does caller identification replace MCP authorization?

No. Caller identity evidence, the credential used and what the caller is allowed to do are separate questions. Proof of Actor adds context to the first and leaves authorization to your server.

Will Proof of Actor block tool calls?

Only if your policies say so. Every integration starts in observation mode, and you enable tool-level policies when you are ready.

How can I try it?

Apply for early access. Selected founding developer teams can receive up to 12 months free within agreed usage limits, with hands-on integration support.

Know who's using your app.

Private beta for a small group of founding developers.

Get Early AccessView pricing

Prefer to talk first? Talk to the founders