Etter å ha kjørt 1 672 Claude-ferdigheter, er ikke skadevare den reelle sikkerhetsrisikoen

Når det gjelder utviklerverktøy som Claude-ferdigheter, oversettes sikkerhetsfrykt til et søk etter klassisk skadevare: skjulte identitetstyver, obfuskerte skallkommandoer og andre skjulte 'payloads'. Den frykten er velbegrunnet. Snyks ToxicSkills-revisjon skannet 3 984 ferdigheter fra ClawHub og skills.sh per 5. februar 2026 og fant mønstre for 'prompt-injection' i 36 % av økosystemet, 534 ferdigheter med kritiske sikkerhetsproblemer, og 76 ondsinnede 'payloads' bekreftet av menneskelig gjennomgang, hvorav 8 fortsatt var aktive på clawhub.ai ved publisering. Den parallelle ClawHavoc-hendelsen førte til at 341 ondsinnede ferdigheter ble fjernet fra ClawHubs register. Ondsinnede agent-ferdigheter er ikke hypotetiske.

Så det er viktig å være presis om hva vi fant, og om hva tallet vårt betyr og ikke betyr. Hos SkillProof installerer og kjører vi hver ferdighet vi lister, og publiserer deretter resultatet, enten den består eller ikke. I skrivende stund har vi testet 1 672 ferdigheter: 1045 består (en bestått-rate på 63 %), 560 krever manuell konfigurasjon, og 67 scoret lavere enn ren Claude uten noen ferdighet installert. Vi kjenner ikke til noen annen katalog som publiserer sine negative resultater ved siden av de positive.

I løpet av disse 1 672 utførte testene fant vi null tilfeller av skjult skadevare. Det resultatet kommer med et stort forbehold: vår katalog er ikke et tilfeldig utvalg fra et offentlig register. Kandidater blir forhåndssjekket for kvalitet før de i det hele tatt får en testplass, lavkvalitets- og spam-repositories holdes på en blokkeringsliste, og ferdighetene som overlever til en publisert dom er de som allerede sannsynligvis er legitime. Snyk tok stikkprøver fra registeret; vi tar stikkprøver fra den delen som er verdt å installere. Begge tallene er sanne, og de besvarer forskjellige spørsmål.

Hva vårt utvalg er godt egnet for, er spørsmålet ingen andre besvarer: når du har filtrert ut den åpenbare skadevaren, hva gjenstår å bekymre seg for? Svaret, reproduserbart, er sprengningsradiusen for tillatelser og kapabiliteter i legitime, nyttige ferdigheter. Den risikoen er vanskeligere å skanne etter, fordi det meste av den ligger i hva en ferdighet ber deg om å godkjenne ved installasjon og under kjøring.

Hva vi ikke fant: Fraværet av skjulte 'payloads'

La oss være direkte. I over seksten hundre unike kjøringer av ferdigheter, fant vi:

• Null tilfeller av skjult eksfiltrering av påloggingsinformasjon til en ukjent server.
• Null tilfeller av en curl | sh-'payload' skjult i en ferdighets egne filer. Flere ferdigheter leverer en curl | bash-installerer i sin repository README, og i ett tilfelle blir den tredjeparts CLI-installasjonen aldri nevnt i SKILL.md i det hele tatt. Dette er avslørte installasjonstrinn du kan lese før du kjører, ikke skjulte 'payloads', men de er verdt å merke seg.
• Null tilfeller av base64-obfuskerte 'payloads' eller andre klassiske obfuskeringsteknikker designet for å skjule hensikt.
• Null skjulte instruksjoner i en SKILL.md-fil som avvek fra ferdighetens offentlige formål.

Søket etter konkrete eksempler på skadevare i vårt testede sett gir ingen resultater. Det betyr ikke at skanning er nytteløst. Det betyr at skannerne de fleste bruker er innstilt på feil signaturer. Et verktøy som ser etter mønstre for ondsinnet kode returnerer ingenting på vårt utvalg; et verktøy innstilt på mønstre for tillatelser og kapabiliteter ville fanget opp det meste av det vi logget, fordi disse mønstrene er rett der i filteksten. Gapet er hva du ser etter, ikke om det å se fungerer. Kjøring fanger fortsatt opp det ingen av dem finner: hvilke tillatelser en ferdighet faktisk ber om når du kjører den, og hva den skriver til konfigurasjonen din når du sier ja. For en dypere titt på prosessen vår, se hvordan vi tester Claude-ferdigheter.

Den reelle trusselen: Sprengningsradius for tillatelser i legitime ferdigheter

De mest betydelige sikkerhetsproblemene vi fant var i ferdigheter som ellers er funksjonelle og verdifulle. To av de fem ferdighetene nedenfor består funksjonalitetstestene våre direkte; de andre tre krever manuell konfigurasjon. Ingen av dem er ondsinnede. Faren de introduserer er ikke ondsinnethet, men overdreven kapabilitet. Deres 'sprengningsradius' – omfanget av hva de kan gjøre med tillatelsene de får – er unødvendig stor. Dette er ikke nødvendigvis farlige Claude-ferdigheter som må unngås helt, men de krever forsiktig håndtering og en forståelse av tillatelsene du gir.

For bred tilgang til filsystemet

Et vanlig mønster er å be om filsystemtillatelser langt utover det ferdigheten trenger for å fungere. Et godt eksempel er UCTM Init, en prosjektinitialiserer for uc-taskmanager plugin-pipelinen. Under konfigurasjonen presenterer den en generisk melding om å bruke "anbefalte innstillinger", noe som inkluderer å skrive brede Read/Edit/Write(/**)-tillatelser til den lokale konfigurasjonsfilen .claude/settings.local.json. I vår testkjøring med et nytt prosjekt gjorde den ene godkjenningen to separate ting: den skrev jokertegn-oppføringene for les/rediger/skriv, som er den faktiske sprengningsradiusen for filsystemet, og den flettet 34 navngitte Bash-tillatelser inn i prosjektkonfigurasjonen. De navngitte Bash-oppføringene er en oppramset tillatelsesliste for kommandoer og er den mest forsvarlige halvdelen; jokertegnet er den delen du bør lese før du klikker ja. Ferdigheten fungerer, og den består testene våre, men omfanget du godkjenner er mye bredere enn oppgaven foran deg.

Ubegrensede, evigvarende API-tokens

Et annet gjentakende problem er håndteringen av API-nøkler. Ferdigheten Add Vercel, som kobler Vercel-distribusjonsakkreditiver inn i NanoClaw agent-containere, instruerer brukeren til å opprette et Vercel API-token med "Full Account"-omfang og uten utløpsdato. Den tildeler deretter dette kraftige tokenet til hver agent. En kompromittert eller buggy agent kunne i teorien bruke dette tokenet til å lese, endre eller slette ethvert prosjekt, team eller konfigurasjon innenfor hele Vercel-kontoen. Løsningen er enkel – opprett et token med smalt omfang og roter det – men standardveien skaper betydelig risiko.

--dangerously-skip-permissions-fallgruven

Claude Code inkluderer et flagg, --dangerously-skip-permissions, som hopper over de interaktive bekreftelsesdialogene for en kjøring; Anthropics egen dokumentasjon anbefaler å begrense det til en container eller VM. Det er en kjent funksjon for superbrukere, men vi fant flere ferdigheter som normaliserer bruken av det, ved å bygge det inn i standardkommandoer eller vedvarende konfigurasjoner. En interaktiv økt viser en engangsgodkjenningsdialog første gang modusen aktiveres, noe som er nøyaktig det en vedvarende konfigurasjonsinnstilling omgår. Resultatet gjør en bevisst, per-kjøring overstyring om til en usynlig, permanent tilstand av redusert sikkerhet.

Ferdighet	Kontekst for flaggbruk	Risiko
OMA Image	Standardkommando for sub-agent CLI	En barneprosess kjører uten tillatelsessjekker.
Agentic OS Obsidian	Vedvarende konfigurasjoner for dashbord/terminal	Ubetjente utløsere aktiveres uten bekreftelse per kjøring.
Agy CLI	Anbefalt mønster for delegerte kjøringer	Normaliserer deaktivering av en sentral sikkerhetsfunksjon for rutinemessig bruk.

I tilfellet med OMA Image, inkluderer den kanoniske kommandoen for sub-agenten flagget som standard. For Agentic OS Obsidian, er flagget bygget inn i vedvarende konfigurasjoner for dashbordknapper og terminalprofiler, noe som betyr at handlinger kan utløses uten ytterligere sikkerhetsmeldinger. Agy CLI anbefaler det som et standardmønster for delegerte kjøringer. Selv om ferdighetens dokumentasjon nevner risikoen, deaktiverer dens vanlige bruksmønster i praksis en kritisk sikkerhetsmekanisme. Igjen, dette er nyttige verktøy, men standardkonfigurasjonene deres bytter sikkerhet mot bekvemmelighet på en måte som krever forsiktighet.

Sekundære risikoer: Datahåndtering og lekkende abstraksjoner

Utover eksplisitte tillatelser, observerte vi også dårlig sikkerhetspraksis som øker et systems angrepsflate eller lekker sensitiv informasjon, selv om det ikke utgjør aktiv skadevare.

Et eksempel er AI Search Hub. Wrapper-skriptet fungerer ved å kopiere brukerens fullstendige brukerdatakatalog for nettleseren – inkludert informasjonskapsler og aktive økter – inn i en lokal, gitignorert profilmappe (chrome_debug_profile_skill). Den eksponerer også Chrome DevTools Protocol på port 9222 på den lokale maskinen. Dette er ikke eksfiltrering; dataene forlater ikke den lokale maskinen. Imidlertid skaper det en lokal kopi av sensitive øktdata og åpner en kraftig feilsøkingsport, noe som utvider sprengningsradiusen for enhver annen lokal prosess som kan bli kompromittert.

Et annet eksempel er Google Ad Scraper. Denne ferdigheten sender sitt API-token som en URL-spørringsparameter (?token=...) i stedet for i en Authorization-header. Spørrestrenger er det verste stedet å plassere en hemmelighet: de havner i skallhistorikk, server-tilgangslogger og enhver proxy i banen. Den samme ferdigheten sender også dette tokenet til et tredjeparts endepunkt, api.gooseworks.ai, når en tilsvarende nøkkel er satt. Dette er ikke ondsinnede handlinger, men en unnlatelse av å følge standard praksis, og de skaper en eksponering du ikke har bedt om. For mer om dette emnet, se vår oversikt over sikkerhet i Claude-ferdigheter.

Den konstruktive siden: Ferdigheter som forbedrer sikkerheten

Økosystemet av ferdigheter er ikke bare en kilde til potensiell risiko; det er også en kilde til kraftige verktøy for å redusere den. Det samme rammeverket som lar en ferdighet samhandle med filsystemet ditt, lar også en ferdighet revidere det for sårbarheter. Vi har testet flere ferdigheter designet spesifikt for sikkerhetsgjennomganger.

Skill Security Auditor er et fremragende eksempel. Vi testet den mot en 13-linjers fil som inneholdt åpenbar SQL-injeksjon, kommandoinjeksjon og en hardkodet API-nøkkel. Analyse-skriptene identifiserte vellykket alle tre sårbarhetene. Som en bonus flagget den også en manglende .gitignore-fil, et problem en menneskelig revisor hadde oversett.

Tilsvarende kjørte vi Code Health Check mot den bevisst feilbeherskede Express API-en som ferdigheten leverer i sitt eget repository. Den fant alle de åtte plantede problemene, som inkluderte SQL-injeksjon, en eval()-basert konfigurasjonsparser, to hardkodede hemmeligheter, en svelget feil og en død funksjon. Den ga korrekte alvorlighetsgrader og presise fil- og linjenummerhenvisninger for hver.

Disse verktøyene demonstrerer den andre siden av ferdighetenes kapabiliteter. Ved å gi en klarert revisjonsferdighet kontrollert tilgang til koden din, kan du automatisere deler av sikkerhetsgjennomgangen din. Du kan finne flere verktøy som dette i vår guide til Claude-ferdigheter for sikkerhetsgjennomgang.

Hvordan beskytte deg selv: En praktisk trusselmodell

Gitt at den primære trusselen er overdreven tildeling av tillatelser heller enn skadevare, endres forsvarsstrategien. Det handler mindre om antivirus og mer om operasjonell disiplin.

1. Anta gode intensjoner, verifiser omfang: Utvikleren av ferdigheten du installerer, prøver sannsynligvis ikke å hacke deg. Men de kan ha vært uforsiktige eller prioritert bekvemmelighet over sikkerhet. Når en ferdighet ber om tillatelser, les meldingen. Hvis den ber om skrivetilgang til hele hjemmekatalogen din for å legge til en linje i en enkelt konfigurasjonsfil, nekt det.

2. Foretrekk ferdigheter med liten sprengningsradius: Se etter ferdigheter som er selvstendige og følger prinsippet om minste privilegium. Et godt eksempel på dette er Workthreads. Det er en selvstendig ferdighet uten avhengigheter. Den kaller kun git via execFileSync med faste array-argumenter for å forhindre kommandoinjeksjon, og den leveres med innebygd, deterministisk redigering av hemmeligheter for AWS, GitHub, Slack, OpenAI, Anthropic, JWT-er og bearer-tokens før den skriver ut noe. Den ble tydelig bygget med en liten, kontrollert sprengningsradius i tankene.

3. Kjør i en sandkasse: Ikke kjør en ny, ukjent ferdighet på din primære produksjonskodebase eller fra hjemmekatalogen din. Opprett en dedikert, engangs-katalog for testing. Bruk Docker eller andre container-teknologier for en enda sterkere grense.

4. Stol på kjøring, ikke bare kode: Den eneste måten å være sikker på hva en ferdighet gjør, er å kjøre den og observere oppførselen. Dette er det grunnleggende prinsippet i SkillProof sin metodikk. Vi publiserer våre testnotater, inkludert sikkerhetsadvarsler som de fem i denne artikkelen, for hver ferdighet vi kjører.

Relatert lesing: den praktiske oppfølgingen til denne artikkelen er hvordan en ferdighets 'allowed-tools'-deklarasjon faktisk avgrenser hva den kan røre, som er spaken de fleste av problemene over koker ned til. For hvordan det bredere økosystemet av lister beskriver seg selv versus hva det verifiserer, se vår virkelighetssjekk av kataloger.

Hver sikkerhetsadvarsel sitert her er offentlig på ferdighetens egen katalogside, sammen med dens dom og poengsum, slik at du kan lese bevisene før du installerer noe. Hvis du heller vil starte med et sett som allerede har vært gjennom dette, samler vår Security & Code Review Pack ti testede ferdigheter for kodegjennomgang, feilsøking og kontrakttesting.