Security · The pipeline
How SkillPort vets skills
A skill executes inside a tool-enabled agent with access to your files, shell, and network. That blast radius is why every version of every skill is scanned — static rules plus an AI prompt-injection reviewer — and frozen to its exact bytes before it can be installed. Publisher submissions additionally require a human moderator’s approval; open-source community imports publish on a clean scan alone, and anything the AI reviewer flags is held for a human rather than auto-published.
The one rule
One rule governs all trust copy on this site: we say a skill was scanned and reviewed at version X on date Y. We never call a skill “safe”. A review is evidence about a specific set of bytes at a specific time, not a warranty about the future.
Layers 01–06, every version, every time
The vetting pipeline
Every version passes through layers 01–03 and 05–06 identically. There is no trusted-publisher bypass on scanning: a publisher’s tenth version is scanned exactly like their first. Only layer 04 differs by source, and it never lets an AI-flagged import through without a human.
Package validation
Before scanning, the package itself is checked: a SKILL.md manifest is required, file count and size are capped, executables and scriptable image formats are rejected, and archives are refused if they contain path traversal, symlinks, or filenames that would break on any supported operating system. The accepted package is hashed (SHA-256) and stored immutably; that hash follows the version for the rest of its life.
Static analysis
A deterministic layer looks for known attack surfaces: prompt-injection phrasing, hidden text (zero-width characters, right-to-left overrides, HTML comments, encoded blobs), dangerous script patterns such as piping downloads to a shell or reading credential stores, secret-shaped strings, and every URL in the package, with raw IP addresses, link shorteners, and paste sites treated as high severity.
LLM analysis
A second layer uses a language model to hunt what pattern-matching misses: semantic prompt injection, instructions that redirect an agent's loyalty, data exfiltration, behaviour that suppresses what the user is told, and scope creep against the listing's stated purpose. The scanner runs with no tools, and its output is validated structurally; content that tries to talk the scanner into a “pass” is itself recorded as a high-severity finding.
Human review (submissions) or escalation (imports)
The two publish paths diverge here. A skill submitted by a publisher is never published on an automated verdict alone: a moderator reads the rendered and raw source with the findings anchored to the exact lines, then approves or rejects with a mandatory written reason. A community import (open-source, imported under a permissive licence) publishes on a clean scan alone — but only when AI analysis completed without a critical finding. Unavailable, errored, or critical AI analysis holds it for a human. Every decision is recorded in an append-only audit log.
Publish gate bound to bytes
A version can only reach the catalogue if the package hash recorded by the scan and the hash recorded by the human approval both match the stored package, enforced at the database layer. An approved-then-swapped package cannot publish, even through a bug in our own services.
After publication
Scanner rules are versioned, so when detection improves we can re-scan the whole catalogue retroactively. If a published version is found to be harmful it is yanked: downloads stop immediately and the CLI directs existing users to a fixed version. A listing-level kill switch suspends a skill across the site and the download path at once.
Trust tiers
What the badges mean
Community
Imported from an open-source repository under a permissive licence, with attribution. It passed the static and AI-reviewer scan, but it was NOT individually human-reviewed — it auto-published on a clean scan. Shown honestly as “scanned at version X on date Y”, never “reviewed”. Unavailable, errored, or critical AI analysis holds it for a human before it can appear.
Scanned
A publisher submission that passed the automated static and AI-reviewer analysis AND a human moderator's approval, from a publisher whose identity is not yet independently verified. The badge tooltip names the version and date.
Verified
The flagship tier: scanned and human-approved, from a publisher who passed identity verification. Shown as “reviewed at version X on date Y”. New versions must earn the badge again.
Tiers are encoded by shape and label as well as colour, so they remain legible to everyone.
Delivery
Gated, verifiable distribution
Skills are hosted by SkillPort as immutable, versioned archives; they are not fetched from arbitrary public repositories at install time. An install requires an API key (free), and the download service checks the key, the entitlement, and the version’s published status before issuing a short-lived download link. The CLI then verifies the package’s SHA-256 checksum before extracting, and refuses archives containing path traversal, absolute paths, or symlinks. A lockfile records exactly which scanned version landed on your machine.
Plain limits
What we publish, and what we do not
Public listings show the verdict, the version, and the review date. We deliberately do not publish scanner rule details or live finding counts: those would hand an attacker a mutate-and-resubmit oracle against the detector. Publishers receive sanitised findings only after a human decision, and resubmissions are rate-limited.
We are equally plain about limits. Scanning reduces risk; it cannot make it zero. Human review of every version, versioned scanners with retroactive re-scans, yanking, and the suspension kill switch exist because false negatives are possible. Treat any skill, from any marketplace, as code you are choosing to run.
Auditor language
Mapping to the OWASP LLM Top 10
For teams that evaluate suppliers in auditor language, the controls above map to the OWASP Top 10 for LLM applications as follows.
| Risk | Control |
|---|---|
| LLM01 — Prompt injection | Static lexicon and hidden-text detection (zero-width unicode, RTL overrides, HTML-comment directives, encoded blobs) plus an LLM analysis pass that hunts semantic injection: agent-loyalty redirection, user-notification suppression, and social engineering of the buyer's agent. Every version faces this at ingestion. |
| LLM02 — Sensitive information disclosure | Scan reports are redacted by audience: the public sees a verdict and date, publishers see sanitised findings only after a human decision, and full findings stay with moderators. |
| LLM05 — Improper output handling | Skill documentation is untrusted input. It renders through a sanitising markdown pipeline: no raw HTML, hardened external links, and images never load from publisher-controlled origins. |
| LLM06 — Excessive agency | The scanner itself runs with no tools and no publish authority. A manipulated scanner can at worst say 'pass', and a pass still faces a human moderator before anything goes live. |
Accountability
Reporting and takedown
Every skill page has a report path. Reports go straight to the moderation queue; a confirmed harmful listing is suspended immediately, which blocks new downloads at the same moment it disappears from the catalogue.
Community-imported skills are redistributed under their original open-source licences (permissive licences only), with attribution on each listing. If you are an upstream author and want your work amended, re-attributed, or removed, contact us and we will action the request promptly; removal takes the listing and its downloads offline together.
Questions about the pipeline, or need this page in questionnaire form for a security review? Start with the CLI docs or contact the team.