Slik fjerner du «skjult kode» fra ChatGPT og andre LLM-er

Etter hvert som store språkmodeller (LLM-er) i økende grad genererer fungerende kode og integreres i utviklingsprosesser og agentstabler, er det en økende risiko for at skjult or skadelig instruksjoner – enten de er innebygd i modellutganger, injisert via nettsider eller tredjeparts plugins, eller introdusert under modelltrening – kan forårsake usikker oppførsel når koden kjøres.

Ifølge brukerrapporter som sirkulerer i utviklermiljøer, opplevde en programvareutvikler katastrofalt datatap – omtrent 800 GB med filer ble slettet, Herunder hele CursorAI-applikasjonen selv — etter å ha kjørt kode generert med hjelp fra Gemini 3 mens man jobber inne i CursorAI IDEEtter hvert som utviklere i økende grad er avhengige av LLM-er for kodegenerering, blir konsekvensene av ureviewede eller usikre skript mer alvorlige.

Derfor er det ganske viktig å vite hvordan man oppdager og fjerner farlige koder generert av LLM.

Hva er «skjult kode» i sammenheng med ChatGPT og LLM-er?

Hva mener folk med «skjult kode»?

«Skjult kode» er en paraplybetegnelse utviklere bruker for å beskrive innebygde instruksjoner eller kjørbart innhold i teksten (eller filene) som en LLM inntar eller sender ut, inkludert:

Instruksjoner i promptstil innebygd i brukerinnhold (f.eks. «Ignorer tidligere instruksjoner ...» skjult i en PDF).
Usynlige tegn eller mellomrom med null bredde som brukes til å skjule tokener eller bryte tokeniseringsantagelser.
Kodede nyttelaster (base64, URL-kodet, steganografiske innebygginger i bilder eller dokumenter).
Skjult HTML/JS eller skriptblokker inkludert i formatert innhold som kan tolkes av nedstrøms renderere.
Metadata eller annoteringer (filkommentarer, skjulte lag i PDF-filer) som instruerer gjenfinningssystemer eller modellen.
Implisitt atferd som følge av generert kode som bruker farlige API-er (f.eks. eval, exec, subprocess, eller nettverks-/systemkall) – selv når hensikten ikke er eksplisitt ondsinnet.
Instruksjoner som er injisert med prompt som får modellen til å generere kode som inkluderer skjulte kommandoer eller bakdørlignende logikk fordi en angriper konstruerte ledeteksten eller konteksten.

Disse angrepsvektorene kalles ofte rask injeksjon or indirekte rask injeksjon når målet er å endre modellens atferd. Sikkerhetsmiljøet behandler nå umiddelbar injeksjon som en sentral LLM-sårbarhet, og OWASP har formalisert det som en LLM-risikokategori.

Hvordan er dette forskjellig fra vanlig skadelig programvare eller XSS?

Forskjellen er semantisk lag: rask injeksjon retter seg mot modellens instruksjonsfølgende oppførsel snarere enn vertsoperativsystemet eller nettleserens gjengivelsesmotor. Når det er sagt, er skjult HTML eller skript som ender opp med å kjøre i en web-renderer fortsatt et kjørbart angrep (XSS-lignende); både semantiske og utførelseslag må forsvares. Bransjeledere og forskere har kalt rask injeksjon en «grensesikkerhetsutfordring» og fortsetter å publisere tiltak for å redusere dette.

Hvorfor kan LLM produsere skjult eller farlig kode?

Modellatferd, treningsdata og instruksjonskontekst

LLM-er er trent til å produsere troverdige fortsettelser gitt kontekst og instruksjoner. Hvis konteksten inneholder motstridende signaler, eller hvis en bruker ber modellen om kode som utfører kraftige handlinger, kan modellen sende ut kode som inkluderer subtil eller aktiv atferd.

LLM-er produserer plausibel, men usikker kode

LLM-er er optimalisert for flyt og nytteverdi, ikke for sikkerhet i nærvær av destruktive bivirkninger. De vil gjerne generere en konsis tekst. rm -rf /path/to/dir or shutil.rmtree() ringe når de blir bedt om å «rydde opp» – og fordi svarene deres ofte er formulert med selvtillit, kan brukere kopiere og kjøre uten tilstrekkelig gransking. Dette problemet med «selvsikre hallusinasjoner» er grunnen til at tilsynelatende uskyldige forespørsler blir farlige.

Automatisering av obfuskasjonsarbeidsflyter

Trusselaktører automatiserer nå kodeforvirring ved å kjede sammen LLM-kall: én modell genererer en nyttelast, en annen omarbeider den for å unngå signaturdeteksjon, og så videre. Bransjetrusselrapporter og leverandøranalyser i 2025 dokumenterer denne «AI-assisterte forvirringen» som en fremvoksende teknikk.

Hvordan kan du oppdage skjult kode i modellutganger?

Rask sjekkliste for triage

Skann etter usynlig/uvanlig Unicode (koblingstegn med null bredde, mellomrom med null bredde, byteordensmerker, ikke-ASCII-homoglyfer).
Kjør statisk analyse / AST-parsing å identifisere bruken av kraftige API-er (eval, exec, subprocess, os.system, reflekterende samtaler).
Se etter kodede nyttelaster (base64, heksadesimale klatter, gjentatte lange strenger eller komprimert innhold).
Se etter obfuskasjonsmønstre (strengsammenkobling som konstruerer API-navn, tegnregning, chr() kjeder).
Bruk semantisk analyse for å bekrefte om koden faktisk utfører I/O, nettverk eller filsystemmutasjon.

Statisk mønsterdeteksjon (rask, første linje)

Språkbevisst parsing og linting. Parser generert utdata umiddelbart til kodeblokker kontra prosa. Kjør formateringsprogrammer og linterprogrammer (Black/Prettier, pylint, eslint). Lint-regler bør flagge bruk av eval, exec, rm -rf, rå delprosesskall eller skallrør som konstruerer kommandoer dynamisk.
Token- og strengmønsterskannere. Søk etter tokens og mønstre med høy risiko: sudo, absolutte stier som /home/, C:\, rm -rf, shutil.rmtree, subprocess.Popen, innebygde base64-blobs, lange strenger som ikke kan tolkes, og tull som bytter tolkekontekst.
Hemmelig skanning og opprinnelsessjekk. Oppdag hardkodet legitimasjon, URL-er som peker mot upålitelige registre eller kode som dynamisk henter pakker fra vilkårlige kilder.

Statisk analyse fanger opp mange åpenbare problemer raskt og er billig å kjøre som en del av en CI-gate.

Semantisk og kontekstuell deteksjon (dypere)

Intensjonsanalyse. Bruk en sekundær modell eller en regelmotor for å klassifisere den genererte kodens intensjon: er den «lese», «skrive», «slette», «nettverk», «installere»? Alt som er kategorisert som sletting/skriving bør utløse eskalering.
Dataflytanalyse. Analyser koden for å oppdage om uvaliderte eller brukeroppgitte stier kan nå destruktive API-er. Hvis for eksempel en variabel avledet fra en LLM-utdata eller en ekstern fil senere blir sammenkoblet til en skallkommando, flagg den.
Provenienskorrelasjon. Hold fullstendig oversikt over samtalen, systemprompten og kontekstsider. Hvis mistenkelige utdata korrelerer med et bestemt eksternt dokument eller plugin-kall, kan det tyde på prompt injeksjon eller en forurenset kontekst.

Dynamisk og atferdsmessig deteksjon (mest pålitelig)

Sandkassekjøring med overvåking. Kjør generert kode i et strengt begrenset, flyktig miljø uten nettverk, vertsmonteringer og systemanropsfiltrering (seccomp). Overvåk filsystemaktivitet, forsøk på nettverkskall, prosessutvikling og uvanlig I/O.
Kanarifugltesting. Før du kjører på ekte data, kjør koden mot syntetiske kataloger som inneholder sentinelfiler; overvåk for slettinger eller overskrivinger.
Atferdsheuristikker. Se etter løkker som går gjennom overordnede mapper, rekursive operasjoner uten dybdesjekker, eller navneendringer av mønstre som kan skade mange filer (f.eks. gjentatte ganger skrive samme filnavn).
Dynamisk analyse er den eneste måten å oppdage nyttelaster som er tilslørt, forsinket eller bare utløst under kjøretid.

Hvordan bør du fjerne eller nøytralisere skjult kode før du kjører LLM-utdata?

Defensiv fjerning kontra endring av semantikk

Det er to mål når man «fjerner skjult kode»:

sanitization — fjern innhold som tydelig ikke er koderelatert eller mistenkelig (usynlig Unicode, tegn med null bredde, tilføyd base64-nyttelast). Dette skal ikke endre den tiltenkte, godartede logikken.
Nøytralisering – for alt som utfører eller kaller eksterne tjenester, deaktiver disse kallene eller gjør dem til no-ops før de er bekreftet.

Foretrekker alltid nøytralisering + gjennomgang over blind sletting: vilkårlig fjerning av deler av kode kan føre til ødelagt eller uventet oppførsel. Erstatt i stedet mistenkelige konstruksjoner med eksplisitte, loggede stubber som feiler på en sikker måte (genererer unntak eller returnerer sikre standardverdier).

Trinn 1 – Behandle generert kode som upålitelige data

Kjør aldri kode direkte fra ChatGPT (eller noen LLM) uten å sende den gjennom en fjernings- og herdingsprosess. Denne prosessen bør håndheves av en policy og automatiseres i CI/CD.

Trinn 2 – Pakk ut og kanoniser kode

Normaliser tekst og fjern tegn med nullbreddeFjern tegn som U+200B, U+200C, U+200D, U+FEFF og andre kodepunkter med null bredde/formatering. Logg det som ble fjernet for revisjon. Dette trinnet eliminerer mange «skjulte» kodinger som brukes for visuell stealth.
Fjern all ikke-kodekontekstFjern narrative, skjulte kommentarer og eventuelle HTML/Markdown-innpakninger. Konverter kode til kanonisk form ved hjelp av språkformateringer (svart, penere) slik at obfuskerte mellomrom eller kontrolltegn normaliseres.
Avvis eller sett kode i karantene med disse konstruksjonenedynamisk eval, rå delprosesskall (os.system, subprocess.Popen), innebygde base64-blober dekodet til utførelse, eller innebygd #! direktiver som forsøker å endre tolkens kontekst. Normaliser tekst og fjern tegn med nullbredde
Fjern tegn som U+200B, U+200C, U+200D, U+FEFF og andre kodepunkter med null bredde/formatering. Logg det som ble fjernet for revisjon. Dette trinnet eliminerer mange «skjulte» kodinger som brukes for visuell stealth.

Trinn 3 – Analyser inn i AST og erstatt risikable noder

Når koden er analysert inn i en AST, finn noder som kaller dynamisk utførelse (f.eks. exec), eller som programmatisk bygger funksjonsnavn. Erstatt dem med sikre stubber som genererer et kontrollert unntak som indikerer «usikker dynamisk oppførsel blokkert». Generer en renset kopi av den AST-støttede kildekoden for gjennomgang. Kjør sikkerhetsmønsterkontroller (tilpassede semgrep-regler for miljøet ditt). Der det finnes treff, merk og nøytraliser dem.

Trinn 4 – Statisk herding og omskriving

Automatisert omskriving: passkode gjennom en automatisk desinfiseringsenhet som erstatter farlige anrop med sikre innpakninger – f.eks. erstatte os.system() / subprocess med en godkjent sandkasse-utfører som håndhever tidsavbrudd og nettverksblokkeringer.
KapabilitetsstyringEndre eller fjern API-nøkler, tokener eller kall til privilegerte endepunkter; erstatt dem med simulerte adaptere for lokal testing. Forhindre utilsiktet inkludering av hemmeligheter eller URL-er.
Avhengighetsomskrivingerblokkdynamikk pip / npm installasjoner opprettet av koden. Krever at avhengigheter deklareres og godkjennes via registeret ditt.

Trinn 5 – Kjør inne i en aggressiv sandkasse

Kortvarige containere / mikro-VM-erUtfør koden i en container/VM som ikke har nettverk, ingen tilgang til vertslegitimasjon og begrenset tilgang til filsystemet. Teknologier som gVisor, Firecracker eller dedikerte flyktige utførelsestjenester er passende. Hvis kode må ha tilgang til I/O, bruk en proxy som håndhever policyen.
Systemkallfiltre og seccomp: begrenser hvilke systemanrop som er tillatt. Filskrivinger utenfor en midlertidig katalog bør blokkeres.
Ressurs-/tidsgrenser: sett CPU/minne/tidsgrenser slik at selv logiske bomber ikke kan kjøre i det uendelige.

Utførelse av sandkasser pluss overvåking avdekker ofte nyttelaster som statiske kontroller overser. Bransjeveiledning og nylige rapporter anbefaler sandkasser som en sentral avbøtende faktor.

Hvilke automatiserte verktøy og regler bør være i pipelinen din?

Anbefalte verktøykjedekomponenter

Unicode sanitærmodul (tilpassede eller eksisterende biblioteker). Må logge normaliserte tegn.
Parser + AST-analysator for hvert målspråk (Python ast, typed-ast, JavaScript-parsere, Java-parsere).
Statiske analysatorer / SASTBandit (Python), Semgrep (flerspråklig, tilpassbar), ESLint med sikkerhetsplugins.
Entropi og dekoderheuristikker: oppdag base64/hex/gzip og rute til inspeksjon.
Sandkasse-kjøretidminimal container med streng seccomp/AppArmor-profil eller språknivåtolk med deaktiverte systemanrop.
Retningslinjehåndhever: en komponent som bestemmer tillatte moduler, tillatte endepunkter og sikre API-innpakninger.
Tilsynsspor: uforanderlige logger som registrerer original utdata, renset utdata, differanser og avgjørelser.

Eksempel på semgrep-mønstre (konseptuelle)

Bruk korte, konservative regler som markerer bruk av farlige funksjoner. For eksempel:

Flagg eval, exec, Function konstruktør (JS), dynamisk import eller strengbygde API-navn.
Flagg nettverksanrop utenfor tillatelseslisten (f.eks. requests.get til ukjente verter).
Flaggskrivinger til sensitive stier (/etc, systemmapper) eller oppstart av prosesser.

(Behold disse som konfigurasjonselementer per organisasjon og stram dem inn over tid.)

Hva er praktiske desinfiseringssnutter (sikre eksempler)?

Nedenfor finner du ufarlige, defensive eksempler du kan tilpasse. De er desinfisering og deteksjon snippets – ikke utnyttelsesinstruksjoner.

Eksempel: fjern tegn med null bredde (Python, defensiv)

import re
ZERO_WIDTH_RE = re.compile(r'')
def strip_zero_width(s: str) -> str:
    cleaned = ZERO_WIDTH_RE.sub('', s)
    return cleaned

Dette fjerner tegn som angripere ofte bruker for å skjule kode i ellers synlig tekst. Logg alltid det som ble fjernet, og behandle fjerningen som en del av revisjonssporet.

Eksempel: analysere og inspisere AST (Python, konseptuelt)

import ast

def has_dynamic_exec(source: str) -> bool:
    tree = ast.parse(source)
    for node in ast.walk(tree):
        if isinstance(node, ast.Call):
            if getattr(node.func, 'id', '') in ('eval', 'exec',):
                return True
        if isinstance(node, ast.Attribute):
            if getattr(node, 'attr', '') in ('popen', 'system'):
                return True
    return False

If has_dynamic_exec returnerer True, ikke kjør koden; erstatt i stedet den dynamiske noden med en sikker stub og krev gjennomgang.

Merk: Disse eksemplene er av defensiv karakter. Ikke fjern logging, revisjon eller menneskelig gjennomgang fra pipelinen din.

Avsluttende tanker: Behandle LLM-utdata som upålitelig kode, alltid

LM-er er kraftige produktivitetsverktøy – de kan produsere elegant kode, akselerere utkast og automatisere rutinearbeid. Men der de møter utførelse, endres sikkerhetsreglene: modellutganger må behandles som upålitelige artefakterKombinasjonen av raske injeksjoner, bakdørsforskning og avsløringer av sårbarheter i den virkelige verden de siste 18–30 månedene viser et klart poeng: risikoflaten har vokst og vil fortsette å utvikle seg.

Praktiske forsvar som kombinerer parsing, statisk analyse, sandkassebasert dynamisk testing, styring og kontinuerlig red-teaming vil stoppe de fleste angrep. Men team må også investere i organisatoriske kontroller: færrest rettigheter, proveniens og en kultur som antar at LLM-utdata må verifiseres. Bransjen bygger verktøy og rammeverk for å gjøre disse mønstrene enklere; samtidig reduserer bruken av sjekklisten ovenfor sjansen for at en skjult nyttelast forsvinner.

Utviklere kan få tilgang til det nyeste LLM API-et, for eksempel Claude Sonnet 4.5 API og Gemini 3 Pro forhåndsvisning osv. gjennom CometAPI, den nyeste modellversjonen er alltid oppdatert med den offisielle nettsiden. For å begynne, utforsk modellens muligheter i lekeplass og konsulter API-veiledning for detaljerte instruksjoner. Før du får tilgang, må du sørge for at du har logget inn på CometAPI og fått API-nøkkelen. CometAPI tilby en pris som er langt lavere enn den offisielle prisen for å hjelpe deg med å integrere.

Klar til å dra? → Registrer deg for CometAPI i dag !

Hvis du vil vite flere tips, guider og nyheter om AI, følg oss på VK, X og Discord!