Hoe u 'verborgen code' uit ChatGPT en andere LLM's verwijdert

Omdat grote taalmodellen (LLM's) steeds vaker werkende code genereren en worden geïntegreerd in ontwikkelingspijplijnen en agent stacks, is er een toenemend risico dat verborgen or kwaadaardig Instructies — of ze nu zijn ingebed in de uitvoer van modellen, zijn ingevoegd via webpagina's of plug-ins van derden, of zijn geïntroduceerd tijdens de training van het model — kunnen onveilig gedrag veroorzaken wanneer die code wordt uitgevoerd.

Volgens gebruikersrapporten die in ontwikkelaarsgemeenschappen circuleren, heeft een softwareontwikkelaar een catastrofaal gegevensverlies ervaren - ongeveer 800 GB aan bestanden zijn verwijderd, Waaronder de volledige CursorAI-applicatie zelf — na het uitvoeren van code die is gegenereerd met hulp van Tweeling 3 terwijl ik binnen werk CursorAI IDEOmdat ontwikkelaars steeds meer vertrouwen op LLM's voor het genereren van code, worden de gevolgen van niet-gecontroleerde of onveilige scripts ernstiger.

Daarom is het van groot belang om te weten hoe je de gevaarlijke codes die door LLM worden gegenereerd, kunt detecteren en verwijderen.

Wat is 'verborgen code' in de context van ChatGPT en LLM's?

Wat bedoelen mensen met “verborgen code”?

'Verborgen code' is een overkoepelende term die ontwikkelaars gebruiken om alle ingebedde instructies of uitvoerbare inhoud te beschrijven in de tekst (of bestanden) die een LLM opneemt of uitzendt, waaronder:

Snelle instructies ingebed in gebruikersinhoud (bijvoorbeeld: "Negeer eerdere instructies..." verborgen in een PDF).
Onzichtbare personages of spaties met een breedte van nul die worden gebruikt om tokens te verbergen of om aannames over tokenisatie te doorbreken.
Gecodeerde payloads (base64, URL-gecodeerd, steganografische insluitingen in afbeeldingen of documenten).
Verborgen HTML/JS of scriptblokken die zijn opgenomen in geformatteerde inhoud en die mogelijk door downstream-renderers kunnen worden geïnterpreteerd.
Metadata of annotaties (bestandsopmerkingen, verborgen lagen in PDF's) die instructies geven aan ophaalsystemen of het model.
Impliciete gedragingen die voortkomen uit gegenereerde code die gevaarlijke API's gebruikt (bijv. eval, exec, subprocess, of netwerk-/systeemoproepen) — zelfs als de intentie niet expliciet kwaadaardig is.
Snel geïnjecteerde instructies die ervoor zorgen dat het model code genereert die verborgen opdrachten of backdoor-achtige logica bevat, omdat een aanvaller de prompt of context heeft gemanipuleerd.

Deze aanvalsvectoren worden vaak genoemd snelle injectie or indirecte snelle injectie wanneer het doel is om het modelgedrag te veranderen. De beveiligingsgemeenschap beschouwt prompt injection nu als een kernkwetsbaarheid voor LLM en OWASP heeft het geformaliseerd als een LLM-risicocategorie.

Hoe verschilt dit van gewone malware of XSS?

Het verschil is de semantisch Laag: prompt injection richt zich op het instructievolggedrag van het model in plaats van op de host-OS of browserrendering-engine. Verborgen HTML of scripts die uiteindelijk in een webrenderer worden uitgevoerd, zijn echter nog steeds een uitvoerbare aanval (XSS-achtig); zowel de semantische als de uitvoeringslagen moeten worden verdedigd. Brancheleiders en onderzoekers noemen prompt injection een "grensverleggende beveiligingsuitdaging" en blijven mitigatiestrategieën publiceren.

Waarom kan een LLM verborgen of gevaarlijke code produceren?

Modelgedrag, trainingsgegevens en instructiecontext

LLM's worden getraind om plausibele voortzettingen te produceren, gegeven context en instructies. Als de context tegenstrijdige signalen bevat, of als een gebruiker het model vraagt om code die krachtige acties uitvoert, kan het model code produceren die subtiel of actief gedrag bevat.

LLM's produceren plausibele maar onveilige code

LLM's zijn geoptimaliseerd voor vloeiendheid en bruikbaarheid, niet voor veiligheid in de aanwezigheid van destructieve bijwerkingen. Ze zullen graag een beknopte samenvatting genereren. rm -rf /path/to/dir or shutil.rmtree() bellen wanneer hen gevraagd wordt om "op te ruimen" — en omdat hun antwoorden vaak zelfverzekerd geformuleerd zijn, kunnen gebruikers ze kopiëren en wegrennen zonder voldoende kritisch te zijn. Dit probleem van "zelfverzekerde hallucinatie" is de reden waarom ogenschijnlijk onschuldige verzoeken gevaarlijk worden.

Automatisering van verduisteringsworkflows

Dreigingsactoren automatiseren codeverduistering nu door LLM-aanroepen aan elkaar te koppelen: het ene model genereert een payload, een ander herwerkt deze om handtekeningdetectie te voorkomen, enzovoort. Rapporten over dreigingen in de sector en analyses van leveranciers uit 2025 beschrijven deze "AI-ondersteunde verduistering" als een opkomende techniek.

Hoe kun je verborgen code in modeluitvoer detecteren?

Snelle triage checklist

Scannen op onzichtbare/ongebruikelijke Unicode (nul-breedte-joiners, nul-breedte-spaties, bytevolgordemarkeringen, niet-ASCII-homogliefen).
Statische analyse/AST-parsing uitvoeren om het gebruik van krachtige API's te identificeren (eval, exec, subprocess, os.system, reflectieve oproepen).
Zoek naar gecodeerde payloads (base64, hex blobs, herhaalde lange strings of gecomprimeerde inhoud).
Controleer op verduisteringspatronen (string-concatenatie die API-namen construeert, karakterberekening, chr() kettingen).
Gebruik semantische analyse om te bevestigen of de code daadwerkelijk I/O, netwerken of bestandssysteemmutaties uitvoert.

Detectie van statische patronen (snel, eerste lijn)

Taalbewust parsen en linting. Parseer de gegenereerde output direct in codeblokken in plaats van proza. Voer formatters en linters uit (Black/Prettier, pylint, eslint). Lintregels moeten het gebruik van markeren. eval, exec, rm -rf, ruwe subprocesaanroepen of shell-pipes die dynamisch opdrachten construeren.
Token- en stringpatroonscanners. Zoek naar tokens en patronen met een hoog risico: sudo, absolute paden zoals /home/, C:\, rm -rf, shutil.rmtree, subprocess.Popen, inline base64 blobs, lange niet-interpreteerbare strings en shebangs die de interpretercontext veranderen.
Geheime scans en herkomstcontroles. Detecteer hardgecodeerde referenties, URL's die verwijzen naar niet-vertrouwde registers of code die dynamisch pakketten uit willekeurige bronnen ophaalt.

Statische analyse spoort veel voor de hand liggende problemen snel op en is goedkoop uit te voeren als onderdeel van een CI-gate.

Semantische en contextuele detectie (dieper)

Intentieanalyse. Gebruik een secundair model of een regelengine om de intentie van de gegenereerde code te classificeren: is het "lezen", "schrijven", "verwijderen", "netwerk", "installeren"? Alles wat gecategoriseerd is als verwijderen/schrijven zou escalatie moeten activeren.
Gegevensstroomanalyse. Analyseer de code om te detecteren of niet-gevalideerde of door de gebruiker aangeleverde paden destructieve API's kunnen bereiken. Als een variabele die is afgeleid van een LLM-uitvoer of een extern bestand bijvoorbeeld later wordt samengevoegd met een shell-opdracht, markeer deze dan.
Herkomstcorrelatie. Houd een volledig overzicht bij van het gesprek, de systeemprompt en de contextpagina's. Als verdachte uitvoer correleert met een specifiek extern document of een plugin-aanroep, kan dit wijzen op promptinjectie of een besmette context.

Dynamische en gedragsdetectie (meest betrouwbaar)

Sandbox-uitvoering met monitoring. Voer gegenereerde code uit in een strikt beperkte, tijdelijke omgeving zonder netwerk, hostkoppelingen en systeemoproepfiltering (seccomp). Bewaak de activiteit van het bestandssysteem, netwerkaanroepen, processpawning en ongebruikelijke I/O.
Kanarie-test. Voer de code uit op synthetische mappen die sentinelbestanden bevatten, voordat u de code op echte gegevens uitvoert. Controleer op verwijderingen en overschrijvingen.
Gedragsheuristiek. Zoek naar lussen die bovenliggende mappen doorkruisen, recursieve bewerkingen zonder dieptecontrole of hernoemingspatronen die veel bestanden kunnen beschadigen (bijvoorbeeld herhaaldelijk dezelfde bestandsnaam schrijven).
Dynamische analyse is de enige manier om payloads te detecteren die verduisterd, vertraagd of alleen tijdens runtime geactiveerd zijn.

Hoe moet u verborgen code verwijderen of neutraliseren voordat u LLM-uitvoer uitvoert?

Defensieve verwijdering versus het veranderen van de semantiek

Het ‘verwijderen van verborgen code’ heeft twee doelen:

sanering — verwijder inhoud die duidelijk niet-code of verdacht is (onzichtbare Unicode, tekens met een breedte van nul, toegevoegde base64-payloads). Dit zou de beoogde, onschuldige logica niet mogen veranderen.
neutralisatie — Schakel alle externe services die worden uitgevoerd of aangeroepen, uit of maak ze no-ops totdat ze zijn geverifieerd.

Altijd de voorkeur geven neutralisatie + beoordeling Over blind verwijderen: het willekeurig verwijderen van codedelen kan leiden tot defect of onverwacht gedrag. Vervang in plaats daarvan verdachte constructies door expliciete, geregistreerde stubs die veilig falen (uitzonderingen genereren of veilige standaardwaarden retourneren).

Stap 1: Behandel gegenereerde code als niet-vertrouwde gegevens

Voer nooit code rechtstreeks vanuit ChatGPT (of een LLM) uit zonder deze via een verwijderings- en beveiligingspijplijn te leiden. Deze pijplijn moet door beleid worden afgedwongen en geautomatiseerd in CI/CD.

Stap 2 — Code extraheren en canoniseren

Normaliseer tekst en verwijder tekens met een breedte van nul: Verwijder tekens zoals U+200B, U+200C, U+200D, U+FEFF en andere codepoints met een breedte van nul/opmaak. Registreer wat er is verwijderd voor controle. Deze stap verwijdert veel "verborgen" coderingen die worden gebruikt voor visuele stealth.
Verwijder alle niet-codecontext: verwijder verhaal, verborgen opmerkingen en HTML/Markdown-wrappers. Converteer code naar canonieke vorm met behulp van taalformatters (Black, Prettier), zodat verborgen witruimte of controletekens worden genormaliseerd.
Code met deze constructies afwijzen of in quarantaine plaatsen: dynamisch eval, ruwe subproces-aanroepen (os.system, subprocess.Popen), inline base64 blobs gedecodeerd in uitvoering, of ingebed #! richtlijnen die de tolkcontext proberen te verschuiven. Normaliseer tekst en verwijder tekens met een breedte van nul
Verwijder tekens zoals U+200B, U+200C, U+200D, U+FEFF en andere codepoints met een breedte van nul/opmaak. Registreer wat er is verwijderd voor controle. Deze stap elimineert veel "verborgen" coderingen die worden gebruikt voor visuele stealth.

Stap 3 — Parseren in AST en riskante knooppunten vervangen

Zoek, met de code die in een AST is geparseerd, naar knooppunten die dynamische uitvoering aanroepen (bijv. exec), of die programmatisch functienamen bouwen. Vervang ze door veilige stubs die een gecontroleerde uitzondering genereren die aangeeft dat "onveilig dynamisch gedrag geblokkeerd" is. Genereer een gesaneerde kopie van de AST-ondersteunde bron ter beoordeling. Voer beveiligingspatrooncontroles uit (aangepaste semgrep-regels voor uw omgeving). Markeer en neutraliseer gevonden overeenkomsten.

Stap 4 — Statisch verharden en herschrijven

Geautomatiseerd herschrijven: geef code door aan een geautomatiseerde sanitizer die gevaarlijke oproepen vervangt door veilige wrappers, bijvoorbeeld door os.system() / subprocess met een goedgekeurde sandbox-uitvoerder die time-outs en netwerkblokkeringen afdwingt.
Capaciteitsbeperking: wijzig of verwijder API-sleutels, tokens of aanroepen naar geprivilegieerde eindpunten; vervang ze door mock-adapters voor lokale tests. Voorkom onbedoelde toevoeging van geheimen of URL's.
Afhankelijkheidsherschrijvingen: blok dynamisch pip / npm Installaties die door de code zijn gemaakt. Vereist dat afhankelijkheden via uw register worden gedeclareerd en goedgekeurd.

Stap 5 — Run in een agressieve sandbox

Tijdelijke containers / microVM's: voer de code uit in een container/VM zonder netwerk, zonder toegang tot hostreferenties en met beperkte toegang tot het bestandssysteem. Technologieën zoals gVisor, Firecracker of speciale ephemeral execution services zijn hiervoor geschikt. Als code toegang tot I/O nodig heeft, gebruik dan een proxy die het beleid afdwingt.
Systeemoproepfilters en seccomp: beperk welke systeemoproepen zijn toegestaan. Bestandsschrijfbewerkingen buiten een tijdelijke directory moeten worden geblokkeerd.
Bron-/tijdslimieten: stel CPU-/geheugen-/tijdslimieten in, zodat zelfs logische bommen niet oneindig kunnen blijven draaien.

Sandbox-uitvoering plus monitoring brengt vaak payloads aan het licht die statische controles missen. Brancherichtlijnen en recente whitepapers bevelen sandboxing aan als een belangrijke risicobeperkende maatregel.

Welke geautomatiseerde tools en regels moeten in uw pijplijn zitten?

Aanbevolen toolchain-componenten

Unicode-sanitatiemodule (aangepaste of bestaande bibliotheken). Genormaliseerde tekens moeten worden geregistreerd.
Parser + AST-analysator voor elke doeltaal (Python ast, typed-ast, JavaScript-parsers, Java-parsers).
Statische analysers / SAST: Bandit (Python), Semgrep (meertalig, aanpasbaar), ESLint met beveiligingsplugins.
Entropie en decoderheuristiek: base64/hex/gzip detecteren en doorsturen naar inspectie.
Sandbox-runtime: minimale container met strikt seccomp/AppArmor-profiel of interpreter op taalniveau met uitgeschakelde systeemaanroepen.
Beleidshandhaver: een onderdeel dat bepaalt welke modules, eindpunten en veilige API-wrappers zijn toegestaan.
Controlespoor: onveranderlijke logboeken die de originele uitvoer, opgeschoonde uitvoer, verschillen en beslissingen vastleggen.

Voorbeeld semgrep-patronen (conceptueel)

Gebruik korte, conservatieve regels die het gebruik van gevaarlijke functies markeren. Bijvoorbeeld:

Vlag eval, exec, Function constructor (JS), dynamische imports of op strings gebaseerde API-namen.
Netwerkoproepen markeren buiten de toegestane lijst (bijv. requests.get naar onbekende hosts).
Vlag schrijft naar gevoelige paden (/etc, systeemmappen) of het opstarten van processen.

(Bewaar deze als configuratie-items per organisatie en verbeter ze in de loop van de tijd.)

Wat zijn praktische desinfectiefragmenten (veilige voorbeelden)?

Hieronder staan ongevaarlijke, defensieve voorbeelden die u kunt aanpassen. desinfectie en detectie fragmenten — geen exploitinstructies.

Voorbeeld: strippen van tekens met een breedte van nul (Python, defensief)

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

Hiermee worden tekens verwijderd die aanvallers vaak gebruiken om code te verbergen in anderszins zichtbare tekst. Registreer altijd wat er is verwijderd en behandel de verwijdering als onderdeel van het audittrail.

Voorbeeld: AST parsen en inspecteren (Python, conceptueel)

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 retourneert True, voer de code niet uit en vervang in plaats daarvan het dynamische knooppunt door een veilige stub en vereis een beoordeling.

Let op: deze voorbeelden zijn defensief van aard. Verwijder logging, auditing of menselijke beoordeling niet uit uw pipeline.

Slotgedachten: behandel LLM-uitvoer altijd als niet-vertrouwde code

LM's zijn krachtige productiviteitstools: ze kunnen elegante code produceren, concepten versnellen en routinewerk automatiseren. Maar waar ze de uitvoering ontmoeten, veranderen de regels voor beveiliging: modeluitvoer moet worden behandeld als niet-vertrouwde artefactenDe combinatie van snelle injecties, achterdeuronderzoek en openbaarmaking van kwetsbaarheden in de praktijk in de afgelopen 18 tot 30 maanden maakt duidelijk: het risicooppervlak is gegroeid en zal zich blijven ontwikkelen.

Praktische verdedigingsmechanismen die parsing, statische analyse, dynamische sandbox-testen, governance en continue red-teaming combineren, zullen de meeste aanvallen stoppen. Teams moeten echter ook investeren in organisatorische controlemechanismen: minimale privileges, herkomst en een cultuur die ervan uitgaat dat LLM-resultaten geverifieerd moeten worden. De industrie ontwikkelt tools en frameworks om deze patronen eenvoudiger te maken; ondertussen verkleint het gebruik van de bovenstaande checklist de kans dat een verborgen payload niet wordt gevonden.

Ontwikkelaars hebben toegang tot de nieuwste LLM API, zoals Claude Sonnet 4.5 API en Gemini 3 Pro Preview enz. via CometAPI, de nieuwste modelversie wordt altijd bijgewerkt met de officiële website. Om te beginnen, verken de mogelijkheden van het model in de Speeltuin en raadpleeg de API-gids voor gedetailleerde instructies. Zorg ervoor dat u bent ingelogd op CometAPI en de API-sleutel hebt verkregen voordat u toegang krijgt. KomeetAPI bieden een prijs die veel lager is dan de officiële prijs om u te helpen integreren.

Klaar om te gaan?→ Meld u vandaag nog aan voor CometAPI !

Als u meer tips, handleidingen en nieuws over AI wilt weten, volg ons dan op VK, X en Discord!