Preventie van AI-gegevenslekken: hoe u kunt voorkomen dat gevoelige gegevens ontsnappen via prompts, RAG, geheugen en agenten

Invoering

Gevoelige gegevens laten een AI-systeem doorgaans niet achter met operadrama. Het trapt de deur niet in, steelt geen sportwagen en verdwijnt in de nacht terwijl het alarm afgaat. Vaker komt het stilletjes naar buiten, verstopt in een onschuldig antwoord, een opgehaald documentstuk, een toolresultaat, een uitgebreide logregel of een vrolijke samenvatting gegenereerd door een model dat eenvoudigweg te veel toegang en te weinig toezicht heeft gekregen.

Dat is het eerste wat de moeite waard is om duidelijk te zeggen. Het lekken van AI-data is geen sciencefictionprobleem. Het is een technisch probleem, en zoals de meeste technische problemen groeit het in de kloof tussen wat mensen aannemen dat een systeem doet en wat het feitelijk mag doen. Een team bouwt een copiloot voor interne documentatie. Het werkt prachtig. Dan wijst iemand het op een bredere gegevensbron, behoudt dezelfde gebruikersrechten, voegt geheugen toe, voegt een paar tools toe, en plotseling vat het systeem niet alleen maar onschuldige tekst samen. Het is dwalen door een pakhuis met privémateriaal met het vertrouwen van een beleefde dief.

Het gevaar is niet dat het model slecht is. Het model is niet slecht. Het model is op de slechtst mogelijke manier gehoorzaam. Het zal instructies, context, opgehaalde tekst, verborgen aanwijzingen, verouderd geheugen en tool-uitvoer combineren tot één werkende soep, en dan iets produceren dat nuttig klinkt. Als de architectuur eromheen slordig is, wordt behulpzaamheid overdreven. Als de datagrenzen zwak zijn, wordt gemak exfiltratie. En als het team meer vertrouwt op snelle bewoordingen dan op systeemontwerp, eindigt het verhaal zoals veel vermijdbare verhalen eindigen: met verrassing, schaamte en een ontmoeting die niemand wilde.

Dit artikel gaat over het voorkomen van die uitkomst. We zullen kijken naar de echte lekkageoppervlakken in moderne AI-systemen, waarom de naïeve verdediging faalt, welke controles daadwerkelijk werken, en hoe we een kleine maar nuttige gateway kunnen bouwen die een technisch team kan beheren en uitbreiden. De toon hier is met opzet praktisch. Het punt is niet om wijs te klinken. Het punt is om u te helpen een AI-systeem te leveren dat uw gegevens niet aan de verkeerde persoon doorgeeft, alleen maar omdat iemand een enthousiaste prompt heeft geschreven.

Waarom AI-lekken op zulke gewone manieren voorkomen

Traditionele toepassingen scheiden de rollen doorgaans redelijk goed. Invoer komt via één plek binnen, bedrijfslogica leeft ergens anders en machtigingen worden afgedwongen door expliciete codepaden. AI-systemen vervagen die grenzen. Natuurlijke taal wordt zowel invoer- als controlevlak. Teruggevonden kennis wordt zowel bewijsmateriaal als aanvalsoppervlak. Tooloproepen worden zowel mogelijkheden als zichtbaarheid. Zelfs het geheugen, dat in productdia's onschuldig klinkt, kan een langzaam bewegend lek worden als niemand gedisciplineerd is over wat er wordt opgeslagen en voor hoe lang.

Dit is de reden waarom gewone productteams het probleem onderschatten. Ze denken dat ze een model in een workflow integreren. In werkelijkheid introduceren ze een probabilistische middlewarelaag die gegevens uit meerdere vertrouwenszones met plezier opnieuw combineert. Als de systeemprompt zegt: 'Onthul nooit geheimen', klinkt dat respectabel. Het verandert ook niets aan het onderliggende feit dat het model deze geheimen nog steeds kan zien, erover kan redeneren en gemanipuleerd kan worden om ze te verpakken in een vorm die de ontwerpers niet hadden verwacht.

De richtlijnen van Microsoft voor het beveiligen van zakelijke AI-applicaties maken dit punt duidelijk in nuchtere bedrijfstaal: datalekken, snelle injectie en lacunes in het bestuur behoren nu al tot de belangrijkste zorgen waarmee organisaties worden geconfronteerd bij de inzet van AI. Het document is beleefd, maar de boodschap is bot. Als AI brede toegang en zwak toezicht heeft, glijdt gevoelige informatie weg. Als je dat eenmaal ziet, is de juiste vraag niet langer: “Hoe kunnen we de prompt strenger maken?” De juiste vraag wordt: “Waarom is het model überhaupt in staat dit materiaal te zien, en welke controle faalde voordat de prompt zelfs maar werd geschreven?”

Die verandering in mentaliteit is belangrijk. Volwassen AI-beveiliging begint voordat het model het eerste token aanraakt. Het begint met gegevensclassificatie, ophaalgrenzen, toegangscontrole, logdiscipline en gereedschapsautorisatie. Met andere woorden: het voorkomen van datalekken door AI bestaat vooral uit systeemtechniek die een AI-badge draagt.

De echte lekoppervlakken

Het helpt om te stoppen met praten over ‘het AI-systeem’ alsof het één doos is. Lekkage gebeurt meestal via een van de vijf paden, en elk pad heeft zijn eigen faalmodus.

Het eerste pad is de aanwijzingsgrens. Teams maken zich vaak zorgen over gebruikersprompts en vergeten dat prompts slechts één van de vele instructies zijn. Een model kan ook verborgen systeeminstructies, opgehaalde documenten, een samengevatte chatgeschiedenis en gegevens van externe tools opnemen. Als een van deze bronnen vijandige of te brede inhoud bevat, is de promptgrens al aangetast. Het werk van OWASP op het gebied van LLM-toepassingsrisico's is juist nuttig geweest omdat het teams dwingt om prompte injectie niet langer als een feesttruc te behandelen, maar om het als een controlevliegtuigprobleem te gaan behandelen.

Het tweede pad is ophalen. Retrieval-augmented generatie ziet er netjes uit in architectuurdiagrammen. Er is een vectorindex, een query, een rangschikkingsstap en een paar stukjes komen in het contextvenster terecht. Dat lijkt gecontroleerd totdat je bedenkt dat die stukjes informatie van de verkeerde tenant, verouderde machtigingen, vergiftigde documenten, niet-beoordeelde exports of tekst met verborgen instructies voor het model kunnen bevatten. Ophalen is vaak het meest onderschatte lekoppervlak omdat het niet dramatisch is. Het voelt als zoeken. Maar zoeken met een generatieve laag erbovenop kan een indexeringsfout heel snel omzetten in een openbaarmakingsgebeurtenis.

Het derde pad is geheugen. Productteams houden van herinneringen omdat de assistent hierdoor minder houterig aanvoelt. Beveiligingsteams houden er minder van, omdat het geheugen vaak per ongeluk groeit. Misschien wordt een sessiecache een langetermijngeheugen. Misschien begint een interne overzichtsopslag gegevens langer te bewaren dan de bedoeling was. Misschien wordt persoonlijk identificeerbare informatie bewaard in een handige functie die nooit is ontworpen voor gevoelige werklasten. Het geheugen is waar vriendelijke UX-ideeën stilletjes een retentiebeleidsprobleem worden.

Het vierde pad is het gebruik van gereedschap. Een model dat een ticketingsysteem, CRM, coderepository, agenda, SQL-gateway of interne API kan aanroepen, is niet langer alleen maar een tekstengine. Het is een actiesysteem. Dat kan productief zijn. Het betekent ook dat te veel toestemming geven veel duurder wordt. Het recente werk van NIST rond de identiteit en autorisatie van software en AI-agenten is hier waardevol omdat het het punt aanpakt dat veel teams proberen over te slaan: wanneer een AI-systeem kan handelen, zijn identiteit en autorisatie niet langer mooie architectuuronderwerpen en worden ze centrale controlepunten.

Het vijfde pad is uitvoer en telemetrie. Zelfs als het ophalen, het geheugen en de tools redelijk goed worden gecontroleerd, kan het systeem nog steeds lekken via antwoorden, sporen, foutopsporingslogboeken, evaluatiedatasets, analysedashboards en gekopieerde chattranscripties. Teams zeggen vaak “we onthullen geen geheimen in de gebruikersinterface”, terwijl ze vergeten dat dezelfde inhoud wordt opgeslagen in logboeken, sporen, ondersteuningsexports of herhalingssets van het rode team. Een lek is nog steeds een lek als het gebeurt in de observatiestapel in plaats van in de chatbotbubbel.

Zodra deze vijf oppervlakken zichtbaar zijn, wordt het probleem minder mystiek. We proberen niet een taalmodel moreel zuiver te maken. Wij ontwerpen een systeem waarin geen enkele onzorgvuldige beslissing alle deuren tegelijk opent.

Waarom de naïeve verdediging faalt

Er zijn verschillende verdedigingsmechanismen die geruststellend klinken in slides en zwaar teleurstellen in echte systemen.

De eerste zwakke verdediging is de prompt van het heksysteem. Het model vertellen geen vertrouwelijke informatie vrij te geven is beter dan niets zeggen, net zoals het op slot zetten van een fiets met een touwtje beter is dan hem op straat te laten staan ​​met een briefje waarop staat ‘alsjeblieft niet doen’. Maar een prompt is geen toestemmingsgrens. Het is geen beleid voor gegevensminimalisatie. Het beperkt het ophalen niet met terugwerkende kracht. Het weerhoudt het model er niet van om een ​​geheim in zijn context te zien. Het probeert alleen maar het model ervan te overtuigen zich te gedragen nadat de gevaarlijke omstandigheden al zijn gecreëerd.

De tweede zwakke verdediging is het optimisme van leveranciers. Teams gaan ervan uit dat de provider vangrails heeft en daarom is het probleem uitbesteed. Dit is een geruststellende fantasie. Leveranciersbeschermingen zijn nuttig, maar ze kennen uw tenantmodel, uw interne documenttaxonomie, uw bewaarverplichtingen, uw verborgen beheerderseindpunten of uw vreemde kleine middleware-snelkoppeling van driekwart geleden niet die nog steeds te veel context in het model injecteert. Beheerde veiligheidsvoorzieningen kunnen risico's verminderen, maar kunnen uw eigen architectuur niet vervangen.

De derde zwakke verdediging is ‘we vertrouwen onze medewerkers’. Natuurlijk vertrouwt u uw medewerkers. Dat is niet het punt. Mensen nemen onder druk snelle beslissingen. De discussie van Microsoft over schaduw-AI en oversharing is nuttig omdat het de ongemakkelijke waarheid benoemt: goede werknemers kunnen nog steeds gevoelige informatie in het verkeerde model stoppen, een goedgekeurd model aan de verkeerde gegevensbron koppelen, of ervan uitgaan dat een chattranscriptie vluchtig is terwijl dat niet het geval is. Vertrouwen in mensen is geen vervanging voor grenzen in systemen.

De vierde zwakke verdediging is het inschakelen van een paar filters alleen tijdens de uitvoertijd. Outputfiltering is belangrijk, maar het is het laatste net en niet de basis. Als het model te veel ziet, te veel ophaalt, te veel onthoudt of het verkeerde gereedschap kan oproepen, probeert de uitvoerfiltering de vloer te dweilen terwijl de leiding nog kapot is.

Het patroon hier is eenvoudig. Zwakke verdedigingen vragen het model om zich te gedragen. Sterke verdedigingen verminderen wat het model in de eerste plaats kan zien, onthouden, ophalen of oproepen.

Bouw de pijplijn alsof het model nieuwsgierig en onzorgvuldig is

Het schoonste mentale model is dit: behandel het model als nieuwsgierig, capabel, snel en niet volledig betrouwbaar als het om grenzen gaat. Dat betekent niet dat het model kwaadaardig is. Het betekent dat het model niet mag worden vertrouwd met een breed impliciet oordeel over wat veilig is om te onthullen.

Vanuit dat oogpunt begint een veiligere AI-pijplijn met dataclassificatie. Niet elk document hoeft even vindbaar te zijn. Niet elke gebruiker zou dezelfde bron moeten kunnen opvragen. Niet elke gegevensklasse mag beschikbaar zijn in dezelfde assistentmodus. Als uw AI-laag zich bovenop een gegevensmoeras bevindt waar classificaties vaag zijn en rechten slordig worden overgenomen, heeft u nog geen AI-probleem. Je hebt een opslag- en identiteitsprobleem als je AI-make-up draagt.

Na classificatie komt het ophaalbeleid. RAG-systemen mogen niet simpelweg “top K-relevante brokken” ophalen. Ze moeten de bovenste K-chunks ophalen die relevant, tenant-correct, permissie-correct, versheid-correct en veilig zijn voor de huidige taak. Dat klinkt als extra werk, want het is extra werk. Maar het is goedkoper dan aan een klant uitleggen waarom de interne naamgevingsconventie van de ene klant verscheen in het zogenaamd privéantwoord van een andere klant.

Dan komt de gereedschapsautorisatie. Een model mag geen brede, magische gereedschapsriem krijgen. Het moet een beperkte set tools ontvangen waarvan de machtigingen zijn afgestemd op de taak, de gebruiker, de tenant en de huidige werkstroomstatus. Tooloproepen moeten ook waarneembaar zijn. Als een model records kan opzoeken, exporten kan genereren, naar systemen kan schrijven of workflows kan activeren, moet het actietraject inspecteerbaar zijn voor mensen die niet de originele demo hebben geschreven.

Het geheugen heeft dezelfde discipline nodig. Houd de kortetermijncontext kort. Houd het langetermijngeheugen expliciet. Geef opgeslagen herinneringen labels, levensduur en verwijderingspaden. Bepaal welke categorieën informatie nooit worden opgeslagen. Als u het niet leuk zou vinden om een ​​stuk tekst in een ondersteunende export te zien, laat het dan geen duurzaam geheugen worden alleen maar omdat iemand zei: “het verbetert de personalisatie.”

Plaats ten slotte uitgangscontroles op de weg naar buiten. Gevoelige patroondetectie, beleidscontroles, gestructureerde toelatingslijsten voor outputklassen met een hoog risico en selectieve menselijke goedkeuring zijn geen tekenen van wantrouwen in het model. Het zijn tekenen van volwassenheid in het systeem.

RAG-grenzen die er echt toe doen

RAG is vaak de plaats waar AI-producten overgaan van speelgoed naar bedrijfssysteem, en dat is precies de reden waarom het meer verdenking verdient dan gewoonlijk.

De eerste grens is huurderisolatie. Ophaalwinkels die huurders mixen en later afhankelijk zijn van zachte filtering, zijn ongelukken die kunnen gebeuren. Als de gegevens werkelijk van grote waarde zijn, is het schoonste antwoord vaak een fysieke of logische scheiding voordat het ophalen zelfs maar begint. Het minder elegante maar nog steeds respectabele antwoord is agressieve metadatafiltering die wordt toegepast voordat de rangschikkingsresultaten aan het model worden doorgegeven. Het slechtste antwoord is om breed op te zoeken, erop te vertrouwen dat het model de relevantie afleidt, en te hopen dat het niet de verkeerde fragmenten aan elkaar plakt.

De tweede grens is documentvertrouwen. Niet elk geïndexeerd document verdient dezelfde autoriteit. Sommige zijn geschreven door vertrouwde interne teams. Sommige werden geëxporteerd vanuit andere systemen. Sommige kunnen door de gebruiker worden verstrekt. Sommige zijn misschien oud. Sommigen zijn mogelijk vergiftigd. Onderzoek naar data-extractieaanvallen in ophaalsystemen is hier van belang omdat het ons eraan herinnert dat het ophalen niet alleen maar feiten ophaalt. Het kan kwaadaardige instructies en verborgen triggers importeren. Een ophaallaag zonder concept van vertrouwensniveau vraagt ​​een zeer dure autocomplete-engine om als beveiligingscontroleur op te treden.

De derde grens is de brokhygiëne. Teams praten graag over de grootte van blokken, overlap en het inbedden van modellen. Ze spreken minder vaak over de vraag of het stuk überhaupt zou moeten bestaan. Bevat het geheimen die vóór indexering hadden moeten worden geredigeerd? Bevat het interne opmerkingen, inloggegevens of resten van foutopsporing? Behoudt het onnodige identificatiegegevens terwijl abstracte samenvattingen zouden volstaan? Als uw RAG-pijplijn eerst alles opneemt en later beveiligingsvragen stelt, is het niet echt een veilige RAG-pijplijn. Het is hoopgevend.

De vierde grens is de citatiediscipline. Idealiter zou een model moeten weten welke brokken hebben bijgedragen aan het antwoord en welk beleid deze brokken in hun context heeft geplaatst. Niet omdat citaten mooi zijn, maar omdat uitlegbaarheid helpt bij de reactie op incidenten. Als er iets ergs gebeurt, is ‘het model moet het ergens gezien hebben’ geen bevredigende zin.

Agenten Vermenigvuldig de straal van de explosie

Eenvoudige chatsystemen kunnen lekken. Agenten kunnen lekken en actie ondernemen.

Het verschil is belangrijk. Zodra een model kan beslissen welk hulpmiddel moet worden aangeroepen, in welke volgorde, met welke parameters, over welke opgehaalde context, wordt het aanvalsoppervlak groter en daarmee ook het ongevalsoppervlak. Het probleem is niet langer alleen: “Zal de assistent iets zeggen wat hij niet zou moeten zeggen?” Het probleem wordt: “Zal de assistent besluiten iets op te vragen wat hij niet had moeten doen, dit combineren met geheugen dat hij niet had mogen bewaren, en het resultaat doorgeven aan een workflow die nooit bedoeld was om op die basis te draaien?”

Daarom kan de beveiliging van agenten niet worden gereduceerd tot snelle engineering. De huidige interesse van NIST in de identiteit en autorisatie van agenten is geen bureaucratische versiering. Het is een erkenning dat AI-systemen die tools gebruiken identiteit, bevoegdheden en goedkeuringslogica nodig hebben die buiten het model zelf leesbaar zijn.

In de praktijk betekent dit dat een paar ouderwets strikte gewoonten veel helpen. Scheid leeshulpmiddelen van schrijfhulpmiddelen. Scheid het ophalen met een laag risico van de acties met een hoog risico. Gebruik kortstondige inloggegevens. Zorg ervoor dat gevaarlijke acties een expliciet goedkeuringspad vereisen. Leg vast waarom de agent geloofde dat een tool call nodig was. En laat niet hetzelfde brede toegangstoken als een koninklijk paspoort door elke fase van de workflow zweven.

Een klein tegenvoorbeeld verduidelijkt dit punt. Stel dat een interne AI-assistent de kennisbank kan doorzoeken, uitgiftetickets kan lezen, een klantantwoord kan opstellen en dat antwoord uiteindelijk kan verzenden. Een zwak ontwerp zorgt ervoor dat dezelfde agent elke stap van begin tot eind kan uitvoeren. Dankzij een sterker ontwerp kan de assistent het bericht ophalen en opstellen, maar is een afzonderlijke, gecontroleerde goedkeuringsstap vereist voordat een uitgaand bericht wordt verzonden. Beide systemen kunnen er in een demo even gepolijst uitzien. Slechts één gedraagt ​​zich alsof hij verwacht dat de echte wereld bestaat.

Een referentie-implementatie die u daadwerkelijk kunt uitvoeren

Het beste beleid is het beleid dat contact met code overleeft. Laten we dus een kleine Python-gateway bouwen die de kernideeën demonstreert: voor de hand liggende geheimen uit inkomende tekst redigeren, opgehaalde delen filteren op tenant en classificatie, toolaanroepen beperken tot een toelatingslijst per verzoek, en het uitgaande antwoord scannen voordat het vertrekt.

Dit is geen volledig beveiligingsproduct voor ondernemingen, en het pretendeert ook niet zo te zijn. Het is een compact skelet dat de juiste architectonische gewoonten afdwingt.

ai_leakage_gateway.py

from __future__ import annotations

from dataclasses import dataclass
import fnmatch
import json
import re
from typing import Iterable


SECRET_PATTERNS = {
    "aws_access_key": re.compile(r"\bAKIA[0-9A-Z]{16}\b"),
    "jwt": re.compile(r"\beyJ[A-Za-z0-9_-]+\.[A-Za-z0-9._-]+\.[A-Za-z0-9._-]+\b"),
    "private_key": re.compile(r"-----BEGIN (RSA|EC|OPENSSH|DSA)? ?PRIVATE KEY-----"),
    "email": re.compile(r"\b[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,}\b", re.I),
}


@dataclass(frozen=True)
class UserContext:
    user_id: str
    tenant_id: str
    role: str
    allowed_labels: tuple[str, ...]
    allowed_tools: tuple[str, ...]


@dataclass(frozen=True)
class Chunk:
    chunk_id: str
    tenant_id: str
    label: str
    text: str


def redact_text(text: str) -> str:
    result = text
    for label, pattern in SECRET_PATTERNS.items():
        result = pattern.sub(f"[REDACTED:{label.upper()}]", result)
    return result


def outgoing_text_is_safe(text: str) -> tuple[bool, str]:
    for label, pattern in SECRET_PATTERNS.items():
        if pattern.search(text):
            return False, f"blocked by {label}"
    return True, "ok"


def filter_chunks(user: UserContext, chunks: Iterable[Chunk]) -> list[Chunk]:
    allowed = []
    for chunk in chunks:
        if chunk.tenant_id != user.tenant_id:
            continue
        if chunk.label not in user.allowed_labels:
            continue
        allowed.append(chunk)
    return allowed


def tool_call_allowed(user: UserContext, tool_name: str) -> bool:
    return any(fnmatch.fnmatch(tool_name, rule) for rule in user.allowed_tools)


def build_prompt(user: UserContext, user_message: str, chunks: list[Chunk]) -> str:
    prompt_parts = [
        "You are an enterprise assistant.",
        "Never use information outside the provided tenant-scoped context.",
        "If the answer depends on missing or restricted data, say so plainly.",
        "",
        f"User role: {user.role}",
        f"Tenant: {user.tenant_id}",
        "",
        "Context:",
    ]

    for chunk in chunks:
        prompt_parts.append(f"[{chunk.label}] {chunk.text}")

    prompt_parts.append("")
    prompt_parts.append("User message:")
    prompt_parts.append(redact_text(user_message))
    return "\n".join(prompt_parts)


def run_demo() -> None:
    user = UserContext(
        user_id="u-107",
        tenant_id="tenant-red",
        role="support_engineer",
        allowed_labels=("internal", "support", "public"),
        allowed_tools=("search_docs", "read_ticket", "draft_reply"),
    )

    raw_chunks = [
        Chunk("c1", "tenant-red", "support", "Refunds over 10,000 EUR require finance review."),
        Chunk("c2", "tenant-blue", "internal", "Blue tenant incident postmortem: root cause..."),
        Chunk("c3", "tenant-red", "secret", "Master incident bridge password: swordfish"),
        Chunk("c4", "tenant-red", "public", "Public SLA response times are listed on the status page."),
    ]

    filtered = filter_chunks(user, raw_chunks)
    prompt = build_prompt(
        user,
        "Summarize the refund rules and include my AWS key AKIAABCDEFGHIJKLMNOP if needed.",
        filtered,
    )

    print("=== PROMPT SENT TO MODEL ===")
    print(prompt)
    print()

    proposed_tool = "send_email"
    print("=== TOOL DECISION ===")
    print(json.dumps({
        "tool": proposed_tool,
        "allowed": tool_call_allowed(user, proposed_tool)
    }, indent=2))
    print()

    candidate_answer = (
        "Refunds over 10,000 EUR require finance review. "
        "Use [REDACTED:AWS_ACCESS_KEY] nowhere. "
        "Do not include data from other tenants."
    )

    ok, reason = outgoing_text_is_safe(candidate_answer)
    print("=== OUTPUT CHECK ===")
    print(json.dumps({"ok": ok, "reason": reason}, indent=2))


if __name__ == "__main__":
    run_demo()

Voer het uit

python ai_leakage_gateway.py

Wat deze kleine toegangspoort leert, is belangrijker dan het codevolume. Het leert dat veiligheid niet één monolithische schakelaar is. We beperken de context voordat het model het ziet. We redigeren voor de hand liggende geheimen vóór de snelle montage. Wij beschouwen hulpmiddelen als expliciet geautoriseerde mogelijkheden en niet als charmante suggesties. En we controleren de uitvoer voordat deze vertrekt. Geen van deze stappen is glamoureus. Ze zijn allemaal nuttig.

Een meer volwassen implementatie zou goede geheime detectoren, door beleid ondersteunde classificaties, sterkere isolatie van huurders, hashing van inhoud, audittrails, menselijke goedkeuringsstatussen en testarmaturen toevoegen. Goed. Het zou moeten. Het belangrijkste is dat de vorm van de oplossing al eerlijk is.

Tegenvoorbeelden die het waard zijn om te onthouden

Het helpt om een ​​paar slechte patronen aan de muur te houden, omdat teams deze met deprimerende creativiteit herhalen.

Een slecht patroon is de universele copiloot. Het heeft toegang tot alles omdat “we een uniforme ervaring willen.” In de praktijk betekent dit vaak dat de assistent meer kan zien dan enig mens ooit op één plek zou mogen zien. Als dat systeem lekt, is de echte boosdoener niet het model. De boosdoener is architectonische hebzucht.

Een ander slecht patroon is de ‘beveiligde RAG’-demo die stilletjes ruwe exporten uit gedeelde opslag indexeert. De demo ziet er prachtig uit totdat iemand vraagt ​​of de vectoropslag tenantgrenzen afdwingt tijdens het ophalen of pas nadat het antwoord is opgesteld. Als het antwoord vaag is, is het risico helemaal niet vaag.

Een andere is de geheugenfunctie die niemand bezit. Product denkt dat het de continuïteit verbetert. De beveiliging gaat ervan uit dat het van korte duur is. Legal gaat ervan uit dat retentie ergens anders wordt gedefinieerd. Support ontdekt zes maanden later dat oude fragmenten nog steeds kunnen opduiken. Dit is hoe onschuldige kenmerken een bestuursfout worden.

Dan is er nog de houtkapval. Ingenieurs voegen tijdens de ontwikkeling vaak rijke sporen toe, beloven ze later op te schonen en doen dat nooit. Het resultaat is dat de gebruikersinterface van het product respectabel kan zijn, terwijl de observatiestapel een museum van gevoelig materiaal wordt. Dit is een van de saaiste lekkagepaden en een van de meest voorkomende.

Goede techniek lijkt vaak het tegenovergestelde van deze fouten. Het ziet er smaller uit. Explicieter. Iets minder magisch. Dat is geen gebrek. Het is een kenmerk van systemen die verwachten het contact met de werkelijkheid te overleven.

De organisatorische controles zijn belangrijker dan mensen willen toegeven

Er hangt een romance rond het oplossen van alles in code, en dat is niet geheel onverdiend. Maar het voorkomen van AI-lekken is ook een disciplineprobleem.

Teams hebben een beleid met goedgekeurde tools nodig, niet omdat beleidsdocumenten spannend zijn, maar omdat schaduw-AI echt is. Ze hebben basisregels voor gegevensverwerking nodig voor prompts en uploads. Ze hebben een manier nodig om te beslissen welke interne systemen AI-functies mogen voeden en welke niet. Ze hebben beoordelingspaden nodig voor gebruiksscenario's met een hoog risico. Ze hebben iemand nodig die de retentie beheert. Ze hebben iemand nodig die eigenaar is van de model- en gereedschapsinventaris. En ze hebben de nederigheid nodig om te zeggen: “Deze werklast is nog niet klaar voor brede toegang tot AI.”

De beste technische controles ter wereld zullen het nog steeds moeilijk hebben als de organisatie elke AI-functie beschouwt als een noodsnelkoppeling naar productiviteit. Beveiliging is eenvoudiger als het bedrijf veilige alternatieven biedt, in plaats van alleen maar te roepen ‘gebruik geen niet-goedgekeurde tools’. De begeleiding van Microsoft maakt dit goed. Mensen lopen om wrijving heen. Als het veilige pad ellendig is en het onveilige pad snel, zal het onveilige pad een loyale aanhang ontwikkelen.

Dus ja, bouw de vangrails. Maar maak de veilige workflow ook zo bruikbaar dat engineers en kenniswerkers niet het gevoel krijgen gestraft te worden voor samenwerking.

Praktijklab: verander de demo in een echte beleidsgateway

Als je van de theorie wilt overstappen naar iets waar je eigen team mee aan de slag kan, is dit een goede oefening voor het weekend.

Begin met de bovenstaande Python-gateway en geef deze een echt beleidsbestand.

policy.json

{
  "tenant_red": {
    "support_engineer": {
      "allowed_labels": ["public", "support", "internal"],
      "allowed_tools": ["search_docs", "read_ticket", "draft_reply"]
    },
    "finance_admin": {
      "allowed_labels": ["public", "support", "internal", "finance"],
      "allowed_tools": ["search_docs", "read_ticket", "draft_reply", "read_finance_record"]
    }
  }
}

Breid vervolgens de gateway uit zodat:

1. gebruikers en rollen worden vanuit beleid geladen in plaats van hardgecodeerd;
2. Ophaalbrokken worden afgewezen, tenzij zowel de tenant als het label overeenkomen;
3. elke geblokkeerde gereedschapsoproep wordt met een reden geregistreerd;
4. uitgaande antwoorden die strings in de vorm van een geheim bevatten, worden in quarantaine geplaatst in plaats van geretourneerd;
5. geheugen wordt alleen geschreven voor gesprekstypen die op de toelatingslijst staan.

Als je dat eerlijk doet, zul je iets nuttigs opmerken. Het probleem voelt al snel niet meer als “prompt engineering” en begint te voelen als wat het werkelijk is: een beveiligings- en systeemintegratieklus met een model in het midden.

Testtaken voor liefhebbers

Als je het artikel verder wilt brengen en iets echts wilt leren in plaats van alleen maar mee te knikken, probeer dan deze:

1. Voeg een tenant_id mismatch-test toe en bewijs dat het verkeerde deel nooit de prompt bereikt.
2. Breid het uitvoerfilter uit om klant-ID's, interne ticketreferenties en betalingsartefacten te markeren.
3. Voeg een tweede fase toe die menselijke goedkeuring vereist voordat een schrijfbaar hulpmiddel kan worden uitgevoerd.
4. Bewaar het kortetermijngeheugen slechts vijftien minuten en voeg vervolgens logboeken voor automatisch verlopen en verwijderen toe.
5. Bouw twee red-team-prompts: één directe, één verborgen in de opgehaalde tekst, en kijk welke controle welke fout ondervindt.

Conclusie

Het voorkomen van AI-gegevenslekken is geen kwestie van het vinden van de perfecte zin om in een systeemprompt te plaatsen. Het is een kwestie van het bouwen van een systeem waarin gevoelige gegevens in een vroeg stadium worden geclassificeerd, het ophalen ervan op de juiste manier wordt geregeld, het geheugen wordt beperkt, tools beperkt worden geautoriseerd en de output wordt gecontroleerd voordat ze het gebouw verlaten.

Dat klinkt misschien minder glamoureus dan de marketingversie van AI. Goed. Glamour wordt overschat in de beveiliging. De teams die hier slagen, zijn meestal degenen die bereid zijn ouderwets precies te zijn. Zij beslissen wat het model mag zien, wat het mag doen, wat het zich mag herinneren en wat door een mens moet worden beoordeeld. Ze vragen het model niet om ethiek te ontwikkelen door middel van interpunctie.

En dat is op een rustige manier bemoedigend. Omdat het betekent dat de oplossing niet mystiek is. Het is techniek. Soms harde techniek, ja. Enigszins vervelende techniek, zeker. Maar toch techniek. Dat betekent dat er over nagedacht, getest, verbeterd en verzonden kan worden.

Als uw AI-systeem al gevoelige informatie raakt, is dit een goed moment om te stoppen met het bewonderen van de assistent en de grenzen eromheen te inspecteren. Dat is waar het echte verhaal altijd heeft gelegen.

Referenties

• NIST, Artificial Intelligence Risk Management Framework: Generative AI Profile: https://doi.org/10.6028/NIST.AI.600-1
• NIST, AI Agent Standards Initiative: https://www.nist.gov/caisi/ai-agent-standards-initiative
• NIST NCCoE, identiteit en autorisatie van software en AI-agenten: https://www.nccoe.nist.gov/projects/software-and-ai-agent-identity-and-authorization
• OWASP, Top 10 voor LLM-toepassingen: https://owasp.org/www-project-top-10-for-large-lingual-model-applications/
• AWS, GENSEC04-BP02: Implementeer controles om te beschermen tegen snelle injecties en pogingen tot jailbreak: https://docs.aws.amazon.com/wellarchitected/latest/generative-ai-lens/gensec04-bp02.html
• AWS, Navigeren door het beveiligingslandschap van generatieve AI: https://docs.aws.amazon.com/pdfs/whitepapers/latest/navigating-security-landscape-genai/navigating-security-landscape-genai.pdf
• Microsoft, Handleiding voor het beveiligen van de door AI aangedreven onderneming: aan de slag met AI-applicaties: https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/microsoft/final/en-us/microsoft-brand/documents/Securing-the-AI-Powered-Enterprise-Getting-Started-with-AI-Applications.pdf
• Yupei Lv et al., PLeak: Prompt lekkende aanvallen tegen grote taalmodeltoepassingen: https://arxiv.org/abs/2405.06823
• Yuxin Wen et al., Data Extraction Attacks in Retrieval-Augmented Generation via Backdoors: https://arxiv.org/abs/2411.01705