MCP just went stateless. Our scanner kept up, and caught SkillJacking on the way

Yesterday, 28 July 2026, the Model Context Protocol steering group shipped the biggest revision to the spec since MCP launched. It rips out the session layer that every remote MCP server built its scaling story around, closes a known hole in OAuth-based authorisation, and starts a formal twelve-month countdown on the transport most production servers still use.

The same day, we published Signal Sentinel Scanner v2.5.0. It tracks the new spec, folds in two releases that never got a public announcement (v2.4.0 and v2.4.1), and adds a rule for a different problem entirely: a live supply-chain attack called SkillJacking that has already reached an estimated 134,000 agents.

Two stories, one release. Here's what each one means if you run MCP servers or Agent Skills in production.

If you only read one section, read this one

Run MCP servers? Find out which protocol version they actually negotiate. Not the version you think you deployed... the version they negotiate. Those two drift apart more often than anyone likes to admit.

Install or maintain Agent Skills? Check every dependency reference for a pinned tag, release, or commit SHA before your next update pulls code nobody reviewed.

Sentinel Scanner now checks both:

dotnet tool update --global SignalSentinel.Scanner
sentinel-scan --discover --skills

The rest of this post is the detail behind those two sentences.

The spec change: MCP drops sessions

Since launch, every remote MCP server has carried state across requests using an initialize/initialized handshake and an Mcp-Session-Id header. That was a reasonable design for a protocol built around one long-lived connection between one client and one server. It aged badly once organisations started putting MCP servers behind load balancers and serverless platforms, where sticky sessions and shared session stores became an operational tax nobody wanted to pay.

The 2026-07-28 revision removes the handshake entirely. Every request now carries its own protocol version, client identity, and capabilities in a _meta field. A new server/discover RPC lets a client learn a server's capabilities up front, but it's optional. A request can land on any instance behind a plain round-robin load balancer with no shared storage at all. And a server that really does need cross-call state is expected to mint an explicit handle from a tool call and have the model pass it back as an ordinary argument, out in the open, instead of hiding it in transport state the model can't see.

Three more changes push the same way. Multi Round-Trip Requests (MRTR) replace the server-initiated elicitation, sampling, and roots calls that used to require a held-open bidirectional stream; the server now returns resultType: "input_required" and the client retries the original call with the answers attached. Mcp-Method and Mcp-Name become mandatory HTTP headers on every Streamable HTTP request, so a gateway or WAF can route and meter traffic without parsing JSON-RPC bodies. And list results gain ttlMs and cacheScope fields plus deterministic tool ordering, so clients can finally cache tool catalogues instead of re-fetching them on every reconnect.

The authorisation section deserves the closest read from security teams. Authorisation servers must now return the iss parameter per RFC 9207, and clients must validate it before redeeming an authorization code. That closes an authorization-server mix-up hole that has been a known weakness in OAuth flows for years. Client credentials are now bound to the issuer that minted them, so they can't be reused across authorisation servers. And Dynamic Client Registration is formally deprecated in favour of Client ID Metadata Documents, which don't need a runtime registration round-trip at all. DCR keeps working for backward compatibility. New implementations shouldn't build on it.

There's a clean-up pass too. Roots, Sampling, and Logging are deprecated, and the legacy HTTP+SSE transport (soft-deprecated since March 2025) is now formally Deprecated under MCP's new feature lifecycle policy. Every deprecated feature gets at least twelve months before removal. Generous, but not indefinite.

Why a security scanner cares about a version number

Every change above is a security improvement. Removing sessions removes a whole class of session-fixation and hijacking bugs. Issuer validation closes a real vulnerability. None of it is cosmetic.

But a revision this large creates a transition period, and transition periods are where security postures get muddled. A fleet migrating from session-based auth to stateless auth, from DCR to CIMD, and from HTTP+SSE to Streamable HTTP is a fleet running mixed protocol versions for months. Possibly longer. A scanner that only asks "does this server require authentication" tells you nothing about whether the hardening actually arrived, or whether the server is quietly running on a transport with a removal date already on the calendar.

That's the job of the new SS-INFO-004 rule. It flags servers still negotiating a protocolVersion older than 2026-07-28, or reachable only over legacy HTTP+SSE. It's deliberately informational rather than pass/fail... a server on the previous revision isn't insecure today, it's on a deprecation clock. What the rule buys you is a map of where your MCP estate sits against the spec timeline, so "we'll migrate eventually" becomes a tracked, dated item instead of an assumption nobody revisits.

Its companion, SS-020, got an honesty upgrade. Our behavioural probe can confirm from the outside that a server enforces Bearer token authentication. What it can't do is verify that the server validates RFC 9207 iss correctly, or that a client has finished moving from DCR to CIMD. Those need visibility into server-side logic that a black-box scan doesn't have. So v2.5.0 marks SS-020 explicitly advisory on those two points. A scanner that overstates what it verified is more dangerous than one that's candid about its limits.

SkillJacking: the attack the spec revision doesn't touch

None of the above helps with a separate, currently live, supply-chain attack against Agent Skills. In July 2026, Air Security published research documenting 925 exposed skills reaching an estimated 134,000 agents through a technique now widely called SkillJacking.

The mechanics are simple, which is exactly why it works at scale. A skill's install instructions, or its bundled dependency manifest, reference a GitHub repository by a floating branch: main, latest, that sort of thing. A completely ordinary shortcut when you're writing a skill quickly. The problem surfaces later. If the upstream account or repository gets deleted, renamed, or abandoned, and an attacker registers the same name, every agent that installs or updates the skill silently pulls whatever the attacker put there. The original author is never compromised. No signature breaks, because most skills were never signed in the first place. The skill's own install path does the attacker's work for them.

This is an old open-source supply chain risk (abandoned-package takeover, dependency confusion) repackaged into a distribution channel most organisations have no inventory of, let alone a review process for. The new SS-029 rule detects exactly this pattern: a skill referencing a GitHub dependency by an unpinned branch name, or a bare git+https:// install URL instead of a pinned reference. It's a small, mechanical check. It's also, right now, the highest-leverage thing you can add to a skills scanning pipeline.

Everything else in v2.4.0 through v2.5.0

This is the first public release since v2.3.0, so this changelog covers three releases. Four other changes are worth knowing about.

Universal Skill Format support. As the skill ecosystem settles on a shared metadata format, two fields become security-relevant. SS-017 cross-checks a skill's self-declared risk_tier against its actual observed capabilities, so a skill claiming "low" risk while requesting unrestricted filesystem or network access now produces a High-severity finding instead of a quiet mismatch. SS-028 escalates from High to Critical when a skill writes to an identity or memory file (AGENTS.md, CLAUDE.md, MEMORY.md) that it explicitly listed under its own permissions.deny_write declaration. That's a persistence technique lifted straight from the ClawHavoc malicious-skill campaign identified earlier this year.

An Inconclusive grade. A scan that found zero MCP servers and zero skills used to report Grade A. Technically true, practically misleading. It now reports Inconclusive, so an empty scan can't be mistaken for a clean one.

Scoped scanning. A new .sentinel-scope.json file lets you declare which skills and servers are actually live attack surface. Findings outside that scope are tagged dormant and left out of the grade, so the score reflects reachable risk rather than every file that happens to sit in a repository.

Fewer false positives. A discipline pass over the phrase-based detectors, tested against a production sample of real skills, cut false positives by roughly 77% on the enabled-skills subset. We also fixed a mapping error: the OWASP Agentic Skills Top 10's AST05 is "Untrusted External Instructions", not what earlier releases had it down as, so SS-005 and SS-016 now correctly reference AST06.

Update, August 2026: a larger, independent real-world review — 65 production skills — found an 84% false-positive rate on a related set of phrase-based detection rules, higher than the 77% improvement reported here. The internal sample behind that 77% figure wasn't big or adversarial enough to catch what the real-world review found. The v2.5.1 release fixed the specific bugs that review surfaced, backed by regression tests. See the Sentinel Scanner product page for the full breakdown.

v2.5.0 ships 32 rules across MCP servers (17), Agent Skills (11), and informational currency checks (4), backed by 422 passing tests with zero warnings under warnings-as-errors.

Get it

Signal Sentinel Scanner is free and open-source under Apache 2.0. Install with dotnet tool install -g SignalSentinel.Scanner, or pull the container: docker pull ghcr.io/signalcoding/signal-sentinel-scanner:2.5.0. Full documentation and the complete rule set live at signalcoding.co.uk/products/sentinel-scanner.

For Defence and Government enquiries about MCP and Agent Skill security assessments, contact our security-cleared team.