Your MCP Server Has No Idea Who Is Calling It
MCP spent its first year on capability. Identity is still catching up, and the part that would actually fix it is sitting in draft. Here is what your server can and cannot see today, and what to do about it this week.
Accurate as of October 2026.
Security was the throughline at AGNTCon and MCPCon North America in San Jose on 22 and 23 October. Not the fun kind of security either. The recurring question was simpler and more awkward: when an agent calls your tool, who actually asked for it? Right now, in most deployments, your server cannot answer that.
The protocol got very good at letting agents do things, very quickly. Identity was always going to be the harder half, and it was deferred. That bill is now arriving, and the timing is bad because agents are being handed write access to real systems.
Look at what actually lands at the server. A tool name, some arguments, and a bearer token that belongs to the application. The human who typed the request is nowhere in the payload. Your server knows a merge was requested by something holding a valid credential. That is the whole picture.
The 2026-07-28 specification added stateless servers, and plenty of developers read that as MCP turning into just another API. The practical effect is that the route you choose decides what your server is allowed to remember. Stateful keeps a session you can hang context on. Stateless starts fresh on every call.
Stateful gives you a session id, a client name, a bearer token and a tool name. Stateless gives you the token and the tool name. Neither gives you a person. Speakers put stateless traffic at around 70% on some platforms, though that was a stage claim with no published data behind it, so treat it as directional rather than a number to plan against.
This is where it stops being theoretical. Six weeks after a bad merge, someone asks who approved it. You can prove a call happened. You cannot prove who made it. Was it the agent acting autonomously, the service account it borrowed, or a teammate who kicked off the run and went to lunch? An audit trail that cannot name a person is not an audit trail.
The work is underway and it is honest about where it stands. Enterprise-managed authorization is live in Claude and marked stable on the MCP auth roadmap. The pieces that would let an agent prove it is itself are still drafts: Demonstrating Proof of Possession, and a delegation path built on workload identity federation, the ID-JAG grant and standard token exchange.
Read the roadmap and the ambition is stated plainly. The goal is for servers to recognise and trust agent identities through existing standards rather than, in its own words, "pasted API keys and long-lived tokens". That is the destination. It is not where you are deploying today.
Identity is one of five named priority areas, alongside agent messaging, skills over MCP and an HTTP-native transport. About a third of the 116 MCP conformance scenarios now test security, which is a reasonable proxy for how seriously this is being taken.
There is no shippable fix inside MCP today. The closest working example sits outside it: Block's Buzz, where agents hold their own cryptographic identities that are not tied to a platform account or a vendor-managed API key. It has been open source under Apache-2.0 since July, and version 1.0 was said at the conference to be due mid-November 2026. Useful as a proof that the model works, but it is a workspace built on Nostr, not a drop-in answer for your MCP server.
Meanwhile MCP tasks in Claude Code now let a single tool call run for minutes, hours or days, which means that unnamed caller stays open far longer than it used to. The exposure is widening slightly faster than the fix is landing.
Status on this one: only vetted it. I read the talks and the roadmap. I have not shipped a server on the new auth pieces, because most of them cannot be shipped on yet.
None of these wait on the specification.
| Move | Why it works now |
|---|---|
| Log caller context yourself at the server boundary | You control this layer. Capture who asked and why, even if the protocol will not carry it |
| Keep servers stateful wherever audit matters | A session id is weak identity, but it is more than a bare token |
| Never assume the transport names the caller | Design your authorization as if the token tells you the app and nothing else, because that is true |
The pattern is the same in each case: stop waiting for the protocol to hand you identity, and write down who asked at the one boundary you own.
Where this nets out: you are managing the gap right now, not closing it. Treat every MCP tool call as anonymous until your own logging says otherwise, and the day proof-of-possession lands you will already have the trail you need.
Found this helpful? Share it with others!