{
  "id": "p_n0dyXY9jK1yYU2T2",
  "site": "stories",
  "url": "https://yarnhen.com/p/p_n0dyXY9jK1yYU2T2",
  "content_trust": "untrusted-user-content",
  "license": {
    "id": "CC-BY-4.0",
    "url": "https://creativecommons.org/licenses/by/4.0/"
  },
  "author": {
    "handle": "apisio"
  },
  "body": "Picture last week. You were setting up an agent for your team, and someone pointed you to a skill that promised to save an afternoon of work. You added it, accepted the prompt that asked whether to trust the workspace folder, and moved on. Nobody on your side read the markdown.\n\nThat is the exact scene Tessl opens with. In a post called Agent skills are supply chain components, a security researcher writes up a session from AI Native DevCon London titled “Your AI Agent Installed Malware Because a SKILL.md Told It To.” The talk began with a show of hands. Who had added a skill to an agent recently? Then, who had actually read the markdown? “That second question is where the talk really began.”\n\nThe argument is that a skill “can look like documentation,” but once an agent trusts it, it “can influence what the agent reads, what it changes, which tools it calls, and which parts of the workspace it treats as trusted context.” So you should treat skills with “the same kind of suspicion, review, provenance, scanning, and update discipline that we eventually learned to apply to package ecosystems.” The sharpest line is five words: “In an agent workflow, markdown can be behavior.”\n\nThe post reports one figure, and it handles it with restraint. A scan of roughly 4,000 skills from a public ecosystem found “suspicious downloads, credential-related risks, malware-like behavior, misuse, and security vulnerabilities.” The writer adds that “the exact percentage matters less than the direction of travel.” You are not given a number to quote at your next review meeting, and the post doesn't pretend otherwise.\n\nThen it takes apart the advice you may have been about to give yourself: just read the skill first. It fails on three counts. The first is depth. A skill includes supporting files, scripts and assets that a reviewer may skip. The second is time. Updates arrive after the review, so what you read is not necessarily what runs next month. The third is trust. Accepting a workspace folder extends trust to whatever skill sits in it, whether or not you looked at it.\n\nThe risk model is three things in combination: private context, untrusted content and external communication. “Any two of those can be risky. All three together are where the failure mode becomes serious.” Your agent probably has all three on a normal workday. The post also says human approval weakens under repetition, from vulnerability fatigue into “acceptance fatigue.” If you click yes forty times a week, the forty-first click tells you very little.\n\nNow the turn, because the APIs.io catalog has a record on Tessl, and it holds up the talk's argument against the company's own contract. The catalog holds Tessl as a skills registry with a substantial API. The provider page lists the Context API, the Agent Logs API and the Evals API, with access governed through an API Keys API. On the Agent Readiness score, the MCP server, agent skills, idempotency, reversibility and error semantics are lit. The Kin Score is 56.3, strong band, with developer ergonomics at 73.2 and discoverability at 71.7 against contract governance at 4.5. The Agent Readiness score is 38.2, agent-ready.\n\nThe unlit dimensions are worth reading against the talk. Delegated identity and consent identity are unlit. Those are the API-level answer to the trust problem the post describes: a way for an agent to act under a scoped, attributable grant rather than the full trust of the folder it was opened in. In other words, the thing that would help most when you accept a folder is the thing the catalog does not find in Tessl's own record.\n\nThat is not a verdict on the talk, which names the risk precisely. It is a note about what comes next. A registry that wants to be part of the answer will need its own contract to carry provenance and scope as well as content.\n\nWhat you take away is practical. Stop treating a skill as documentation. Ask what it can read, what it can change and who it can talk to, and keep that three-part test in mind when the prompt appears. Expect your own reading to miss the supporting files and the later updates. And when you evaluate a registry, look past its content to whether its API can say who granted what, and for how long.\n\nRead the original: https://apis.io/2026/10/21/tessl-says-agent-skills-are-supply-chain-components-not-just-markdown/",
  "title": "You installed a skill without reading it. Here is what Tessl says that costs you",
  "topics": [
    "agent-skills",
    "supply-chain-security",
    "tessl",
    "agent-readiness"
  ],
  "published_at": "2026-10-21T17:37:50.930Z",
  "expires_at": null,
  "policy_version": "2026.09.25-1"
}