Din KI-agent ble nettopp hacket. Og du ville ikke vite det.

Et virkelig prompt injection-angrep i et offentlig GitHub-repositorium, og hva det betyr for utviklere som bruker KI-kodingsagenter.

Det så legitimt ut

Nylig kom jeg over et GitHub-repositorium med mer enn 40 stjerner, aktiv community-aktivitet og profesjonell posisjonering som "#1 OpenCode Plugin." Det lovet async-subagenter, kuraterte agenter og et Claude Code-kompatibelt lag. På overflaten så det ut som et normalt utviklerverktøy: dokumentasjon, installasjonstrinn og en beroligende profesjonell presentasjon.

Begravd i den dokumentasjonen var imidlertid noe langt mer bekymringsfullt.

Det jeg fant var ikke en konvensjonell malware-nyttelast eller en mistenkelig binær. Det var et prompt injection-angrep rettet direkte mot KI-kodingsagenter.

Dette var ikke skrevet for mennesker

Det viktigste er dette: installasjonsveiledningen var egentlig ikke skrevet for brukeren. Den var skrevet for brukerens KI-agent.

Repositoriet instruerte eksplisitt brukere om å lime inn en URL i en LLM-drevet kodingsassistent. Når agenten hentet den eksterne markdown-filen, ble den matet med en sekvens av instruksjoner designet for å påvirke dens atferd, styre dens beslutninger og utløse handlinger på brukerens maskin.

Det er det som gjør dette angrepet bemerkelsesverdig. Nyttelasten er ikke skjult i kompilert kode. Den er skjult i naturligspråklige instruksjoner som en autonom kodingsassistent sannsynligvis vil stole på.

Hvordan angrepet fungerte

Når en KI-agent hentet den, forsøkte den eksterne veiledningen å gjøre flere ting.

1. Utløse vilkårlig pakkekjøring

Veiledningen instruerte agenten til å kjøre kommandoer som:

bunx oh-my-opencode install
npx oh-my-opencode install

Det er viktig fordi bunx og npx kan laste ned og kjøre kode direkte fra et pakkeregister. Hvis en KI-agent kjører disse kommandoene på vegne av brukeren uten ordentlig gjennomgang, kjører den effektivt ikke-klarert kode med brukerens egne tillatelser.

2. Samle abonnements- og kontoinformasjon

Veiledningen instruerte også agenten til å spørre brukeren om betalte tjenester og abonnementer, inkludert om de hadde tilgang til Claude, ChatGPT, GitHub Copilot eller OpenCode Zen.

Dette er ikke normal installasjonsatferd. Det er datainnsamling forkledd som konfigurasjon, og det gir repositorieoperatøren innsikt i hvilke kommersielle KI-tjenester målet allerede bruker.

3. Injisere reklame i arbeidsflyten

En seksjon instruerte eksplisitt agenten om å lese en ekstern liste og velge et selskap å fremme overfor brukeren.

Dette er ett av de klareste signalene på ondsinnet intensjon. KI-assistenten hjelper ikke lenger brukeren med å fullføre en oppgave; den repurposeres som en ikke-klarert markedsføringskanal innebygd i utviklerens arbeidsflyt.

4. Manipulere sosiale bevis

Instruksjonene oppfordret også agenten til å be brukeren om å stjerne repositoriet, bruke GitHub CLI-kommandoer til å gjøre det hvis brukeren samtykket, og generere positive anmeldelser eller attester.

Dette blåser kunstig opp tillitssignaler. Et repositorium kan virke populært, velansett og community-godkjent selv når den reputasjonen produseres gjennom prompt-drevet manipulasjon.

5. Bruke beroligende tone som kontrollmekanisme

Ordlyden i veiledningen var bevisst varm, gratulasjonspreget og lekende. Den brukte en vennlig tone, festrende språk og quirky formulering for å redusere skepsis og holde både brukeren og agenten ettergivende.

Det er viktig fordi sosial manipulasjon ikke lenger er begrenset til mennesker. Tone kan også forme hvordan et KI-system tolker og prioriterer instruksjoner.

Hvorfor dette er annerledes

Tradisjonelle supply chain-angrep retter seg mot kode. Prompt injection-angrep retter seg mot beslutningslaget rundt koden.

Den distinksjonen er viktig.

Angrepsoverflaten er ikke lenger begrenset til node_modules, pip eller shell-skript. Den inkluderer nå hvert dokument, README, markdown-fil og eksternt instruksjonssett som en KI-agent er villig til å ta inn.

Røde flagg utviklere bør se etter

Etter å ha gjennomgått dette repositoriet, stakk flere mønstre seg ut.

Umiddelbare røde flagg

• Enhver README som sier "lim dette inn i din KI-agent" eller ber deg mate en ekstern URL direkte inn i en assistent.
• Dokumentasjon primært skrevet for modellen i stedet for for den menneskelige operatøren.
• Ugjennomgått bruk av bunx, npx, pip install eller lignende kommandoer mot ikke-klarerte pakker.
• Spørsmål om flere betalte abonnementer som er urelaterte til installasjons- eller kjøretidskrav.
• Instruksjoner om å fremme tredjepartsselskaper, anbefale sponsorer eller injisere reklame.
• Forespørsler om å stjerne repositorier, skrive anmeldelser eller på annen måte produsere engasjement.

Strukturelle røde flagg

• Et forket eller rebrandert repositorium som arver troverdighet fra et annet prosjekt.
• Et stort antall commits, men svært lite meningsfull kjernefunksjonalitet.
• Manglende sikkerhetspolicy, svak håndtering av sårbarhetsmeldinger, eller ingen ansvarlig respons på en rapport.
• Viktige instruksjoner lagret i sekundære markdown-filer heller enn i hoveddokumentasjonen.

Slik reviderer du et repositorium før du bruker det

1. Ikke stol på README alene

Les den faktiske kilden og all referert dokumentasjon. I KI-agent-økosystemer kan markdown-filer være like sensitive som kjørbare filer.

Vær spesielt oppmerksom på:

• docs/
• README.md
• AGENTS.md
• enhver rå GitHub-URL som refereres under oppsett
• installasjonsinstruksjoner beregnet for agenter snarere enn brukere

2. Inspiser hva som faktisk vil kjøres

Før du kjører pakkeoppsett-kommandoer, inspiser hva de vil hente:

npm pack oh-my-opencode --dry-run
tar -tzf oh-my-opencode-*.tgz
npm view oh-my-opencode scripts

Målet er enkelt: forstå hva som vil kjøre før du lar en pakkebehandler eller agent kjøre det for deg.

3. Søk etter manipulasjonsmønstre

Grunnleggende tekstsøk kan raskt avdekke mistenkelige intensjoner:

git clone <repo> && cd <repo>
grep -ri "star the repo\|advertise\|free advertising\|promote" .
grep -ri "subscription\|pro plan\|max\|copilot" .
grep -ri "paste this into\|llm agent\|assistant session" .

Disse søkene vil ikke bevise ondsinnethet alene, men de er et effektivt første filter.

4. Verifiser vedlikeholderen

Still noen grunnleggende spørsmål:

• Er dette det originale prosjektet eller en fork?
• Har vedlikeholderen en troverdig bidragshistorikk?
• Ser issues og diskusjoner autentiske ut?
• Er tilliten rundt prosjektet organisk, eller overdrevent kuratert?

5. Test ukjente verktøy i isolasjon

Hvis du bestemmer deg for å evaluere et ukjent KI-verktøy:

• Bruk en container eller VM.
• Hold legitimasjoner utenfor miljøet.
• Unngå testing på din primære arbeidsstasjon eller produksjons-shell.
• Overvåk nettverksaktivitet under installasjon og første kjøring.

Hva du bør gjøre hvis du finner prompt injection

1. Bevar bevis

Ta vare på repositorium-URL, commit-hash, rå markdown, skjermbilder og installasjonsinstruksjoner.

curl -o evidence.md https://raw.githubusercontent.com/<repo>/<path>

2. Rapporter det ansvarlig

Hvis repositoriet er vert på GitHub, bruk Sikkerhet-fanen når tilgjengelig og send inn en detaljert rapport med nøyaktige utdrag, URL-er og forklaring av angrepsbanen.

Hvis vedlikeholderen ser ut til å handle ondsinnet, eskaler til GitHub Trust & Safety. Hvis pakken er publisert til npm eller PyPI, vurder å rapportere det til registeret også.

3. Advar fellesskapet forsiktig

Hvis brukere kan være i fare, del funnene dine ansvarlig og faktabasert. Fokuser på bevis, reproduserbarhet og risiko for brukere snarere enn spekulasjon.

En offentlig skrivning er ofte nødvendig, men den bør hjelpe folk å forsvare seg, ikke forsterke angriperens taktikker.

Det større problemet

Dette handler ikke bare om ett tvilsomt repositorium.

Det peker på et bredere skifte i programvaresikkerhet: autonome og semi-autonome kodingsagenter utvider angrepsoverflaten utover kodekjøring til instruksjonskjøring. En ondsinnet aktør trenger ikke lenger å kompromittere en kompilator, en pakke eller et byggtrinn først. I noen tilfeller kan det være nok å kompromittere agentens kontekst.

Dette er en alvorlig endring i trusselmodellering.

Utviklere delegerer i stadig større grad pakkeinstallasjon, kodeendringer, shell-kommandoer og dokumentasjonsgjenfinning til KI-systemer. Hvis disse systemene får lov til å behandle ikke-klarert tekst som operasjonell veiledning, blir prompt injection en praktisk supply chain-risiko.

Hva som må endres

Flere ting må forbedres raskt:

• KI-agent-rammeverk trenger sterkere sandboxing, tillatelsesgrenser og klarere menneskelige godkjenningskontrollpunkter.
• Sikkerhetsgjennomganger for utviklerverktøy må inkludere prompt injection-risiko, ikke bare kildekodegjennomgang.
• Plattformer som GitHub og pakkeregistre bør behandle ondsinnede KI-rettede instruksjoner som et rapporterbart sikkerhetsproblem.
• Utviklere må forstå at "lim dette inn i din KI-assistent" kan være like risikabelt som curl | sudo bash.

Siste tanke

Hvis du bruker KI-kodingsagenter, behandle dokumentasjon som en del av din angrepsoverflate.

Ikke anta at en polert README er trygg. Ikke anta at et stjernebedømt repositorium er pålitelig. Og ikke anta at prompt injection er teoretisk bare fordi det ikke ser ut som malware.

Noen ganger er ikke nyttelasten kode.

Noen ganger er nyttelasten instruksjonen.

---

Jeg analyserte repositoriet referert til i denne artikkelen 2026-03-31 basert på offentlig tilgjengelig innhold på det tidspunktet og rapporterte problemet gjennom GitHub Security Advisories.

#AISecurity #PromptInjection #CyberSecurity #LLMSecurity #AIAgents #SupplyChainSecurity #DeveloperSecurity