Daily signal: MCP skills ship in the TypeScript SDK with a security section hosts must now implement, and a client-auth downgrade question reopens in CIMD

Executive summary

The relevant movement is quiet and structural. The mechanism that lets an MCP server hand an agent a folder of reusable instructions and scripts is now final and available in the TypeScript SDK. Combined with yesterday’s move of the Agent Skills standard to a neutral foundation, a skill is becoming a normal thing a server serves. The SEP’s security section is good, but it is a list of things hosts should do; a library that ships the transport does not enforce any of it.

For the security events of the window, see the security brief (a refusal that still approved a destructive MCP call, a hostile-server OAuth gap, and tenant-isolation bugs in A2A and LangGraph).

Recommendation (opinion): before enabling skills over MCP in any host, write the host rules from the SEP’s security section as code: origin tag, per-skill approval, no allowed-tools from remote skills, digest-bound approvals.

Models

No frontier model launch, system card or pricing change was found in the window, and the Anthropic and OpenAI release pages I could open (Claude Code, Codex) list tooling releases only. Nothing to report for security.

MCP

Skills over MCP is Final and now in an SDK

OfficialSEP merged 13 Sep · SDK 23 Oct

What changed. SEP-2640 defines a skills extension (identifier io.modelcontextprotocol/skills, targeting the 2026-07-28 base revision). A server publishes each file of a skill directory as an MCP resource, conventionally under a skill:// URI; the host decides which metadata to show and which SKILL.md to read. TypeScript SDK 2.4.0 adds loadSkills(folder) and skills.attach(server) for servers and a SkillsClient that lists, reads and verifies skills, working on both the 2025-11-25 and 2026-07-28 revisions. The attach call is flagged experimental. The release notes also say the v1-to-v2 upgrade guide is distributed as an installable agent skill.

Security read. A skill is a bundle of instructions plus scripts, so a remote server that serves one is offering text the model will follow and files it may be told to run. The SEP’s security section is explicit about this, and it is worth reading as a threat model:

• skill content is untrusted model input, and a connected server does not make its skills authoritative;
• hosts should tag MCP-served skills with their origin server so the model can tell them from local ones;
• any code execution a skill triggers needs explicit per-skill user approval;
• a skill from one server must not cause reads against another server;
• same-named skills from different origins must not shadow or replace each other, local ones included;
• frontmatter that widens permissions (such as allowed-tools) is ignored for MCP-origin skills unless the user approves it;
• approving a skill does not approve skills nested inside it;
• digests come from the same server as the content, so they check consistency, not trustworthiness; persisted approvals should be bound to the file set and digests and revoked when it changes;
• cached copies must not enter filesystem-skill discovery paths and must be removed when the server is removed.

None of this is enforced by the transport. A host that reads skills over MCP and drops them into its normal skills directory has reproduced, with a remote server in the loop, the exact failure the SEP warns about: a skill gets local standing. The comparison is with the repository-as-attack-vector pattern from 21 to 23 Oct: trust given to a folder was read as consent for what the folder declared. Here the equivalent is trust given to a server being read as consent for what it serves. Two design points deserve attention: the “unlisted but fetchable by URI” behaviour means obscurity is not access control, and content-bound approval cannot work for dynamically generated skills, which the SEP lets hosts decline to load. ATLAS: supply-chain compromise via a poisoned instruction artefact; OWASP LLM01 prompt injection and LLM03 supply chain.

What to do. Do not enable attach or SkillsClient against third-party servers yet. If you serve skills internally, sign or at least pin the file set out of band, and review changes the way you review a dependency bump. If you build a host, implement the origin tag, the approval gate and the discovery-path separation before the feature reaches users.

Recommendation (opinion): treat skills over MCP as remote code distribution and gate it accordingly. The foundation’s skills security guidance is still a roadmap item (see the 23 Oct signal), so the SEP text is the only baseline there is.

Sources: SEP-2640 text · experimental-ext-skills · TypeScript SDK 2.4.0

SEP-3149: required client-auth methods, and the downgrade question

OfficialDraft · active 23 Oct

What is proposed. The SEP would make token_endpoint_auth_methods_supported a required field in a client ID metadata document (CIMD), the document an MCP client publishes at a URL so an authorization server can learn about it without prior registration. It deprecates the singular token_endpoint_auth_method and removes the implicit public-client default when no method is declared. The stated motive is interoperability: one document consumed by many authorization servers with different capabilities.

Security read. The pull request text says little about security; the review does. Reviewers ask whether a client could authenticate with a strong method once and fall back to a weaker one on a later refresh, whether a missing field should be treated as none (unsafe) rather than rejected, whether the singular-field fallback during deprecation should be mandatory, and whether the chosen method stays fixed for an existing grant. The proposal’s intersection rule also assumes the authorization server publishes its own method list, which RFC 8414 does not require. On 23 Oct a participant said they are aligning the upstream OAuth CIMD draft with the plural field. This matters because CIMD is how MCP clients identify themselves to authorization servers; a weak default there is a client-impersonation risk.

Recommendation (opinion): support the SEP only with a rule that the negotiated method is bound to the grant and that absence of the field is an error, not a default. The related DPoP profile (SEP-1932) needs the same clarity about downgrade.

Sources: SEP-3149 pull request

TypeScript SDK 2.4.0: what else changed

Official23 Oct

Beyond skills, the release rejects $id or $ref values with an invalid URI scheme (for example my_tool:output) through an updated validator, which is a behaviour change that can break existing tool schemas but shrinks the surface for odd reference resolution. It adds an opt-in scopeForRefresh hook for authorization servers that refuse refresh requests without a scope (Microsoft Entra ID is the named case), and keeps the 2.3.1 expectedResource option on requireBearerAuth, which accepts only tokens issued for the server but stays off unless you set it. The 1.x line got a typing patch (1.32.2). The release lists no advisories. Action: if you run an HTTP MCP server on the TypeScript SDK, set expectedResource now; it is the audience check the earlier signal reports flagged as missing by default.

Sources: TypeScript SDK releases · Python SDK releases

Agent ecosystem and interoperability

A2A state keys: a reminder from the Strands advisory

Official22 to 23 Oct

No A2A specification or SDK release landed (latest is 1.0.1 from 28 May, per earlier reports). The ecosystem point of the window is in the Strands Agents SDK advisory covered in the security brief: its A2A server shared conversation state across context_id values until the fix isolated state per context with an agent factory. The protocol-level lesson, which neither the A2A specification nor most SDK defaults state, is that a context identifier is a conversation handle chosen by the caller, so any server that holds per-conversation memory must key it to the authenticated principal as well. Action: if you host an A2A endpoint, add that rule to your implementation checklist next to the A2A Java SDK lessons.

Sources: GHSA-4v6f-7vjh-6x4m

Specification repository activity

The most recently updated specification pull requests are SEP-3149, SEP-3415 (Events), SEP-2633 (mcp.json), SEP-2778 (type constraints), SEP-1932 (DPoP) and SEP-2848 (asynchronous approval), all still open; SEP-2692 (stdio process lifetime) was closed on 19 Oct and the Tasks and Events working group merged on 20 Oct. The only commit to the main branch on 23 Oct changed a maintainer’s GitHub handle and affiliation. No security-relevant specification change in the window.

Sources: Specification pull requests · Specification commits