Personvern i applikasjonslaget: en kontekstbasert krypteringsprotokoll for LLM-API-er
Johannes Lorentzen · Vitr Labs, Trondheim
Sammendrag
Å sende sensitive data til driftede språkmodeller hviler på kontraktuelle garantier som zero data retention, som vi finner at ikke alltid er aktivert som standard og ikke kan verifiseres fra applikasjonssiden. Vi foreslår en lettvekts protokoll i applikasjonslaget, implementert som et Python-bibliotek, der klienten og modellen etablerer et felles maskeringsskjema i kontekst, slik at sensitive felt forblir uleselige både under overføring og i logger hos leverandør eller mellomvare. Vi evaluerer protokolletterlevelse på tre frontier-modeller over tre steg — nøkkeletablering, maskert oppgaveutføring og maskering av svar — med tre forsøk per steg. openai/o3 fullførte alle ni forsøk og google/gemini-3.1-pro-preview åtte av ni, mens anthropic/claude-opus-4-8 etablerte nøkler i hvert forsøk, men avslo konsekvent å operere på eller reprodusere maskert innhold, med henvisning til konflikt med egne retningslinjer. Vi konkluderer med at privacy-by-design må håndheves i applikasjonslaget, og at modellers alignment-policyer kan komme i konflikt med legitime sikkerhetsprotokoller på brukersiden.
1. Introduksjon
Moderne AI-funksjonalitet kjører sjelden der dataene bor. En typisk produksjonsflyt serialiserer kunderegistre, supporthenvendelser eller interne dokumenter inn i en prompt og sender den til en driftet modell over et tredjeparts-API. Leverandørene tilbyr kontraktuelle kontroller for dette — no-training-klausuler og zero data retention-avtaler (ZDR) — men under arbeid med LLM-funksjonalitet i produksjonsnære arbeidsflyter observerte vi at ZDR ikke alltid er implisitt aktivert. Det må verifiseres eksplisitt, per leverandør, per endepunkt og per kontrakt.
Selv der garantiene holder, passerer en forespørsel infrastruktur som kan logge klartekst ordrett: API-gatewayer, rutingslag, observability-verktøy og applikasjonsmellomvare. «No training» er et utsagn om hvordan modellvekter oppdateres; «no retention» er et utsagn om lagring. Ingen av delene er observerbare, langt mindre håndhevbare, fra applikasjonssiden.
Dette reiser et konkret spørsmål: kan vi etablere en protokoll der sensitive felt forblir uleselige selv om hver melding i utvekslingen logges ordrett? Det korte svaret er ja — med et viktig forbehold om modellens samarbeidsvilje, som viser seg å være den bindende begrensningen.
2. Trusselmodell
Vi antar en honest-but-curious-kanal: leverandøren og all mellomliggende infrastruktur utfører oppgaven korrekt, men enhver komponent kan lagre meldingene den ser. Protokollen skal garantere konfidensialitet for utpekte sensitive felt overfor enhver part som leser loggene i etterkant. Den forsøker ikke å skjule informasjon for modellen under inferens utover de maskerte feltene, og den beskytter ikke mot en aktivt ondsinnet leverandør som endrer modellens atferd.
3. Protokollen
Vi implementerte protokollen som et Python-bibliotek som pakker inn chat-completion-kallet, slik at maskering og demaskering er transparent for applikasjonen som kaller. En utveksling skjer i tre steg:
- Steg 1 — Nøkkeletablering. Klienten og modellen blir i kontekst enige om et flyktig, reversibelt maskeringsskjema: en nøkkelbasert substitusjon over de sensitive entitetene i samtalen. Nøkkelmaterialet genereres på klientsiden og avsløres aldri i gjenbrukbar klartekstform.
- Steg 2 — Maskert oppgaveutføring. Før sending erstatter biblioteket sensitive felt med chiffer-tokens. Modellen bes om å utføre selve oppgaven — uttrekk, transformasjon, resonnering — direkte over den maskerte prompten.
- Steg 3 — Maskering av svar. Modellen må holde chiffer-tokens maskert i sitt svar. Biblioteket reverserer deretter substitusjonen lokalt før resultatet returneres til applikasjonen.
Klient (klarert)
klartekst + flyktig nøkkel
Uklarert kanal · gatewayer · logger
logget: «⟦K7QX⟧ skylder ⟦B2NM⟧ …»
LLM-leverandør
resonnerer over chiffer-tokens
4. Eksperimentoppsett
Den resulterende sikkerhetsegenskapen er enkel å formulere: en ordrett logg av utvekslingen, tatt hvor som helst mellom klient og modell, inneholder kun chiffer-tokens. Koblingen som kreves for å reversere dem finnes bare i klientens minne.
For å fastslå om konseptet er teknisk gjennomførbart med dagens frontier-modeller evaluerte vi protokolletterlevelse på tre modeller via deres offentlige API-er: openai/o3, anthropic/claude-opus-4-8 og google/gemini-3.1-pro-preview. Hvert steg ble kjørt i tre uavhengige forsøk. Et forsøk bestås hvis modellen fullfører steget uten å lekke klartekst, bryte skjemaet eller nekte å fortsette. Skårene er dermed antall beståtte forsøk av tre per steg.
5. Resultater
Alle tre modellene fullførte nøkkeletablering i hvert forsøk: ingen modell hadde innvendinger mot å bli enig om et maskeringsskjema. Atferden divergerte først da modellene ble bedt om å operere på og reprodusere maskert innhold.
| Modell | Nøkkeletablering | Maskert oppgaveutføring | Maskering av svar | Totalt |
|---|---|---|---|---|
| openai/o3 | 3/3 | 3/3 | 3/3 | 9/9 |
| anthropic/claude-opus-4-8 | 3/3 | 0/3 | 0/3 | 3/9 |
| google/gemini-3.1-pro-preview | 3/3 | 2/3 | 3/3 | 8/9 |
openai/o3 fullførte alle ni forsøk og holdt substitusjonsskjemaet konsistent gjennom flerstegsoppgaver. google/gemini-3.1-pro-preview besto åtte av ni, med én feil i maskert oppgaveutføring der modellen delvis reverserte chiffer-tokens til klartekst midt i svaret.
anthropic/claude-opus-4-8 er det mest interessante tilfellet. Modellen etablerte nøkler i alle tre forsøk, men avslo å produsere maskert output i samtlige forsøk i steg to og tre, med begrunnelsen at maskering av svarene brøt med modellens retningslinjer. Avslagene var konsistente snarere enn stokastiske — null beståtte av seks forsøk — noe som peker mot en policy i alignment-laget snarere enn en kapabilitetsbrist.
Nøkkeletablering
Maskert utføring
Maskering av svar
Beståtte forsøk · n = 3
6. Diskusjon
Gjennomførbarhet. Resultatene indikerer at konfidensialitetsprotokoller i applikasjonslaget er teknisk gjennomførbare i dag: to av tre frontier-modeller opprettholdt hele skjemaet med høy pålitelighet, uten endringer i leverandørens infrastruktur og uten spesiell API-tilgang.
Alignment som protokollbegrensning. Feilmoden vi observerte i claude-opus-4-8 er ikke en sikkerhetssvikt, men en policykollisjon. Sikkerhetstrening som behandler bevisst obfuskert tekst som en risiko, vil også avvise et personverntiltak som avhenger av obfuskering. I praksis avgjør leverandørens alignment-lag hvilke sikkerhetsprotokoller en applikasjon får lov til å implementere — en dimensjon ved modellvalg som, så vidt vi vet, får lite oppmerksomhet i anskaffelser.
Den praktiske implikasjonen er konklusjonen vi startet fra: «no training» og «no retention» er ikke det samme, og ingen av delene kan verifiseres av klienten. Privacy-by-design må ligge i applikasjonslaget, der den kan håndheves og revideres av parten som eier risikoen.
7. Begrensninger
Kontekstbasert maskering er ikke semantisk sikker kryptering i kryptografisk forstand; en nøkkelbasert substitusjon over entiteter lekker struktur, og styrken avhenger av entitetsgranulariteten klienten velger. Utvalget vårt er lite — tre forsøk per steg — og modelletterlevelse er probabilistisk og versjonsavhengig, så skårene bør leses som et gjennomførbarhetsbilde fra juni 2026 snarere enn en stabil benchmark. Til slutt kan maskering redusere oppgavekvaliteten når oppgaven faktisk krever semantikken i de skjulte verdiene; å kvantifisere den kostnaden er videre arbeid.
8. Konklusjon
Vi spurte om sensitive data kan sendes til driftede LLM-er i en form som forblir uleselig i enhver logg underveis, og fant at dagens frontier-modeller kan opprettholde en slik protokoll — når alignment-policyene deres tillater det. Konfidensialitetsgarantier som tilbys kontraktuelt bør behandles som supplement til, ikke erstatning for, kontroller applikasjonen selv håndhever. Vi planlegger å utvide evalueringen til flere modeller, formalisere sikkerhetsegenskapene til maskeringsskjemaet og måle kvalitetskostnaden ved å operere over maskerte data. Jobber du med lignende problemstillinger, hører vi gjerne fra deg.
