Documenten die instructies proberen te geven: promptinjectie in een PHP-applicatie beperken

Een functie die vragen over documenten beantwoordt, kan relevante tekst ophalen en naar een AI-model sturen. Die tekst is echter niet altijd onschuldig: een document, webpagina of door een gebruiker aangeleverd bestand kan zinnen bevatten die de taak proberen te wijzigen, toegang tot andere informatie proberen te verkrijgen of een actie proberen uit te lokken. Dit risico staat bekend als promptinjectie via documenten, of indirecte promptinjectie, omdat de instructies zijn opgenomen in de verwerkte inhoud en niet noodzakelijkerwijs in de vraag van de gebruiker.

De beperking bestaat er niet uit de perfecte zin voor de systeemprompt te vinden. Het gaat erom de applicatie zo te ontwerpen dat opgehaalde inhoud geen machtigingen, beleid of bedrijfsbeslissingen kan wijzigen en dat een modelantwoord nooit voldoende toestemming vormt om te handelen.

Welk risico moet worden beheerst?

Een document kan expliciete instructies bevatten, zoals “negeer de eerdere instructies”, of misleidendere tekst, zoals een verzoek om interne gegevens te onthullen. Het kan ook verborgen instructies bevatten in inhoud die uit HTML, opmerkingen, metadata of met OCR herkende tekst is gehaald. Als dit materiaal zonder onderscheid wordt vermengd met de instructies van de applicatie, kan het model een deel ervan opvolgen, er een gekleurde samenvatting van geven of een onbedoeld antwoord genereren.

Het risico hangt af van wat de functie kan doen. Een assistent die alleen een antwoord opstelt ter beoordeling heeft een andere impact dan een assistent die accounts kan raadplegen, terugbetalingen kan uitvoeren of berichten kan versturen. Voordat je de functie beschikbaar maakt voor gebruikers, moet je bepalen welke informatie deze mag ontvangen, welke antwoorden deze mag produceren en welke gevolgen daaruit kunnen voortvloeien.

Promptinjectie bewijst op zichzelf niet dat de toegangscontroles van de applicatie zijn doorbroken. Het kan wel informatie blootleggen die ten onrechte in de context is opgenomen of het model ertoe aanzetten een bewerking aan te vragen. De bescherming moet zowel de invoer en de beschikbare gegevens als de vervolgacties omvatten.

Gegevens scheiden van beleid en machtigingen

Opgehaalde inhoud moet als onderbouwing dienen voor een antwoord en mag geen bron van gezag worden. Een document kan bedrijfsbeleid beschrijven, maar de applicatie moet afzonderlijk bepalen of de gebruiker het document mag raadplegen of een gerelateerde bewerking mag uitvoeren. Die beslissing wordt niet aan de tekst of het gegenereerde antwoord gedelegeerd.

• Autorisatie vóór het ophalen: pas toegangscontroles toe bij het zoeken en filter documenten op basis van de identiteit en de actuele machtigingen van de gebruiker.
• Minimale context: stuur alleen de fragmenten die voor de taak nodig zijn. Voeg geen gegevens van andere accounts, geheimen, inloggegevens of informatie toe die het model niet nodig heeft.
• Beleid buiten het model: bepaal machtigingen, limieten en bedrijfsvoorwaarden in applicatiecode of geautoriseerde services.
• Antwoord als voorstel: behandel de uitvoer van het model als inhoud die moet worden gevalideerd, niet als een uitvoerbare instructie.

Een systeemprompt kan helpen het gewenste gedrag te beschrijven, bijvoorbeeld door aan te geven dat opgehaalde tekst referentiemateriaal is. Het is geen beveiligingsgrens: het garandeert niet dat het model kwaadaardige instructies negeert en vervangt geen toegangscontroles, validatie of technische beperkingen.

De PHP-flow ontwerpen met expliciete grenzen

In PHP is het verstandig de stappen autorisatie, ophalen, context samenstellen, het model aanroepen en de uitvoer valideren van elkaar te scheiden. Die scheiding maakt het eenvoudiger om elke grens te testen en voorkomt dat een AI-resultaat rechtstreeks wordt gekoppeld aan een gevoelige bewerking.

Het volgende fragment is illustratieve pseudocode, geen uitvoerbare aanroep van een specifieke client. De manier waarop je het verzoek samenstelt en welke velden worden geaccepteerd, hangt af van de gebruikte API en SDK:

$user = $auth->currentUser();
$documents = $repository->searchAuthorized($user, $question);
$snippets = $contextBuilder->selectRelevant($documents, $maxItems);

// Pseudocode: pas het verzoek aan de specifieke API aan.
$response = $aiClient->answer([
    'task' => 'Beantwoord de vraag met het referentiemateriaal; geef geen toestemming voor acties.',
    'untrusted_context' => $snippets,
    'question' => $question,
]);

$answer = $responseValidator->validate($response);
return $answer;

De namen in het voorbeeld zijn illustratief. Door de context als niet-vertrouwd te labelen, wordt de functie ervan duidelijker, maar daarmee wordt de context niet onfeilbaar geïsoleerd: noch het formaat, noch de instructies verhinderen op zichzelf dat het model een ingebedde instructie opvolgt. Een effectieve scheiding hangt ook af van de verzonden gegevens, de buiten het model toegepaste machtigingen en de beschikbare mogelijkheden.

Normaliseer en beperk de opgehaalde inhoud voordat je deze toevoegt: stel maximale groottes in, verwijder indelingen die je niet nodig hebt en behandel tekst uit OCR of externe pagina’s zorgvuldig. Vermijd het zonder limieten samenvoegen van documenten en het standaard opnemen van de volledige gespreksgeschiedenis. Bewaar een verwijzing naar de bron van elk fragment als je het antwoord moet kunnen toelichten of controleren, zonder de gevoelige inhoud ervan in logs op te nemen.

De impact van een gemanipuleerd antwoord beperken

Beperk de tools waartoe het model toegang heeft tot wat nodig is voor de specifieke functie. Als de taak alleen bestaat uit het beantwoorden van vragen, geef het dan geen schrijftools of algemene toegang tot interne services. Als het gegevens moet raadplegen, bied dan een beperkte bewerking aan die autorisatie per verzoek toepast, in plaats van ruime inloggegevens of willekeurige toegang tot een database.

Wanneer het model een actie voorstelt, moet de applicatie die via een afzonderlijke flow valideren. Controleer de identiteit, machtigingen, parameters, bedrijfsregels en de actuele toestand van de resource op het moment van uitvoering. Vraag voor acties met grote impact om expliciete bevestiging of menselijke beoordeling. Een tekstueel antwoord van het model, zelfs als het veilig lijkt of naar een document verwijst, vervangt die autorisatie niet.

Valideer de uitvoer ook voordat je deze weergeeft of verwerkt: controleer het verwachte formaat, beperk de lengte en wijs velden of waarden af die niet zijn toegestaan. Als een specifieke structuur wordt verwacht, parse en valideer de velden dan met deterministische regels. Output-escaping en bescherming tegen injectie in HTML, SQL of commando’s blijven noodzakelijk; AI-generatie maakt de geproduceerde tekst niet betrouwbaar.

Aanvallen en verwacht gedrag testen

De tests moeten de volledige flow bestrijken, niet alleen nagaan of het model correct reageert op een systeemprompt. Bereid onschadelijke documenten en adversariële documenten voor die de taak proberen te wijzigen, ongeautoriseerde gegevens proberen op te vragen of een actie proberen uit te lokken. Neem variaties in de bronindeling op, zoals tekst uit HTML, lange documenten en inhoud waarin instructies met legitieme informatie zijn vermengd.

• Controleer dat zoekopdrachten nooit documenten buiten de machtigingen van de gebruiker opleveren, ook niet wanneer de vraag expliciet om die gegevens vraagt.
• Controleer dat adversariële documenten geen tools activeren en de bedrijfsregels niet wijzigen.
• Bevestig dat een onjuist opgemaakt of onverwacht antwoord wordt afgewezen en dat voor een gevoelige bewerking afzonderlijke autorisatie nodig is.
• Beoordeel nuttige en correcte antwoorden op onschadelijke documenten om vast te stellen of de beperkingen de functie onaanvaardbaar verslechteren.
• Herhaal de tests wanneer het model, de instructietemplate, de retriever, de tools of het extractieproces veranderen.

Stel waarneembare acceptatiecriteria vast: welke gegevens nooit mogen verschijnen, welke acties geblokkeerd moeten blijven en hoe het systeem moet reageren wanneer er onvoldoende bewijs is. Eén geïsoleerde test garandeert geen veiligheid, maar een herhaalbare testsuite helpt regressies op te sporen en configuratiewijzigingen te vergelijken.

Signalen registreren zonder gevoelige gegevens op te stapelen

Registreer om problemen te onderzoeken aanvraag-ID’s, de configuratieversie, ID’s of interne verwijzingen van geraadpleegde documenten, autorisatiebeslissingen, aangeroepen tools en validatieresultaten. Een verwijzing registreren betekent niet dat je het document of de fragmenten ervan opslaat. Vermijd het opslaan van gevoelige fragmenten, tenzij daar een concrete noodzaak voor bestaat en specifieke toegangs-, beveiligings- en bewaarbeperkingen zijn ingesteld.

Voeg statistieken toe voor afwijzingen, formaatfouten en storingen bij de provider om beveiligingsproblemen van operationele problemen te onderscheiden. Vermijd het automatisch opslaan van volledige prompts, documenten en antwoorden als die persoonsgegevens, bedrijfsgeheimen of gereguleerde informatie bevatten. Stel regels vast voor bewaartermijnen, toegang en het redigeren van gevoelige gegevens; registreer waar dat volstaat hashes, ID’s en gestructureerde gebeurtenissen. Zorg ervoor dat logs geen nieuwe manier worden om de inhoud bloot te leggen die de functie moest beschermen.

Checklist voordat je de functie inschakelt

• Worden de machtigingen gecontroleerd voordat elk document wordt opgehaald?
• Is de verzonden context minimaal en begrensd, en wordt deze als niet-vertrouwde invoer behandeld?
• Worden beleid en bedrijfsregels buiten het model toegepast?
• Zijn de tools beperkt en wordt de autorisatie voor elke bewerking opnieuw gecontroleerd?
• Worden antwoorden gevalideerd voordat ze worden weergegeven of in acties worden omgezet?
• Is er menselijke beoordeling of bevestiging vereist voor beslissingen met grote impact?
• Zijn er herhaalbare adversariële tests en logs met gecontroleerde bewaartermijnen?

Als het antwoord op een van deze vragen nee is, beperk dan het bereik van de functie of houd acties in de voorstelmodus totdat die tekortkoming is verholpen. Bescherming tegen promptinjectie via documenten hangt er niet van af of het model de inhoud altijd correct interpreteert: ze hangt ervan af of de toegangs- en uitvoeringsgrenzen blijven werken, zelfs wanneer het model een fout maakt.