Two changes landed nine days apart, in late July and early August 2026, and they look like opposites until you see the trend they form.
The MCP 2026-07-28 specification removed the required initialize handshake and session headers, making each request self-contained — "a fully stateless protocol," in Cloudflare's words, so an MCP server can now run in a plain Worker with no durable state or sticky sessions (Cloudflare). Sentry reports going live on the new protocol before the spec was finalized — "it didn't break prod," per co-founder David Cramer (Cloudflare). Deploying an MCP server went from an infrastructure project to an afternoon.
Days later, GitHub made enterprise MCP allowlists and denylists generally available: enterprise owners can centrally control which MCP servers Copilot clients may run, with policies that fail closed (The GitHub Blog).
Easier to deploy. Harder to trust. That is not a contradiction — it is a protocol growing up.
Why allowlists were inevitable
When running an MCP server is trivial, thousands of them appear. An enterprise cannot evaluate thousands of anything per developer per week, so it does what every enterprise does with an unbounded supply: it puts a gate in front and makes someone argue past it.
The gate turns a deployment question into a trust question. "Does your server run?" stopped being interesting the day the answer became always. The question an enterprise admin now asks is:
Why should your MCP server be on our allowlist?
Answering it takes more than an endpoint:
- Identity — who publishes this server, and is the running instance verifiably theirs?
- Minimal scopes — does it request only what its function requires, or everything?
- Predictable behavior — can its behavior be described in a sentence an admin can put in a policy?
- Data boundaries — what data classes does it touch, does it write or only read, and where does data go?
- Auditability — when something goes wrong, can the interaction be reconstructed?
A server that cannot answer those is not getting on the list, no matter how well it works.
What a memory server has to answer specifically
For memory and context servers the allowlist questions get sharper, because the data class is the enterprise's own accumulated knowledge:
- Is the server read-only, or does it accept writes? From whom?
- Is memory scoped per tenant, per agent, per user?
- What retention and deletion behavior applies?
- What does the server log about queries, and who can see those logs?
These are not compliance checkboxes. They are the difference between a memory layer an enterprise can adopt and one that quietly concentrates every agent's organizational knowledge behind a single unaudited endpoint.
Where this points
The MCP surface is how most agents will first touch a memory layer, which is why the hosted MCP endpoint answers the identity and data-boundary questions in its published contract: bearer-authenticated, tenant-scoped keys, a documented tool surface you can inspect directly — tools/list in your authenticated environment is the honest source of truth for what is currently exposed, before any integration relies on it (MCP server).
The trajectory is clear regardless of any single vendor: stateless made MCP cheap, allowlists made trust the currency, and trust is earned in the boring properties — narrow scopes, clear data boundaries, inspectable behavior.
Continue with the MCP server guide, the quickstart, or connecting coding agents.
Choose Northsun as your agent memory layer.