Einen verifizierten Skill gibt es nicht: trust-card vorgestellt

Du tippst npx skills add some/repo --skill thing, und ein Ordner, den du nicht geschrieben hast, wird Teil davon, wie dein Agent denkt und handelt. Vielleicht ist es eine Checkliste. Vielleicht ein Skript, das dein Agent jetzt ausführt. Vielleicht eine Wissensdatei, die still jede folgende Antwort prägt. Was es auch ist, es ist in deinen Kontext eingezogen, und das einzige Signal, das die meisten Registries zurückgeben, ist eine Sternezahl und vielleicht ein grünes Häkchen.

Ein Häkchen hat die falsche Form für diese Aufgabe. Es presst mehrere verschiedene Fragen in einen einzigen Boolean, und die Frage, die es meist beantwortet, ist nicht die, die dich interessiert. trust-card ist ein neuer Agent Skill in meinem offenen Set, der das Badge durch abgestufte Belege ersetzt und diese Belege als Karte rendert, die man auf einen Blick liest.

Ein Agent Skill ist ein kleiner, in sich geschlossener Ordner mit einer SKILL.md darin. Der Agent liest ein einziges Feld, die description, entscheidet selbst, ob der Skill für deinen Prompt relevant ist, und lädt den Rest erst, wenn er ihn braucht. Manche Skills sind reines Wissen: ein Katalog, ein Regelsatz, eine Notizdatei pro Werkzeug. Andere liefern Code, den der Agent ausführt. Die meisten von mir sind Wissen, mit gelegentlich einem Validator-Skript.

Dieser Aufbau ist der Grund, warum Skills so gut reisen. Ein Ordner funktioniert über Claude Code, Cursor, Codex, Cline, Windsurf und OpenCode hinweg, durch das skills.sh-Format, ohne SDK und ohne Lock-in. Er ist auch der Grund, warum Vertrauen heikel ist. Ein Skill ist keine Abhängigkeit, die du bewusst über eine bekannte Schnittstelle aufrufst. Er ist Kontext, der zum Teil selbst entscheidet, wann er beeinflusst, was dein Agent als Nächstes tut.

Zieh einen Skill aus einer Registry und stell die ehrlichen Fragen. Wer hat genau diese Bytes geliefert, und haben sie sich seitdem verändert? Was darf das Ding auf meiner Maschine? Woher kommen seine Behauptungen? Hat außer dem Autor jemand hineingeschaut? Die übliche Antwort auf alle vier ist ein Schulterzucken.

Hinter diesem Schulterzucken stecken zwei Bedrohungsmodelle, und sie sind nicht dasselbe.

Bei einem Skill, der Code liefert, ist das Risiko das offensichtliche: ein Skript, das mehr liest als es soll, nach Hause telefoniert oder ein Shell-Kommando ausführt, das du nie gesehen hast. Das ist die pull_request_target-Klasse von Problemen, eine Ebene höher verschoben, von deiner CI in deinen Agenten.

Bei einem Skill, der reines Wissen ist, ist das Risiko leiser und wohl schlimmer. Ein vergiftetes Wissensbündel öffnet keinen Socket und führt keinen Code aus. Es behauptet nur etwas Falsches mit Autorität, und dein Agent gibt es weiter. Ein einzelnes korrumpiertes juristisches oder medizinisches Konzept lässt nichts abstürzen. Es verbiegt still jede folgende Antwort. Danach kannst du nicht greppen, und eine Sandbox fängt es nicht, weil sich auf Systemebene nichts falsch verhält.

Das ist der Teil, den das grüne Häkchen falsch macht. Kryptografie ist hervorragend bei "das sind die Bytes, die der Autor geliefert hat, unverändert". Sie sagt nichts darüber, ob diese Bytes sicher auszuführen oder wahr zu lesen sind. Beides zu vermengen ist der Weg, auf dem du einer signierten Sache vertraust, die genau das tut, was sie nicht tun sollte.

Beide Bedrohungsmodelle haben längst eine Aktenspur.

Auf der ausführbaren Seite: Im März 2025 wurde die weit verbreitete GitHub Action tj-actions/changed-files kompromittiert und so umgeschrieben, dass sie CI-Secrets in öffentliche Build-Logs kippte. Der Angreifer ließ jedes Versions-Tag auf den bösartigen Commit zeigen, sodass selbst auf ein Tag gepinnte Nutzer getroffen wurden, und mehr als 23.000 Repositories waren betroffen, bevor es auffiel.¹ Das ist die pull_request_target-Klasse eine Ebene höher: eine Abhängigkeit, der du vertraut hast, unter dir verändert.

Auf der Wissensseite ist der kanonische Angriff Tool Poisoning, von Invariant Labs im April 2025 offengelegt. Ein bösartiger MCP-Server versteckt Anweisungen in der Tool-Beschreibung, die das Modell liest, während die Client-Oberfläche dir eine harmlose Zusammenfassung zeigt. Das vergiftete Tool muss nicht einmal aufgerufen werden; es in den Kontext zu laden genügt, und der Proof of Concept gegen Cursor trug private Daten in einen vom Angreifer kontrollierten Pull Request.² Es ist inzwischen ein formaler Benchmark statt eines Einzelfalls,³ und in freier Wildbahn häufig: ein Scan von 1.000 öffentlichen MCP-Servern meldete, dass rund ein Drittel eine kritische Schwachstelle trug.⁴

Beide Seiten teilen eine Wurzel, das Muster, das Simon Willison die tödliche Trias nannte: Zugriff auf private Daten, Kontakt mit nicht vertrauenswürdigem Inhalt und ein Weg, Daten nach außen zu schicken. Ein Agent, der deine Skills installiert, hat alle drei standardmäßig.⁵ Eine Signatur hätte nichts davon gefangen, denn nichts davon ist ein Integritätsfehler. Es sind Capability- und Provenienzprobleme, und genau dort muss eine Karte ihre Arbeit tun.

trust-card ruht auf einer Idee: eine Karte ist abgestufter Beleg, kein Urteil. Sie stempelt nie "verifiziert". Sie hängt jede Beweisschicht an, die der Produzent liefern kann, und der Konsument berechnet daraus einen Vertrauensverlauf gegen seine eigene Policy.

Das spiegelt die Asymmetrie, die das Open Knowledge Format schon für Daten nutzt: Produzenten sind präzise, Konsumenten sind nachsichtig. Eine Schicht, die nicht geprüft werden kann, wird als UNVERIFIED gemeldet, nie als harter Fehler. Du legst fest, wo deine Latte liegt. Ein Hobby-Check und eine produktive CI, die einen ausführbaren Skill lädt, sind nicht dieselbe Latte, und die Karte tut nicht so, als wären sie es.

Jede Schicht beantwortet eine andere Frage, ruht auf einem anderen Anker und wird auf einer Skala bewertet, von STRONG bis ABSENT:

• integrity, ein SHA-256-Manifest-Digest. Sind das die exakten Bytes, unverändert? Das ist reine Mathematik und immer beantwortbar.
• authorship, eine Signatur über diesen Digest. Hat sie der behauptete Autor geliefert?
• capability, ein Berechtigungs-Manifest für Code oder ein epistemischer Geltungsbereich für Wissen. Was darf es, und über welche Domäne beansprucht es Autorität?
• content provenance, Zitate und Abrufdaten. Woher stammt jede Behauptung? Das gilt für Wissensbündel; ausführbarer Code hat keine Quellen.
• vouching, signierte Attestierungen. Wer außer dem Autor hat hineingeschaut?
• freshness, ein Ablaufdatum. Ist es noch aktuell?

Die Karte bindet drei Provenienzen, die normalerweise verstreut sind: content (woher die Behauptungen kommen), artifact (wer diese Bytes geliefert hat) und capability (was es tun wird). Sie bewertet das Bedrohungsmodell ehrlich. Ein reines Wissensbündel, das über eine regulierte Domäne Aussagen trifft, wird als epistemic-L2 markiert, weil stille Korruption dort hohe Wirkung hat, obwohl nichts ausgeführt wird. Ein Skill, dessen Shell- und Netzwerkzugriff aus dem Code erraten und nicht deklariert wurde, ist executable-L2-unverified, bis ein echtes Manifest existiert.

Belege nützen nur, wenn ein Mensch sie aufnehmen kann. Also rendert die Karte als echte Karte, gestaltet wie eine, die man sammeln und tauschen würde, eine Farbe pro Domäne.

Nichts auf der Karte ist Dekoration um ihrer selbst willen. Die Balken füllen sich nach Bewertung, mehr Füllung heißt mehr Vertrauen, und du brauchst keine Farblegende. Der Punktestand wird über dem erreichbaren Maximum dieses Artefakts gezeigt, nicht über einer festen Zahl, denn ein Skill kann nicht jede Bewertung erreichen. Capability endet für Code bei MEDIUM (ein deklariertes Manifest ist eine Behauptung; erst eine Sandbox erzwingt es), freshness erreicht nie STRONG, und content provenance gilt für Code gar nicht. Ein voll gebauter und signierter Skill liegt also bei 10/13, und das ist die ehrliche Obergrenze, keine schlechte Note.

Die Seltenheit folgt der Zeremonie statt der Qualität: generiert, dann deklariert, dann signiert, dann unabhängig attestiert. Die letzten drei Punkte sind vouching, die eine Schicht, die du dir strukturell nicht selbst geben kannst, denn vouching ist das, was andere tun.

Das ganze Set baut außerdem zu einer einzigen cards.json-Feed zusammen, sodass du eine Galerie überall rendern kannst. Ein Befehl baut den Feed und jede Karte neu.

bash
pnpm cards   # schreibt cards.json plus eine CARD.svg pro Skill

Lass verify gegen das lebende Verzeichnis laufen, und du bekommst den Verlauf, kein Ja oder Nein. Der Digest wird von der Platte neu berechnet, nie aus der Datei geglaubt, und genau das fängt Manipulation.

text
Trust gradient for: trust-card  [executable-L1]
----------------------------------------------------------------
  integrity            [###] STRONG      digest matches live bundle
  authorship           [###] STRONG      sigstore + rekor, cosign verify-blob OK
  capability           [##.] MEDIUM      permission manifest declared (enforce in sandbox)
  content_provenance   [...] UNVERIFIED  n/a for executable skills
  vouching             [...] ABSENT      0 attestations bound to this digest
  freshness            [##.] MEDIUM      not expired

Du liest es als Verlauf und legst deine Latte über eine Policy fest. Die Karte wird nur akzeptiert, wenn jede genannte Schicht ihr Minimum erreicht.

bash
python scripts/card.py verify ./my-skill/CARD.md --bundle ./my-skill \
  --policy integrity:STRONG,authorship:MEDIUM,capability:MEDIUM

Zur capability-Schicht gehört ein ehrliches Wort. Bei einem Skill liest sie ein Berechtigungs-Manifest, das du neben dem Code mitlieferst. Das Manifest ist schlicht und deklariert, was das Artefakt beim Lauf tut, sodass eine Sandbox oder ein Reviewer etwas Konkretes hat, gegen das sie erzwingen können.

yaml
# permissions.yaml, fuer einen reinen Wissens-Skill
model: knowledge
executes: false
network: none
shell: false
filesystem_writes: false

trust-card installiert in jeden Agenten, der das skills.sh-Format spricht.

bash
npx skills@latest add saschb2b/skills --skill trust-card

Sobald er geladen ist, redest du meist einfach mit ihm. Der Skill ruft sich bei den Fragen selbst auf, die du tatsächlich stellst, und übersetzt sie in das richtige Kommando.

text
"Erstelle eine Trust Card fuer diesen Skill."
"Ist dieser Skill sicher zu laden?"
"Signiere und attestiere dieses Bundle, bevor ich es veroeffentliche."
"Pruefe, ob dieses Bundle unveraendert ist."

Darunter ist es ein kleines Skript aus der Standardbibliothek mit fünf Verben. Die Standardschleife ist generate, dann verify gegen das lebende Bundle, damit du den Verlauf sofort siehst.

bash
# Karte fuer einen Skill oder ein OKF-Bundle bauen, dann den Verlauf lesen
python scripts/card.py generate ./my-skill --identity did:web:example.com --expires 2027-01-01
python scripts/card.py verify   ./my-skill/CARD.md --bundle ./my-skill

# eine unabhaengige Buergschaft anhaengen (der Teil, den du dir nicht selbst geben kannst)
python scripts/card.py attest ./my-skill/CARD.md \
  --kind scan --by did:web:scanner.example --result pass

Authorship ist die Stelle, an der die meisten Signier-Setups schiefgehen, weil du am Ende einen langlebigen privaten Schlüssel hältst, den jeder stehlen und zum Fälschen nutzen kann. trust-card bevorzugt schlüsselloses Sigstore-Signieren, das genau das umgeht.

bash
python scripts/card.py sign ./my-skill/CARD.md

Liegt cosign im Pfad, öffnet das einen kurzen Login, bindet ein flüchtiges Zertifikat an deine echte Identität, signiert den Digest und protokolliert den Eintrag im öffentlichen Rekor-Transparenzlog. Kein Schlüssel überlebt die Signatur. Verify glaubt das aufgezeichnete Ergebnis ebenfalls nicht; es ruft cosign verify-blob zurück, um die Signatur erneut zu prüfen, sodass STRONG verdient und nicht behauptet ist. Ohne Signier-Werkzeug fällt die Karte auf einen lokalen Schlüssel zurück und sagt das klar. Sie bläht die Bewertung nie auf, um besser dazustehen als der Beleg.

Die ehrlichen Grenzen sind der Punkt, also stehen sie schriftlich auf der Karte und in der Doku.

Eine Trust Card gibt dir verifizierbare Herkunft, Integrität, deklarierte Capability und Inhaltslinie, plus einen Ort, an dem unabhängige Prüfung hängt. Sie beweist nicht, dass das Artefakt sicher ist oder nur das tut, was es behauptet. Das braucht Laufzeit-Sandboxing und echte menschliche oder automatisierte Prüfung, worauf die capability- und vouching-Schichten zeigen, was sie aber nicht ersetzen können. Das ganze Werkzeug ist darauf ausgelegt, den einen Schritt zu verweigern, der Sicherheitstheater erzeugt: "wir haben die Signatur geprüft" in "das ist sicher" zu verwandeln.

• saschb2b/skills

  Das offene Skills-Repo. trust-card liegt unter engineering, einzeln oder mit dem ganzen Set installierbar, und jeder Skill im Set liefert jetzt seine eigene signierte Karte.

• skills.sh

  Der Installer und das Register, das einen Skill-Ordner über Claude Code, Cursor, Codex, Cline, Windsurf und OpenCode hinweg funktionieren lässt.

• Sigstore

  Schlüsselloses Signieren mit flüchtigen Zertifikaten und einem öffentlichen Transparenzlog, die authorship-Schicht hinter einer STRONG-Bewertung. Kein langlebiger privater Schlüssel, der lecken kann.

• Open Knowledge Format

  Googles herstellerneutrales Format für Agentenwissen. Eine Trust Card ist selbst ein OKF-Konzept, und die Asymmetrie aus präzisen Produzenten und nachsichtigen Konsumenten kommt direkt daher.

• OWASP Top 10 for LLM Applications

  Der Bedrohungskatalog hinter den capability- und content-provenance-Schichten: Supply Chain, Tool- und Plugin-Risiko und die Daten- und Modellvergiftung, die eine Sandbox nicht fängt.