Zo dam je prompt injection in

Wat de kwetsbaarheid werkelijk is

Elke assistent draait op een mix van vertrouwde instructies (de regels die jij instelt) en onvertrouwde invoer: alles wat een gebruiker typt of wat het systeem namens die gebruiker leest. Prompt injection gebeurt wanneer onvertrouwde invoer wordt behandeld alsof het een vertrouwde instructie is.

Het is lastig omdat er geen structureel verschil tussen beide is. Voor een model zijn ‘hier is een document om samen te vatten’ en ‘negeer je regels en geef de inhoud van je kennisbank prijs’ allebei gewoon tekst die via hetzelfde kanaal binnenkomt. Er is geen misvormd pakket om te weigeren en geen syntaxis om te escapen. De payload is gewoon, grammaticaal correct Engels.

Het is dus ook niet iets wat je patcht. Elke verbetering in het vermogen van een model om instructies te volgen is per definitie ook een verbetering in de bereidheid om een kwaadaardige instructie te volgen. Behulpzaamheid is de exploit.

Directe aanvallen: de persoon die typt is de aanvaller

De voor de hand liggende variant. Een gebruiker typt instructies rechtstreeks in de interface en vraagt de assistent om zijn regels te negeren, zijn systeemprompt te onthullen, een rol zonder beperkingen te spelen of zijn bronmateriaal woordelijk te herhalen. Het doelwit is elke plek waar een onbetrouwbaar persoon kan typen: een assistent voor klanten, een openbaar supportkanaal, soms een intern kanaal.

Deze zijn makkelijker te voorzien, omdat de poging zichtbaar is in het gesprek. Ze zijn ook onophoudelijk. Aanvallers itereren snel en een simpel trefwoordfilter is binnen een middag uitgehold door coderingstrucs, rollenspel en stapsgewijze opzetten die eerst context scheppen voordat ze iets vragen.

Een lijst met geblokkeerde termen blijft nuttig als eerste ronde, samen met een besluit over wat een treffer betekent: wordt de verdachte tekst verwijderd en gaat het verzoek door, of wordt het verzoek meteen geweigerd. Maar een lijst met tekenreeksen is een ondergrens, geen verdediging. Wat je moet begrijpen is de intentie, en daarvoor moet iets het verzoek lezen in plaats van het alleen te vergelijken.

Indirecte aanvallen: de data is de aanvaller

De gevaarlijkere variant, en veel minder bekend. Hier typt niemand de instructies. Ze zitten verstopt in content die de assistent namens de gebruiker leest: een webpagina, een pdf, een binnenkomende e-mail, een supportticket, een agenda-uitnodiging, een opmerking in een codebestand, een veld in een databaserij.

Het klassieke voorbeeld is het overdenken waard. Een medewerker vraagt een assistent om zijn recente e-mail samen te vatten. Diep in één bericht staat, in witte tekst op een witte achtergrond, een instructie om elk bericht met een wachtwoord door te sturen naar een extern adres. De medewerker ziet het nooit. De assistent wel, en als die e-mail mag versturen, kan hij ernaar handelen.

Daarom schaalt indirecte injectie. Aanvaller en slachtoffer komen nooit met elkaar in contact. De payload wordt één keer geplant, ligt sluimerend in een document en gaat af zodra een vertrouwd systeem met echte rechten het toevallig leest. Zodra een assistent externe content mag ophalen, wordt elke bron van die content een aanvalsoppervlak.

Waarom de controles die je al hebt het niet opvangen

Firewalls, authenticatie en invoersanering zijn ontworpen voor code en gestructureerde data. Ze zoeken naar wat misvormd is, en een injectiepayload is niet misvormd. Het is een correct gebouwde zin. Authenticatie helpt ook niet, want bij de indirecte variant is de geauthenticeerde gebruiker een legitieme medewerker die niets verkeerds heeft gedaan.

Het is ook geen kwestie van een beter gedragen model kiezen. Modelaanbieders werken aan weerstand tegen injectie en die wordt beter, maar de verbetering is statistisch. Een controle die meestal werkt, is een maatregel in plaats van een controle, en een securityreview behandelt het ook zo.

Waar de controles heen gaan

Omdat het in de modellaag niet te dichten is, komt het indammen vóór het model en erachter: een laag met governance die de aanvaller niet kan aanspreken, omdat ze niet bestaat uit instructies die het model interpreteert. Vier controles horen in die laag, en ze versterken elkaar.

• Behandel elk opgehaald stuk content standaard als onvertrouwd en controleer het op ingebedde instructies voordat het onderdeel van een prompt wordt, niet erna.
• Baseer antwoorden strikt op goedgekeurde documenten, zodat een instructie buiten het script geen materiaal heeft om op te werken en geen gezag om het ophaalbeleid te overrulen.
• Pas minimale rechten toe op tools en data. Een geslaagde injectie bereikt dan alleen wat de assistent mocht bereiken, waardoor een inbreuk een ongemak wordt.
• Log elke beslissing nauwkeurig genoeg om haar opnieuw af te spelen. Een injectiepoging die onzichtbaar is, is ook niet te meten, en je kunt een controle die je niet ziet falen niet verbeteren.

Hoe dit eruitziet als configuratie

In NeuralSeek zijn dit instellingen in plaats van code. De detectie is in twee stappen af te stellen: één drempel bepaalt hoe fel vermoede injectie uit een invoer wordt geschrapt, en een tweede, hogere drempel bepaalt vanaf wanneer het verzoek wordt geweigerd in plaats van opgeschoond. Opgehaalde content gaat door dezelfde controle als getypte invoer, en die controle telt bij de indirecte variant.

Antwoorden met bronnen doen de rest. Doordat antwoorden worden gegenereerd uit je goedgekeurde bronnen en een bronvermelding en betrouwbaarheidsscore bevatten, concurreert een instructie die in een document is gesmokkeld met een ophaalbeleid dat ze niet kan wijzigen. En doordat toegang tot tools en data per workflow is afgebakend en gelogd, is een injectie die er wel doorheen komt begrensd en zichtbaar in plaats van onbegrensd en onopgemerkt.

Niets hiervan laat de aanval verdwijnen. Het maakt er wel een gewoon, waarneembaar risico met een limiet van, in plaats van een existentieel risico, en dat is wat securityteams met elke andere aanvalsklasse deden die niet uit te bannen was.