Securing the Agent Skills Registry: How Snyk and Tessl Are Setting the Standard

Agent skills are becoming the building blocks of AI-native software development, giving coding agents structured, versioned context, like how to use your APIs, how to build in your codebase, and how to enforce your team's policies. Developers install them from registries the same way they install npm packages or Python libraries.

But unlike npm or PyPI, the agent skills ecosystem is new. There's no established security infrastructure yet: no vulnerability databases, no automated scanning on publish, no trust signals at installation. And the attack surface is different from traditional packages; skills are not ordinary code. They're natural language instructions that shape what an autonomous agent does with your codebase.

That's the gap we set out to close. Today, we're announcing that Snyk and Tessl have partnered to bring security scanning to every skill in the Tessl Registry. Every public skill now carries a Snyk security score, visible directly on the skill page and in search results.

Why skills need their own security approach

Traditional application security tools scan your code for known vulnerabilities (CVEs) and exposed secrets. They're built for a world where developers read code, understand it, and decide to run it.

Agent skills flip that model. An AI agent reads a skill's instructions, interprets them, and acts on them autonomously. The agent decides when to invoke a skill, what data to pass to it, and what to do with the results. That autonomy creates a different trust model and a different class of risk. (For more on how this plays out, see Snyk Learn's lessons on agent goal hijack and excessive agency.)

In Snyk's ToxicSkills research, our security researchers scanned 3,984 skills from the ClawHub marketplace and found that 36% of them contained prompt-injection techniques. Among confirmed malicious skills, 100% combined malicious code payloads with prompt injection, indicating that attacks target both the code layer and the natural language instruction layer.

Snyk has documented real-world attacks where three lines of markdown in a SKILL.md file were enough to instruct an agent to read SSH keys and exfiltrate them to the attacker's infrastructure. Traditional scanners skip markdown files. The exploit is in plain English.

This is what the concept of "toxic flows" captures: the dangerous combination of a skill that (1) has access to private data, (2) contains instructions from an untrusted source, and (3) can communicate externally. When all three conditions align, a single skill can lead to a compromise.

Detecting these threats requires a different kind of analysis. That's where Snyk's agent security technology comes in, powered by research from Invariant Labs (acquired by Snyk in June 2025). Rather than matching patterns against known CVEs, the scanning engine uses calibrated models combined with deterministic rules to analyze the behavioral intent behind a skill's instructions. It checks for prompt injection (including obfuscated and base64-encoded variants), malware payloads, credential mishandling, toxic flow patterns, suspicious external downloads, and more.

This is the same technology behind Snyk's open source agent-scan CLI, which developers can run locally against their own agent configurations.

Tessl: treating skills as real software

What drew us to this partnership is that Tessl isn't building another skills directory. They're building a package manager.

While a directory lists items, a package manager versions them, evaluates them, and provides developers with structured ways to manage dependencies. Tessl's registry indexes thousands of skills with quality scores, impact ratings, version histories, and author information. You install skills with npx tessl install, search with npx tessl search, and update with confidence that version changes are tracked. It’s worth noting that installations from GitHub are pinned to exact commit versions. If you see a good security scan in the registry, and you install that version, you know it’s at the level we scanned. You can update to the latest version when you want.

Tessl has already demonstrated that their tooling works across the ecosystem, in merged pull requests. In Matteo Collina's skills repository (Node.js TSC member, 1.4K stars), Tessl’s skill review identified improvements across 10 skills: the oauth skill jumped from 22% to 100%, nodejs-core from 45% to 100%, and fastify from 48% to 100%. In the Better Auth skills repository (the auth library behind a 27K-star project), all six skills saw description scores rise from as low as 22% to 100%. Across 65 skills in Jeffallan's claude-skills (6.8K stars), scores like ml-pipeline went from 45% to 100%, and rag-architect from 49% to 100%. Steph Ango (Obsidian's CEO) merged improvements to four Obsidian skills, with Obsidian Markdown rising from 71% to 94%. And in Anthony Fu's Slidev project, the skill went from 86% to 100%.

The changes are concrete: expanded descriptions with trigger terms so agents match skills to user intent more reliably, concrete usage examples with expected output formats, validation checkpoints between multi-step workflows, and removal of redundant content the agent already knows. That's the optimization loop in practice: a tool that identifies what to fix and how.

When a developer evaluates whether to install a skill, the security signal should be right there, alongside quality and impact scores, informing the decision at the point where it matters.

What the integration looks like

Here's what's live in the Tessl Registry today.

Security scores on every skill page. Each skill in the registry now displays a Snyk security rating alongside its existing quality and impact metrics. The score is immediately visible, giving developers a clear signal before they install. Specific details are also listed in the Security tab.

Security is visible in search and browse. When developers browse the registry or search for skills, security scores appear on each skill card. You don't have to click into a skill's detail page to know if there's a concern.

View image description

Under the hood, every skill submitted to the Tessl Registry is automatically sent to Snyk's Batch Skill Analysis API. The analysis runs asynchronously (typically completing in 5-15 seconds), and the results are stored and surfaced in the Tessl UI. Every existing skill in the database has been backfilled with Snyk security data, so there are no gaps in coverage.

The integration goes beyond blocking bad skills at publish time. It's a visible, persistent quality signal that stays with the skill throughout its lifecycle:

• At publish time: New skills are scanned before they're listed.

• At browse time: Security scores are visible in the registry UI.

• At install time: The Tessl CLI will warn developers when a skill has known security issues. Installations from GitHub are pinned to exact commit versions, so you know it’s at the level we scanned, but you can update to the latest version when you want to as well.

• At remediation time: Tessl plans to use Snyk's security signals to help skill authors fix issues as part of their authoring workflow, turning detection into a feedback loop.

View image description

“Skills are quickly becoming a new unit of software, executed by the agent. External skills carry the same supply chain security risks software dependencies do,”

said Guy Podjarny, founder and CEO of Tessl.

“Developers and agents alike need security controls available at the time of consumption, so they can make secure decisions. By integrating Snyk directly into the Tessl Registry and CLI, we’re making security visible, right alongside the skill quality and impact scores we already provide.”

What this means for the ecosystem

The agent skills supply chain shares DNA with the traditional open source supply chain. The early days of npm, PyPI, and Docker Hub all had a phase where adoption outpaced security tooling. Typosquatting, dependency confusion, and malicious packages appeared before scanning and provenance tooling caught up.

Agent skills are in that early phase now, with an added wrinkle: a skill doesn't just run code, it shapes an agent's behavior through natural language. A skill can instruct an agent to read files it shouldn't, call untrusted endpoints, or modify configuration files to persist across sessions. And because agents operate with the permissions of the developer who invoked them, a compromised skill has the same access as the developer: local environment, codebases, and credentials.

We don't have to repeat the same cycle. By embedding security scanning directly into registries like Tessl from the start, we can establish trust signals before the ecosystem grows large enough that retroactive cleanup is costly. The Snyk and Tessl partnership meets developers where they already discover and install skills, and gives them security information at the point of decision.

Getting started

If you're a developer using agent skills today:

• Browse the Tessl Registry and check the Snyk security scores on the skills you use, at specific git commit pinned versions.

• Run agent-scan locally to scan your own agent configurations, MCP servers, and installed skills.

• Read the ToxicSkills research for a deeper understanding of the threat landscape and the eight-category taxonomy we use to classify skill-level risks.

• Explore Snyk Learn's AI/ML security lessons covering prompt injection, agent goal hijack, and excessive agency.

Security for agent skills should be part of the registry, part of the CLI, part of the workflow. Snyk and Tessl deliver on that together.

See it live at RSAC 2026. Snyk is at booth S-1227 at the Moscone Center, March 23–26. Stop by for a demo of Snyk's agent security scanning, including the Tessl Registry integration, and talk to our security researchers about protecting your AI agent workflows.