--- title: "RAG adatszivárgás 2026: hogyan védd az ügyféladatot" description: "7 konkrét támadási minta, amivel RAG-rendszerek csepegtetnek ki bizalmas adatot · és a 4-rétegű védelem, amit mi alkalmazunk minden RAG-projekten." date: 2026-04-21 updated: 2026-04-21 author: "Mező Dezső" tags: "AI, RAG, Adatvédelem, LLM, GDPR, ai-security, llm-security" slug: rag-adatszivargas-magyar-ugyfel-2026 canonical: https://dfieldsolutions.hu/blog/rag-adatszivargas-magyar-ugyfel-2026 --- # RAG adatszivárgás 2026: hogyan védd az ügyféladatot A RAG nem csak válaszgenerálás · adatszivárogtató vektor, ha nem vigyázol. 7 minta + 4 réteg védelem. A legtöbb RAG-adatszivárgási incidens, amit 2025-ben láttunk, nem a modellből jött. Az infrastruktúrából. Ez a hét konkrét minta, amit minden RAG-projekten átfuttatunk, és a négy-rétegű védekezés, amit alkalmazunk. ## 1 · Cross-tenant retrieval A multi-tenant SaaS klasszikus bugja: a vektor DB nem szűr tenant-ID-ra, így A user kérdésére B tenant dokumentumai jönnek vissza. A pgvector `WHERE tenant_id = $1` klauzula nem opcionális · a hiánya MNB-audit finding, ami élesben kerül 10M+ Ft-ba. ## 2 · System prompt-szivárgás A system prompt, ami tartalmaz belső üzleti logikát vagy ügyfélnevet, kivehető egy jól strukturált prompttal. Tedd minimálisra, amit system promptban adsz meg · a titkokat tool-hívásokba. ## 3 · Embedding visszafejtés Az embedding-vektorok nem titkosítottak. Ha kiteszed őket egy public endpointra (ami gyakori, ha a kereső-API visszaadja a similarity score-okat), egy támadó rekonstruálhatja az eredeti szöveget. Ne legyen publikus endpoint raw embedding-re. ## 4 · Cache-hit exfiltráció Az LLM provider cache (OpenAI prompt caching, Anthropic cache) timing side-channelt nyit: ugyanaz a cache kulcs gyorsabb válasz = ugyanolyan system prompt. Ezzel egy támadó megállapíthatja, hogy más tenantok milyen rendszer-promptot használnak. ## 5 · Naplózott retrieval tartalom A Datadog/CloudWatch loggolás gyakran lekérdezi a retrieval eredményét debug céllal. Ha a dokumentum tartalmaz személyes adatot (ami RAG esetén tipikus), az most a log-rendszeredben van, GDPR szempontból nem a megfelelő helyen. PII-redaction minden log-pointon. ## 6 · Replay · ugyanaz a kérdés, más user Ha az A user egy bizalmas dokumentumot töltött fel és kérdezett rá, a RAG-cache (ha egyáltalán cache-elsz válaszokat) ezt kiadhatja B usernek ugyanarra a kérdésre. A válasz-cache kulcsa mindig tartalmazza a user/tenant ID-t. ## 7 · Túlbő attribution A legtöbb RAG-UI forrást jelez: ez a válasz ezekből a doksikból jön'. Ha a forrás URL tartalmaz user-ID-t vagy belső doc-ID-t, egy támadó kikövetkeztetheti a doksi létezését, még ha nem is férhet hozzá. Az attribution legyen címszint, ne link. ## A 4-rétegű védelem - **Retrieval layer**: minden query WHERE tenant_id = :current_user_tenant. Nincs sharedvektor. Postgres RLS kötelező. - **Prompt layer**: user content szegmentált delimitter között. A modellnek explicit instruktálva: ami a között van, az adat, nem utasítás. - **Response layer**: kimeneti PII-check. Guardrails-AI vagy custom validator. Reject & retry, ha új PII bukkan fel. - **Observability layer**: minden log PII-redactoláson át. A retrieval eredménye sosem naplózódik plain textben; csak hash és chunk-ID. > **NOTE:** Az AI-biztonsági audit checklistunk 15 kérdése pont ezekre a pontokra tér rá · futtasd le a sajátodon: /tools/ai-security-audit --- Source: https://dfieldsolutions.hu/blog/rag-adatszivargas-magyar-ugyfel-2026 Author: Mező Dezső · Alapító, DField Solutions Site: https://dfieldsolutions.hu