Forebyggelse af AI-datalækage: Sådan stopper du følsomme data, der undslipper gennem prompter, RAG, hukommelse og agenter

Introduktion

Følsomme data forlader normalt et AI-system stille og roligt, gemt inde i et uskyldigt svar, en hentet dokumentdel, et værktøjsresultat, en detaljeret loglinje eller en munter oversigt genereret af en model, der simpelthen fik for meget adgang og ikke nok overvågning.Det er det første, der er værd at sige klart. AI-datalækage er et teknisk problem, og som de fleste tekniske problemer vokser det i kløften mellem, hvad folk antager, at et system gør, og hvad det rent faktisk har lov til at gøre. Et team bygger en copilot til intern dokumentation. Det fungerer smukt. Så peger nogen den mod en bredere datakilde, beholder de samme brugertilladelser, tilføjer hukommelse, bolter på et par værktøjer,og pludselig vandrer systemet gennem et lager af privat materiale med for stor selvtillid.

Faren kommer fra lydighed uden nok grænsedesign. Det vil blande instruktioner, kontekst, hentet tekst, skjulte prompter, gammel hukommelse og værktøjsoutput til en enkelt arbejdssuppe og producerer derefter noget, der lyder nyttigt. Hvis arkitekturen omkring det er sjusket, bliver hjælpsomheden overordnet. Hvis datagrænserne er svage, bliver bekvemmelighed eksfiltration. Og hvis holdet stoler på hurtig formulering mereend systemdesign, ender historien, som mange historier, der kan forhindres, slutter: med overraskelse, forlegenhed og et møde, ingen ønskede.

Denne artikel handler om at forhindre dette resultat. Vi vil se på de reelle lækageoverflader i moderne AI-systemer, hvorfor det naive forsvar fejler, hvilke kontroller faktisk virker, og hvordan man bygger en lille, men nyttig gateway, som et teknisk team kan køre og udvide. Tonen her er praktisk med vilje. Pointen er at hjælpe dig med at sende et AI-system, der holder datagrænser intakte, selv når nogen skriver en entusiastisk prompt.## Hvorfor AI-lækage sker på så almindelige måderTraditionelle applikationer adskiller normalt roller ret godt. Input kommer ind gennem ét sted, forretningslogik lever et andet sted, og tilladelser håndhæves af eksplicitte kodestier. AI-systemer udvisker disse grænser. Naturligt sprog bliver både input- og kontrolplan. Hentet viden bliver både bevis og angrebsflade. Værktøjsopkald bliver både kapacitet og eksponering. Selv hukommelsen, som lyder harmløsi produktglas, kan blive en langsomgående lækage, hvis ingen er disciplineret med hensyn til, hvad der opbevares og hvor længe.

Det er derfor, almindelige produktteams undervurderer problemet. De tror, ​​de integrerer en model i en arbejdsgang. I virkeligheden introducerer de et probabilistisk middleware-lag, der med glæde rekombinerer data fra flere tillidszoner. Hvis systemprompten siger "afslør aldrig hemmeligheder", lyder det respektabelt. Det ændrer heller ikke på den underliggende kendsgerning, at modellen stadig kan se disse hemmeligheder, ræsonnere forbidem og blive manipuleret til at pakke dem i en form, som designerne ikke havde forudset.

Microsofts vejledning til sikring af AI-applikationer til virksomheder gør dette på et nøgternt virksomhedssprog: datalækage, hurtig indsprøjtning og styringshuller er allerede blandt de største bekymringer, organisationer står over for, når de implementerer AI. Dokumentet er høfligt, men budskabet er direkte. Hvis AI har bred adgang og svagt overblik, glider følsomme oplysninger. Når du først ser det, er det rigtige spørgsmål ikke længere "Hvordan gør vigøre prompten strengere?” Det rigtige spørgsmål bliver "Hvorfor er modellen overhovedet i stand til at se dette materiale, og hvilken kontrol mislykkedes, før prompten overhovedet blev skrevet?"Den ændring i mindset betyder noget. Moden AI-sikkerhed begynder, før modellen rører det første token. Det begynder med dataklassificering, genfindingsgrænser, adgangskontrol, logningsdisciplin og værktøjsautorisation. Med andre ord er forebyggelse af AI-datalækage for det meste systemteknik, der bærer et AI-badge.

De rigtige lækageoverfladerDet hjælper at holde op med at tale om "AI-systemet", som om det var én boks. Lækage sker normalt gennem en af ​​fem stier, og hver sti har sin egen fejltilstand.Den første vej er promptgrænsen. Teams bekymrer sig ofte om brugerprompter og glemmer, at prompter kun er én kilde til instruktioner blandt flere. En model kan også indtage skjulte systeminstruktioner, hentede dokumenter, opsummeret chathistorik og data fra eksterne værktøjer. Hvis en af ​​disse kilder indeholder modstridende eller over-bredt indhold, er promptgrænsen allerede kompromitteret. OWASPs arbejde med LLManvendelsesrisici har været nyttig, netop fordi det tvinger teams til at stoppe med at behandle prompte injektioner som et festtrick og begynde at behandle det som et kontrolflyproblem.

Den anden vej er hentning. Genfinding-augmented generation ser ryddelig ud i arkitekturdiagrammer. Der er et vektorindeks, en forespørgsel, et rangeringstrin og et par bidder lander i kontekstvinduet. Det ser ud til at være kontrolleret, indtil du husker, at disse bidder kan indeholde oplysninger fra den forkerte lejer, forældede tilladelser, forgiftede dokumenter, ikke-gennemgåede eksporter eller tekst, der indeholder skjulte instruktioner til modellen.Hentning er ofte den mest undervurderede lækageflade, fordi den ser almindelig ud. Det føles som at søge. Men søgning med et generativt lag på toppen kan meget hurtigt forvandle en indekseringsfejl til en offentliggørelseshændelse.

Den tredje vej er hukommelsen. Produktteams elsker hukommelse, fordi det får assistenten til at føles mindre træ. Sikkerhedsteams har en tendens til at elske det mindre, fordi hukommelsen ofte vokser ved et uheld. Måske bliver en sessionscache til langtidshukommelse. Måske begynder en intern oversigtsbutik at gemme detaljer længere end beregnet. Måske bliver personligt identificerbare oplysninger bevaret i en bekvemmelighedsfunktion, som aldrig er designet tilfølsomme arbejdsbelastninger. Hukommelse er det sted, hvor venlige UX ideer stille og roligt bliver problemer med fastholdelsespolitikken.

Den fjerde vej er værktøjsbrug. En model, der kan kalde et billetsystem, CRM, kodelager, kalender, SQL-gateway eller intern API er ikke længere kun en tekstmaskine. Det er et handlingssystem. Det kan være produktivt. Det betyder også, at overtilladelse bliver meget dyrere. NISTs seneste arbejde omkring software og AI-agentidentitet og -autorisation er værdifuldt her, fordi det adresserer det punkt, mange teams forsøgerat springe over: Når et AI-system kan handle, holder identitet og autorisation op med at være pæne arkitekturemner og bliver centrale kontrolpunkter.

Den femte vej er output og telemetri. Selvom hentning, hukommelse og værktøjer er rimeligt godt kontrolleret, kan systemet stadig lække gennem svar, spor, fejlfindingslogfiler, evaluatordatasæt, analyse-dashboards og kopierede chatudskrifter. Teams siger ofte "vi afslører ikke hemmeligheder i UI", mens de glemmer, at det samme indhold bliver gemt i logfiler, spor, supporteksporter eller red-team-genafspilningssæt. En lækageer stadig en lækage, hvis det sker i observerbarhedsstakken i stedet for chatbot-boblen.Når først disse fem overflader er synlige, bliver problemet mindre mystisk. Vi forsøger ikke at gøre en sprogmodel moralsk ren. Vi designer et system, hvor ingen enkelt skødesløs beslutning åbner alle døre på én gang.

Hvorfor det naive forsvar mislykkes

Der er flere forsvar, der lyder betryggende i slides og skuffer slemt i rigtige systemer.Det første svage forsvar er hæksystemets prompt. At bede modellen om at holde fortrolige oplysninger skjult er bedre end at sige ingenting, på samme måde er det bedre at låse en cykel med snor end at efterlade den på gaden med en seddel, der siger "vær venlig ikke." Men en prompt er ikke en tilladelsesgrænse. Det giver ingen dataminimeringsgaranti. Det indsnævrer ikke tilbagesøgning. Det stopper ikke modellenfra at se en hemmelighed i sammenhæng. Den forsøger blot at overtale modellen til at opføre sig, efter at de farlige forhold allerede er skabt.

Det andet svage forsvar er sælgeroptimisme. Holdene antager, at udbyderen har autoværn, derfor er problemet blevet outsourcet. Dette er en trøstende fantasi. Leverandørbeskyttelse er nyttige, men de kender ikke din lejermodel, din interne dokumenttaksonomi, dine opbevaringsforpligtelser, dine skjulte admin-slutpunkter eller din mærkelige lille middleware-genvej fra tre kvarter siden, der stadig injicerer for megetkontekst ind i modellen. Administrerede sikkerhedsfunktioner kan reducere risikoen, men de kan ikke erstatte din egen arkitektur.

Det tredje svage forsvar er "vi stoler på vores medarbejdere." Selvfølgelig stoler du på dine medarbejdere. Den egentlige pointe er systemgrænser. Folk træffer hurtige beslutninger under pres. Microsofts diskussion af shadow AI og overdeling er nyttig, fordi den navngiver den akavede sandhed: gode medarbejdere kan stadig lægge følsomme oplysninger ind i den forkerte model, forbinde en godkendt model til den forkerte datakilde eller behandle en varig chatudskrift som midlertidig. Tillid til mennesker er ikke en erstatning for grænser i systemer.Det fjerde svage forsvar tænder kun nogle få filtre på outputtidspunktet. Outputfiltrering betyder noget, men det er det sidste net, ikke grundlaget. Hvis modellen ser for meget, henter for meget, husker for meget eller kan kalde det forkerte værktøj, så forsøger outputfiltrering at moppe gulvet, mens røret stadig er knækket.Mønsteret her er enkelt. Svagt forsvar beder modellen om at opføre sig. Stærke forsvar reducerer, hvad modellen kan se, huske, hente eller kalde i første omgang.

Byg rørledningen, som om modellen var nysgerrig og skødesløsDen reneste mentale model er denne: Behandl modellen som nysgerrig, dygtig, hurtig og ikke fuldt ud troværdig ved grænser. Det betyder ikke, at modellen er ondsindet. Det betyder, at modellen ikke skal have tillid til en bred implicit bedømmelse af, hvad der er sikkert at afsløre.Fra det synspunkt begynder en mere sikker AI-pipeline med dataklassificering. Ikke alle dokumenter bør være lige genfindelige. Ikke alle brugere burde være i stand til at forespørge på den samme kilde. Ikke alle dataklasser bør være tilgængelige for den samme assistenttilstand. Hvis dit AI-lag sidder på toppen af ​​en datasump, hvor klassifikationer er vage, og tilladelser nedarves sjusket, har du endnu ikke et AI-problem. Du har enopbevaring og identitetsproblem med at bære AI makeup.Efter klassificering kommer afhentningspolitik. RAG systemer bør hente de bedste K bidder, der er relevante, lejerkorrekte, tilladelseskorrekte, friskhedskorrekte og sikre til den aktuelle opgave. Det lyder som ekstra arbejde, fordi det er ekstra arbejde. Men det er billigere end at forklare en kunde, hvorfor en kundes interne navngivningskonvention optrådte i en anden kundes angiveligt private svar.Så kommer værktøjsautorisation. En model bør ikke modtage et bredt, magisk værktøjsbælte. Den bør modtage et snævert sæt værktøjer, hvis tilladelser er omfattet af opgaven, brugeren, lejeren og den aktuelle arbejdsgangtilstand. Værktøjskald bør også kunne observeres. Hvis en model kan slå optegnelser op, generere eksporter, skrive til systemer eller udløse arbejdsgange, skal handlingssporet kunne inspiceres af mennesker, der ikke har skrevetoriginal demo.Hukommelsen har brug for den samme disciplin. Hold kortsigtet kontekst kort. Hold langtidshukommelsen eksplicit. Giv lagrede minder etiketter, levetider og slettestier. Beslut hvilke kategorier af oplysninger der aldrig bliver gemt. Hvis du ville være utilfreds med at se et stykke tekst i en supporteksport, skal du kun gemme det som holdbar hukommelse, når stier til politik, ejerskab og sletning er eksplicitte.Sæt endelig udgangskontrol på vej ud. Detektion af følsomme mønstre, kontrol af politikker, strukturerede tilladelseslister for højrisiko-outputklasser og selektiv menneskelig godkendelse er ikke tegn på mistillid til modellen. De er tegn på voksenlivet i systemet.

RAG Grænser, der faktisk betyder nogetRAG er ofte der, hvor AI-produkter går fra legetøj til forretningssystem, og det er netop derfor, det fortjener mere mistænksomhed, end det normalt får.Den første grænse er lejerisolation. Afhentningsbutikker, der blander lejere og er afhængige af blød filtrering senere, er ulykker, der venter på at ske. Hvis dataene virkelig er af høj værdi, er det reneste svar ofte fysisk eller logisk adskillelse, før hentning overhovedet starter. Det mindre elegante, men stadig respektable svar er aggressiv metadatafiltrering, der anvendes, før rangeringsresultater afleveres til modellen. Det værstesvaret er at hente bredt, stole på, at modellen udleder relevans og håbe, at den ikke syr de forkerte fragmenter sammen.

Den anden grænse er dokumenttillid. Ikke alle indekserede dokumenter fortjener den samme autoritet. Nogle blev skrevet af betroede interne teams. Nogle blev eksporteret fra andre systemer. Nogle kan være brugerleveret. Nogle kan være forældede. Nogle kan være forgiftede. Forskning i dataekstraktionsangreb i genfindingssystemer har betydning her, fordi hentning kan importere ondsindede instruktioner og skjulte triggere. Et hentelag, der har nrbegrebet tillidsniveau beder en meget dyr autofuldførelsesmotor om at fungere som sikkerhedsanmelder.

Den tredje grænse er chunk-hygiejne. Teams elsker at tale om chunk-størrelse, overlapning og indlejring af modeller. De taler sjældnere om, hvorvidt klumpen skulle eksistere i første omgang. Indeholder den hemmeligheder, der burde have været redigeret før indeksering? Indeholder det interne kommentarer, legitimationsoplysninger eller fejlretningsrester? Bevarer det unødvendige identifikatorer, når abstrakte opsummeringer ville gøre det? En RAG rørledningder indtager alt først og stiller sikkerhedsspørgsmål senere er en håbefuld pipeline.Den fjerde grænse er citationsdisciplin. En model burde ideelt set vide, hvilke bidder der bidrog til svaret, og hvilke politikker der tillod disse bidder i kontekst. Forklarlighed hjælper med at reagere på hændelser. Når der sker noget slemt, er "modellen må have set det et sted" ikke en tilfredsstillende sætning.

Agenter multiplicerer sprængningsradius

Simple chatsystemer kan lække. Midler kan lække og handle.Forskellen betyder noget. Når en model kan beslutte, hvilket værktøj den skal kalde, i hvilken rækkefølge, med hvilke parametre, over hvilken hentet kontekst, bliver angrebsfladen bredere, og ulykkesfladen bliver bredere med den. Problemet er ikke længere kun "Vil assistenten sige noget, den ikke burde?" Problemet bliver "Vil assistenten beslutte sig for at forespørge på noget, den ikke burde, kombinere det med hukommelse, det ikke burde have beholdt,og overdrage resultatet til en arbejdsgang, der aldrig var beregnet til at køre på det grundlag?”Derfor kan agentsikkerhed ikke reduceres til prompt engineering. NISTs aktuelle interesse i agentidentitet og autorisation er ikke bureaukratisk dekoration. Det er en erkendelse af, at værktøjsbrugende AI-systemer har brug for identitet, privilegieomfang og godkendelseslogik, der er læselig uden for selve modellen.I praksis betyder det, at nogle få umoderne strenge vaner hjælper meget. Adskil læseværktøjer fra skriveværktøjer. Adskil lavrisiko-hentning fra højrisikohandlinger. Brug kortvarige legitimationsoplysninger. Få farlige handlinger til at kræve en eksplicit godkendelsessti. Registrer, hvorfor agenten mente, at et værktøjsopkald var nødvendigt. Og tillad ikke, at det samme brede adgangstoken flyder på tværs af alle trin i arbejdsgangen som et kongeligt pas.Et lille modeksempel tydeliggør pointen. Antag, at en intern AI-assistent kan søge i videnbasen, læse spørgsmålstegn, udarbejde et kundesvar og til sidst sende dette svar. Et svagt design lader den samme agent udføre hvert trin fra ende til anden. Et stærkere design gør det muligt for assistenten at hente og udkast, men kræver et separat, revideret godkendelsestrin, før en udgående besked sendes. Begge systemer kan dukke oplige så poleret i en demo. Kun én opfører sig, som den forventer, at den virkelige verden eksisterer.## En referenceimplementering, du rent faktisk kan køre

Den bedste politik er den, der overlever kontakt med kode. Så lad os bygge en lille Python gateway, der demonstrerer kerneidéerne: Rediger åbenlyse hemmeligheder fra indgående tekst, filtrer hentede bidder efter lejer og klassifikation, begrænse værktøjsopkald til en tilladelsesliste pr. anmodning, og scan det udgående svar, før det forlader.Dette kompakte skelet fremtvinger de rigtige arkitektoniske vaner.

`ai_leakage_gateway.py````python

from future import annotations

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

SECRET_PATTERNS = { "aws_accesskey": 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"), "privatekey": 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() ### Kør detbash python ai_leakage_gateway.py

## Modeksempler værd at huskeDet hjælper at holde et par dårlige mønstre på væggen, fordi teams gentager dem med deprimerende kreativitet.Et dårligt mønster er den universelle copilot. Det har adgang til alt, fordi "vi vil have en samlet oplevelse." I praksis betyder dette ofte, at assistenten kan se mere, end noget menneske nogensinde ville få lov til at se på ét sted. Når det system lækker, er den egentlige synder ikke modellen. Synderen er arkitektonisk grådighed.Et andet dårligt mønster er den "sikre RAG"-demo, der stille og roligt indekserer rå eksport fra delt lager. Demoen ser vidunderlig ud, indtil nogen spørger, om vektorbutikken håndhæver lejergrænser ved hentning eller først efter, at svaret er udarbejdet. Hvis svaret er vagt, er risikoen slet ikke vag.En anden er hukommelsesfunktionen, som ingen ejer. Produktet mener, det forbedrer kontinuiteten. Sikkerheden forudsætter, at den er kortvarig. Juridisk antager tilbageholdelse er defineret et andet sted. Support opdager seks måneder senere, at gamle uddrag stadig kan dukke op igen. Sådan bliver uskyldige funktioner til styringsfejl.Så er der skovningsfælden. Ingeniører tilføjer ofte rige spor under udviklingen, lover at rense dem senere og gør det aldrig. Resultatet er, at produktet UI kan være respektabelt, mens observerbarhedsstakken bliver et museum for følsomt materiale. Dette er en af ​​de mest kedelige lækageveje og en af ​​de mest almindelige.God teknik ser ofte smallere, mere eksplicit og mindre magisk ud. Det markerer systemer bygget til at overleve kontakt med virkeligheden.

## De organisatoriske kontroller betyder mere, end folk vil indrømme

Løsning af problemer i kode har tjent noget af sin romantik. Men forebyggelse af AI-lækage er også et disciplinproblem.Hold har brug for en godkendt værktøjspolitik, fordi skygge-AI er ægte. De har brug for grundlæggende datahåndteringsregler for prompter og uploads. De har brug for en måde at beslutte, hvilke interne systemer der må fodre AI-funktioner, og hvilke der ikke er. De har brug for gennemgangsveje til højrisikobrugssager. De har brug for nogen, der ejer fastholdelse. De har brug for nogen, der ejer model- og værktøjsinventar. Og de har brug for ydmygheden til at sige: "Denne arbejdsbyrde erikke klar til bred AI-adgang endnu."

De bedste tekniske kontroller i verden vil stadig kæmpe, hvis organisationen behandler hver AI-funktion som en nødgenvej til produktivitet. Sikkerheden er nemmere, når virksomheden leverer sikre alternativer og gør den godkendte sti brugbar. Microsofts vejledning får dette rigtigt. Folk går rundt om friktion. Hvis den sikre vej er elendig, og den usikre vej er hurtig, vil den usikre vej udvikle en loyalfølge.Så ja, byg autoværnet. Men gør også den sikre arbejdsgang brugbar nok til, at ingeniører og vidensarbejdere ikke føler, at de bliver straffet for samarbejde.

## Hands-On Lab: Gør demoen til en Real Policy Gateway

Hvis du vil bevæge dig fra teori til noget, dit eget hold kan røre ved, er dette en god weekend-øvelse.

Start med Python-gatewayen ovenfor og giv den en rigtig politikfil.### `policy.json````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"]
    }
  }
}
```Forlæng derefter gatewayen, så:

1. brugere og roller indlæses fra politik i stedet for at blive hårdkodet;
2. Hentningsstykker afvises, medmindre både lejer og etiket matcher;
3. hvert blokeret værktøjskald logges med en årsag;
4. udgående svar, der indeholder hemmelige strenge, sættes i karantæne i stedet for at returneres;
5. Hukommelse skrives kun til tilladelseslistede samtaletyper.Hvis du gør det ærligt, vil du bemærke noget nyttigt. Problemet holder hurtigt op med at føles som "prompt engineering" og begynder at føles som det, det virkelig er: et sikkerheds- og systemintegrationsjob med en model i midten.

## Testopgaver for entusiaster

Hvis du vil skubbe artiklen videre og lære noget rigtigt i stedet for blot at nikke med, så prøv disse:1. Tilføj en `tenant_id` mismatch test og bevis, at den forkerte del aldrig når prompten.
2. Udvid outputfilteret til at markere kunde-id'er, interne billetreferencer og betalingsartefakter.
3. Tilføj et andet trin, der kræver menneskelig godkendelse, før noget skriveegnet værktøj kan køre.
4. Gem kun korttidshukommelsen i femten minutter, og tilføj derefter automatiske udløbs- og sletningslogfiler.
5. Byg to røde team-prompter: endirekte, en skjult inde i hentet tekst, og se hvilken kontrol der fanger hvilken fejl.## Konklusion

Forebyggelse af AI-datalækage starter med et system, hvor følsomme data klassificeres tidligt, hentning er scoped korrekt, hukommelse er begrænset, værktøjer er snævert autoriseret, og output kontrolleres, før de forlader bygningen.Det lyder måske mindre glamourøst end marketingversionen af ​​AI. God. Glamour er overvurderet i sikkerhed. De hold, der lykkes her, er som regel dem, der er villige til at være umoderne præcise. De bestemmer, hvad modellen må se, hvad den må gøre, hvad den må huske, og hvad der skal gennemgås af et menneske. De beder ikke modellen om at udvikle etik gennem tegnsætning.Og det er på en stille måde opmuntrende. Fordi løsningen er ingeniørarbejde. Hård ingeniørarbejde til tider, ja. Lidt irriterende teknik, bestemt. Men stadig ingeniør. Hvilket betyder, at det kan ræsonneres om, testes, forbedres og sendes.Hvis dit AI-system allerede rører ved følsom information, er det nu et meget godt tidspunkt at stoppe med at beundre assistenten og begynde at inspicere grænserne omkring den. Det er der, den virkelige historie altid har været.

## Referencer- 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, *Software- og AI-agentidentitet og -autorisation*: https://www.nccoe.nist.gov/projects/software-and-AI-agent-identity-and-authorization
- OWASP, *Top 10 for LLM applikationer*:https://owasp.org/www-project-top-10-for-large-language-model-applications/
- AWS, *GENSEC04-BP02: Implementer kontroller for at beskytte mod hurtige injektioner og jailbreak-forsøg*: https://docs.aws.amazon.com/wellarchitected/latest/generative-AI-lens/gensec04-bp02.html
- AWS, *Navigering af sikkerhedslandskabet for generativ AI*:https://docs.aws.amazon.com/pdfs/whitepapers/latest/navigating-security-landscape-genai/navigating-security-landscape-genai.pdf
- Microsoft, *Guide til sikring af den AI-drevne virksomhed: Kom godt i gang med AI-applikationer*: https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/microsoft/final/en-us/microsoft-brand/documents/Securing-the-AI-Powered-Enterprised-Enterprised-Enterprised-AiStarlications-with-AI
-Yupei Lv et al., *PLeak: Prompt Leaking Attacks Against Large Language Model Applications*: 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
## Sådan ser det ud, når systemet allerede er under pres

Forebyggelse af AI-datalækage har en tendens til at blive presserende i det nøjagtige øjeblik, et team håbede på et mere stille kvartal. En funktion er allerede foran kunderne, eller en platform har allerede intern afhængighed, og systemet har valgt den pågældende uge for at afsløre, at dets elegante teori og dets runtime-adfærd høfligt har levet separate liv. Det er derfor, så meget seriøst ingeniørarbejde starter medforsoning. Teamet er nødt til at forene, hvad det mener, systemet gør med, hvad systemet rent faktisk gør under belastning, under forandring og under den slags deadlines, der gør alle lidt mere kreative og lidt mindre kloge.

I virksomheders AI-systemer er de sager, der betyder mest, normalt videncopiloter med flere lejere, interne assistenter med hukommelse og værktøjsbrugende agenter med eksport. Disse situationer har tekniske, budgetmæssige, tillid, køreplaner og nogle gange omdømmekonsekvenser. Et teknisk problem bliver politisk større i det øjeblik flere hold er afhængige af det, og ingen kan helt forklare, hvorfor det bliver ved med at skabe støj, forsinkelse ogkoste.

Derfor anbefaler vi at læse problemet gennem linsen af ​​driftstryk og leveringsvirkelighed. Et design kan være teoretisk smukt og driftsmæssigt ødelæggende. Et andet design kan være næsten kedeligt og alligevel bære produktet frem i årevis, fordi det er målbart, repareres og ærligt om dets afvejninger. Seriøse ingeniører lærer at foretrække den anden kategori. Det giver færre episke taler, menogså færre nødretrospektiver, hvor alle taler passivt, og ingen husker, hvem der godkendte genvejen.## Praksis, der konsekvent ældes godtDen første varige praksis er at holde én repræsentativ vej under konstant måling. Hold indsamler ofte bred telemetri, før de definerer det signal, der vil ændre beslutningen. Vælg den vej, der virkelig betyder noget, mål den gentagne gange, og nægt at lade diskussionen glide over i dekorativ historiefortælling. I arbejdet omkring forebyggelse af AI-datalækage er de nyttige foranstaltninger normalt genfindingsomfang, hukommelseopbevaringsregler, værktøj-for-værktøj-autorisation og udgående scanning. Når de først er synlige, bliver resten af ​​beslutningerne mere menneskelige og mindre mystiske.

Den anden varige praksis er at adskille bevis fra løfte. Ingeniører bliver ofte presset til at sige, at en retning er lige før systemet har opnået den konklusion. Modstå det pres. Byg først et snævert bevis, især når emnet er tæt på kunder eller penge. En lille verificeret forbedring har mere kommerciel værdi end en stor ikke-verificeret ambition. Dette lyder indlysende indtil en kvartende anmeldelsegør en hypotese til en deadline, og hele organisationen begynder at behandle optimisme som en planlægningsartefakt.

Den tredje varige praksis er at skrive anbefalinger på ejerskabssproget. Et afsnit, der siger "forbedre ydeevne" eller "styrke grænser" er følelsesmæssigt behageligt og operationelt ubrugeligt. Et afsnit, der siger, hvem der ændrer hvad, i hvilken rækkefølge, med hvilken tilbagerulningstilstand, er den, der faktisk overlever mandag morgen. Det er her, meget teknisk skrivning fejler. Det vil gerne lyde avanceretmere, end det ønsker at være skemalagt.## Modeksempler, der sparer tid

En lokal succes beviser ikke parathed til et hårdere miljø. Før man skalerer ideen, skal teamet opgradere måledisciplinen og bevise, at den samme adfærd holder under stærkere pres.Et andet modeksempel er værktøjsinflation. En ny profiler, en ny runtime, et nyt dashboard, en ny agent, et nyt lag af automatisering, en ny wrapper, der lover at harmonisere den gamle wrapper. Ingen af ​​disse ting er i sagens natur dårlige. Problemet er, hvad der sker, når de bliver bedt om at kompensere for en grænse, som ingen har angivet klart. Systemet bliver så mere instrumenteret, mere imponerende og kun lejlighedsvis mereforståelig. Holdene mærker det meget hurtigt. Selv uden den frasering kan de lugte, når en stak er blevet en dyr erstatning for en beslutning.

Det tredje modeksempel er at behandle menneskelig anmeldelse som en automatiseringsfejl. I rigtige systemer er menneskelig gennemgang ofte den kontrol, der holder automatisering kommercielt acceptabel. Modne teams ved, hvor de skal automatisere aggressivt, og hvor de skal holde godkendelse eller fortolkning synlig. Umodne teams vil have maskinen til at gøre alt, fordi "alt" lyder effektivt i en rutsjebane. Så kommer den første alvorlige hændelse,og pludselig genopdages manuel gennemgang med oprigtigheden af ​​en konverteringsoplevelse.## Et leveringsmønster, vi anbefaler

Godt arbejde starter med at reducere stress med en teknisk læsning, der er stærk nok til at stoppe cirkulær debat. Den næste afgrænsede implementering forbedrer én vigtig vej, og gentesten gør retningen læselig for ingeniører og ledere. Denne sekvens betyder mere end det nøjagtige værktøjsvalg, fordi det er det, der forvandler tekniske færdigheder til fremadgående bevægelse.Rent praktisk anbefaler vi en snæver første cyklus: saml artefakter, lav en hård diagnose, send en afgrænset ændring, test den rigtige vej igen, og skriv den næste beslutning i almindeligt sprog. Klart sprog betyder noget. Et hold fortryder sjældent klarhed. Et team fortryder ofte at blive imponeret, før kvitteringerne ankommer.Det er også her, tonen betyder noget. Stærkt teknisk arbejde skulle lyde, som om det har mødt produktion før. Rolig, præcis og præcis om afvejninger og beviser. Denne tone bærer et operationelt signal. Det viser, at holdet forstår den gamle sandhed om systemteknik: Maskiner er hurtige, køreplaner er skrøbelige, og før eller siden kommer regningen for hver antagelse, der fik lov til at forblive poetisk.