Alle publikasjoner
Personvern og sikkerhet8. juli 20267 min lesetid

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:

  1. 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.
  2. 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.
  3. 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

1 · Nøkkeletablering
2 · Maskert prompt
3 · Maskert svar
4 · Lokal dekryptering

logget: «⟦K7QX⟧ skylder ⟦B2NM⟧ …»

LLM-leverandør

resonnerer over chiffer-tokens

Figur 1 · Oversikt over protokollen. Sensitive felt maskeres på klientsiden; kun chiffer-tokens passerer den uklarerte kanalen og havner i logger. Koblingen som kreves for å reversere maskeringen forlater aldri klienten.

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.

ModellNøkkeletableringMaskert oppgaveutføringMaskering av svarTotalt
openai/o33/33/33/39/9
anthropic/claude-opus-4-83/30/30/33/9
google/gemini-3.1-pro-preview3/32/33/38/9
Tabell 1 · Beståtte forsøk per steg (n = 3 per celle). Feilene til claude-opus-4-8 er konsistente avslag, ikke kapabilitetsfeil.

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.

openai/o3
anthropic/claude-opus-4-8
google/gemini-3.1-pro-preview
3210
3
3
3

Nøkkeletablering

3
0
2

Maskert utføring

3
0
3

Maskering av svar

Beståtte forsøk · n = 3

Figur 2 · Protokolletterlevelse per steg (beståtte forsøk av 3). Alle modeller etablerer nøkler; atferden divergerer når modellene bes om å operere på og reprodusere maskert innhold.

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.

Siter dette arbeidet

@techreport{lorentzen2026privacy,
  title  = {Privacy in the Application Layer: An In-Context
            Encryption Protocol for LLM APIs},
  author = {Lorentzen, Johannes},
  year   = {2026},
  institution = {Vitr Labs},
  url    = {https://www.vitrlabs.no/research/llm-privacy-protocol}
}

Korrespondanse: research@vitrlabs.no