Krypterte AI-spor kan fortsatt inneholde sensitive opplysninger

Forsidebildet er en AI-generert redaksjonell illustrasjon. Skjermer og dokumenter er illustrerte konsepter.

At noe i en logg er kryptert, er ikke en grunn til å publisere loggen. I Stealing Reasoning Traces from Proprietary LLM APIs beskriver forskere hvordan krypterte resonneringsblokker kunne sendes gjennom kompatible modeller for å hente ut innholdet. Artikkelen fra august rapporterer funn av personopplysninger og påloggingsdata i blokker fra offentlige kodearkiver.

Metoden utnyttet hvordan blokkene kunne brukes på nytt. Den knekte ikke krypteringen på vanlig måte. Funnet utfordrer antakelsen om at et felt er trygt å dele fordi vi ikke kan lese det.

Se på hele loggen

Et agenttranskript kan inneholde mer enn meldingene som vises i grensesnittet. Verktøysvar, vedlegg, intern kontekst og uleselige felt kan alle inneholde opplysninger fra oppgaven.

Vi anbefaler å bestemme hva som må deles, før økten eksporteres. Et lite eksempel med syntetiske data er ofte nok til å forklare en feil. Hele arbeidsloggen gir mottakeren langt mer informasjon.

En automatisk kontroll for hemmeligheter bør ikke være eneste sjekk. At den ikke finner noe i en uleselig blokk, beviser ikke at innholdet er fritt for sensitive opplysninger.

Hvis loggen allerede ligger offentlig

Finn ut hvilke økter som er publisert, og hvilken informasjon de kunne lese. Begrens videre deling mens dere undersøker eksponeringen. Der påloggingsdata kan ha blitt delt, følg hendelsesrutinene for å trekke dem tilbake, erstatte dem og undersøke bruken.

Å fjerne filen fra siste versjon fjerner ikke kopier eller historikken i kodearkivet. Oppfølgingen må ta hensyn til det, uten å anta at hver publiserte logg er utnyttet.

Lag en egen eksportprosess for senere feilsøking og forskning. Behold arbeidsloggen i riktig tilgangsbegrenset område og lag et gjennomgått eksempel for deling. Det er enklere å gjøre dette før publisering enn etter at noen finner et sensitivt felt.