The most consequential thing in the retrieval stack right now isn't a model or a vector index. It's the Model Context Protocol maintainers publishing a new roadmap that promotes agent identity from "on the horizon" to a named priority, alongside server-initiated events and result type improvements.
The framing in the roadmap is the part worth reading closely. MCP's authorization model, as it stands, assumes a person with a browser at consent time — an OAuth flow, a human clicking approve, a token scoped to that human. The maintainers' observation is that the caller increasingly isn't a person at all: it's a cloud workload with its own identity, acting for a user who isn't present, or spawning further work of its own. That assumption is load-bearing in nearly every connector anyone has shipped in the last eighteen months.
Why this lands on your architecture
If you built an internal knowledge base or enterprise search layer on MCP servers, you almost certainly pushed the user's OAuth token through to the downstream system and let the source-of-truth ACLs do permission filtering. That is the right design when a human is in the loop. It falls apart for scheduled agents, background reindexing, multi-hop delegation, and any agent that runs while the user is asleep. The usual workaround — a service account with union-of-all-permissions access — is exactly the pattern that turns a retrieval bug into a data leak.
This connects to work already underway. The 2026-07-28 spec release made a remote MCP server behave like an ordinary HTTP workload, which is what makes standard HTTP-layer identity primitives usable here at all. WorkOS has written about Client ID Metadata Documents, where a client's identity is a URL pointing to a JSON document the client controls, and authorization servers fetch that metadata on demand instead of maintaining a registration database for every client. That's a meaningful shift for anyone who has tried to onboard hundreds of agent clients through dynamic client registration.
The memory half of the problem
Identity matters more now because memory is real. Mem0's state-of-agent-memory writeup argues memory has moved from an afterthought to a separately benchmarked layer of the stack over roughly the past eighteen months — the old approach was dumping conversation history into context and hoping. Persisted memory is also a new attack surface: research covered in early September described memory poisoning, where an adversary slips a misleading instruction into the store an agent writes to and later consults.
Put those together and the practical question for anyone building this stack becomes: *whose* identity wrote this memory, and under what authority is it being read back? If your memory records carry no provenance beyond a session ID, you have no way to answer that during an incident.
Concretely, worth doing this quarter: audit which of your MCP servers depend on a human-present consent flow, and add writer identity plus source attribution to every memory record you persist. Both get harder to retrofit as the spec lands.