MCP Sessions That Outlive the Connection
August 16, 2026 · InfraScout Team
The Model Context Protocol keeps moving. Revision 2026-07-28 removes protocol-level sessions and the session header that carried them, and drops the initialize handshake in favor of a discovery call. A client built against that revision connects, discovers what InfraScout offers, and starts calling tools — without ever establishing the thing InfraScout had been hanging two features off.
Those two features were session groups for clients driving InfraScout directly over MCP, and the MCP audit trail. On a modern client, session_start would simply have failed.
The anchor moved to your identity
InfraScout now mints its own logical MCP session rather than borrowing the protocol's. It resolves every authenticated request to a session using the identity you signed in with and the client you are calling from, and treats a quarter-hour of silence as the boundary between one working session and the next.
That is one code path for both protocol eras. A client that still sends the old session header keeps working — the header is now a lookup hint rather than the source of truth, and identity always comes from your signed-in credentials. A client that never sends one gets the same behavior for the first time.
The client name is load-bearing here, not decoration: it is what keeps two different clients used by the same person from being folded into one assessment.
Explicit control over session groups
Because the protocol no longer offers an implicit handle, session_start gained two optional arguments:
group_id— continue a specific session group by naming it.new_group— start a fresh one deliberately.
Omit both and you continue whatever group you are currently working in, which is what almost every assessment wants. The behavior you already had is the default; the arguments exist for when you need to be explicit about it.
Callers that were invisible to audit
Administrators can drill from an MCP session into the executions it produced. That drill-in matched on the old session header, which meant callers that never sent one — application callers, and now every modern client — recorded work that could not be traced back to a session.
The drill-in now matches on both the logical session and the legacy header. Two things follow: history recorded before this release stays reachable exactly as it was, and header-less callers become drillable for the first time.
Four smaller alignments, one of them security-relevant
Reading a playbook over MCP returned a result that did not state how it could be cached. The specification reads an unstated cache scope as public — so tenant-scoped playbook content, gated on who is allowed to see it, was being advertised as replayable by any shared intermediary between you and InfraScout. Playbook reads now declare themselves private, matching the treatment the tool and resource listings already had.
The other three are mechanical. Browser-based MCP clients from an allowed origin now pass the preflight check, which they previously failed on two headers the current revision requires them to send. InfraScout now states its capabilities explicitly rather than leaving them inferred, which stops some clients from holding open a long-lived listener for change notifications InfraScout never sends. And dynamic client registration now declares its application type, as the current specification requires.
Older clients are unaffected by all four. If you are running Claude Desktop, Claude Code, or any 2025-era client today, nothing about your setup changes.
See Understanding MCP for the protocol itself, Connecting an AI Client for setup, and Session Tools for the session_start contract.
Questions or feedback? Reach us at info@infrascout.cloud.