Ikke gi den nøklene til advokatkontoret: slik begrenser du en KI-agent

En KI-agent trenger ikke tilgang til alt for å gjøre en oppgave godt. Det nyttige spørsmålet er ikke om vi stoler på modellen, men hva den kan gjøre selv når den tar feil.

En assistent svarer. En agent handler. Den kan åpne filer, kjøre kommandoer, hente informasjon fra tjenester, endre dokumenter eller sende resultatet til en annen person. Denne kapasiteten sparer arbeid, men endrer også sikkerhetsspørsmålet. Det er ikke lenger nok å kontrollere hva KI-en sier. Vi må avgjøre hva vi lar den gjøre før den begynner.

På et advokatkontor ville det å gi full tilgang til datamaskinen for å oppsummere en kontrakt være som å overlevere nøklene, alarmkoden og hele arkivet for å finne én mappe. Oppgaven kan være legitim. Tilgangen er likevel uforholdsmessig omfattende.

To nyere hendelser viser hvorfor dette er viktig. Claude Code rettet tilfeller der regler for avvisning eller bekreftelse kunne svikte ved sammensatte kommandoer, filer som ble åpnet gjennom symbolske lenker, og kommandoer med miljøvariabler foran.[1] Apple varslet på sin side ytterligere kontroller for å gi full disktilgang. Selskapet minnet om at denne tillatelsen omgår en stor del av de vanlige beskyttelsesmekanismene i macOS og kan eksponere filer, e-post, meldinger og nettleserhistorikk.[2]

Dette er ikke en grunn til å avvise agenter. Det er en grunn til å behandle dem som operatører med tillatelser, ikke som enkle tekstbokser.

Den avgjørende tillatelsen handler om omfang

Prinsippet om minste privilegium er eldre enn KI. NIST definerer det som å begrense hver bruker — eller prosess som handler på brukerens vegne — til de minste privilegiene som er nødvendige for å utføre den tildelte oppgaven.[3] Anvendt på en agent krever det at vi skiller mellom funksjoner som ofte samles under én enkelt avkrysningsboks for «tilgang»:

• Lese: åpne dokumentene i en bestemt mappe.
• Skrive: opprette eller endre filer innenfor et arbeidsområde.
• Kjøre: starte programmer, skript eller kommandoer.
• Koble til: hente informasjon fra internett, et API eller et internt system.
• Sende eller publisere: skape en synlig virkning utenfor arbeidsmiljøet.
• Slette eller endre tillatelser: utføre handlinger som er vanskelige å reversere.

Disse fullmaktene innebærer ikke samme risiko. En agent kan trenge å lese tre kontrakter uten å trenge hele klientens e-post. Den kan utarbeide et svar uten å kunne sende det. Den kan lage en ny versjon uten å overskrive originalen. Den kan kontrollere et nettsted uten å ha tilgangsopplysningene som trengs for å sette det i produksjon.

Sikkerheten blir bedre når tillatelsen følger oppgaven og utløper når den er ferdig. «Arbeid med denne saken i én time» er en tydeligere definert tillatelse enn «du kan få tilgang til dokumenthåndteringssystemet». «Lag et utkast i denne mappen» er lettere å kontrollere enn «rediger filene mine». Produktnavnet betyr mindre enn denne faktiske avgrensningen.

De tekniske grensene svikter også

En regel om avvisning virker enkel: Hvis en farlig kommando dukker opp, blir den blokkert. I praksis kan den samme virkningen uttrykkes på mange måter. En kommando kan inngå i en kjede, stå etter en variabeltilordning eller nå en fil gjennom en indirekte sti. Rettelsene i Claude Code v2.1.289 er verdifulle nettopp fordi de synliggjør denne kompleksiteten.[1]

Den riktige konklusjonen er ikke at tillatelsesregler er ubrukelige. Den er at ikke ett lag alene skal bære hele sikkerhetsansvaret. En liste over forbudte kommandoer hjelper, men erstatter ikke isolering av filsystemet. Menneskelig godkjenning hjelper, men erstatter ikke en konto uten tilgang til produksjon. En logg hjelper ved undersøkelser, men gjør ikke om på en e-post som er sendt til feil mottaker.

Det er heller ikke nødvendig å tillegge modellen onde hensikter. En tvetydig instruksjon, en fil med villedende innhold, en feiltolkning eller en feil i applikasjonen som utfører handlingen, er nok. Å utforme avgrensningen handler om at en vanlig feil skal få vanlige konsekvenser.

Apple belyser det samme problemet fra en annen vinkel. Full disktilgang ble laget for særskilte bruksområder, som visse programmer for sikkerhetskopiering. Når en applikasjon med agentfunksjoner får denne tilgangen, dekker tillatelsen ikke lenger én bestemt operasjon, men åpner en svært stor del av brukerens digitale liv.[2] Spørsmålet er ikke bare «stoler jeg på denne applikasjonen?», men «hvorfor trenger den å se alt for å løse denne oppgaven?».

En praktisk modell for advokatkontoret

Det er ikke nødvendig å bygge en avansert arkitektur fra første dag. Men det er klokt å fastsette fem grenser før en agent kobles til reelt arbeid.

1. Et eget arbeidsområde

Kopier eller lenk bare de nødvendige dokumentene til en mappe for saken. Unngå å starte agenten fra hjemmemappen, hele postkassen eller en delt disk med andre klienters materiale. Hvis oppgaven kan løses med lesetilgang, begynn uten skrivetillatelse. Hvis agenten må produsere filer, gi den en ny utdatamappe, ikke originalen.

2. En egen identitet med begrenset tilgang

Ikke gi agenten partnerens, administratorens eller den IT-ansvarliges vanlige tilgangsopplysninger. Bruk en egen konto med tilgang til bare de nødvendige repositoriene, postkassene eller tjenestene. Foretrekk midlertidige tilgangsopplysninger som kan tilbakekalles. En nøkkel med begrenset tilgang gjør det mulig å stenge én dør uten å skifte alle låsene på advokatkontoret.

3. Nettverk og verktøy etter behov

En agent som gjennomgår lokale dokumenter, trenger kanskje ikke internett. Hvis den må slå opp kilder, begrens destinasjonene når det er mulig. Hvis den bruker koblinger til andre systemer, aktiver bare de nødvendige operasjonene. «Søke etter saker» og «endre saker» bør være forskjellige tillatelser.

4. Godkjenning ved eksterne virkninger

Handlinger med lav risiko som kan reverseres, kan utføres innenfor avgrensningen uten å avbryte fagpersonen. Handlinger som krysser denne grensen, må stanse. På et advokatkontor er kontrollpunktene vanligvis få og tydelige: sende en e-post, inngi et prosesskriv, publisere innhold, sette et system i produksjon, slette informasjon, endre tilganger eller dele data med en tredjepart.

Godkjenningen må vise det nøyaktige innholdet i handlingen: hva som skal sendes, til hvem, fra hvilken konto og med hvilke filer. En tillatelse til å publisere en bestemt versjon kan dekke hele den tekniske sekvensen — lagre, sette i produksjon og kontrollere — så lenge innholdet, destinasjonen og tillatelsene ikke endres. Hvis ett av disse elementene endres, endres også beslutningen.

5. Logging, testing og tilbakekalling

Bevar tilstrekkelige spor til å svare på tre spørsmål: Hva ba personen om, hva forsøkte agenten å gjøre, og hva skjedde faktisk? Registrer også avvisninger og godkjenninger. Når arbeidet er ferdig, trekk tilbake de midlertidige tilgangsopplysningene og steng tilgangen. En tillatelse ingen husker å tilbakekalle, blir ved et uhell til permanent infrastruktur.

Kontrollene fungerer bedre i flere lag. For Codex beskriver OpenAI to utfyllende mekanismer: sandkassen setter den tekniske grensen — hvor agenten kan skrive, eller om den kan bruke nettverket — og godkjenningspolicyen avgjør når den må stanse og be om tillatelse.[4] Det samme mønsteret kan brukes uten å ta i bruk et bestemt verktøy: en grense maskinen ikke kan krysse, og en menneskelig beslutning om unntakene.

Test før utvidelse: en reell pilot

I en nylig pilot brukte jeg Hermes til å koordinere en oppgave og Codex til å utføre den innenfor ett enkelt repositorium. Den første testen startet med bare lesetilgang, uten nettverk og uten tillatelse til å endre andre arbeidsområder. Instruksjonen identifiserte repositoriet, grenen og utgangspunktet. Da testen var ferdig, kontrollerte vi uavhengig at committen ikke var endret, og at arbeidstreet fortsatt var rent.

Dette resultatet viste ikke at modellen var ufeilbarlig. Det viste noe mer nyttig: at den kunne gi et gyldig svar uten å få skrivetillatelser eller generell tilgang til datamaskinen.

Den andre beslutningen var organisatorisk. Hermes koordinerte og verifiserte; Codex utførte. Det var ikke to agenter som skrev samtidig i det samme arbeidsområdet. Å utarbeide utkast og kjøre tester kunne gjøres innenfor avgrensningen. Publisering, produksjonssetting eller kontakt med tredjeparter krevde uttrykkelig godkjenning.

Kontrollen ble ikke lagt til som en byråkratisk gjennomgang til slutt. Den var en del av oppdraget: omfang, tillatelser, forventet resultat og kriterium for verifisering. Først etter at et konkret behov var observert, ga det mening å utvide hva agenten kunne gjøre.

Risikoen ved å spørre for mye

Et system som ber om tillatelse for hver lesing, hvert søk og hver rutinekommando, ender med å lære brukeren å trykke «Godta». Godkjenningstretthet er ikke en teoretisk innvending. OpenAI har beskrevet hvordan hyppige avbrytelser kan få brukere til å aktivere full tilgang, lage altfor vide regler eller godkjenne uten å forstå konsekvensen; selskapets interne data om automatisk gjennomgang viser en svært stor reduksjon i avbrytelser, selv om selskapet selv advarer om at denne mekanismen ikke gir deterministiske garantier.[5]

Løsningen er ikke å fjerne godkjenningene, men å plassere dem ved de riktige grensene:

• Innenfor avgrensningen: operasjoner som kan reverseres, blir loggført og er nødvendige for oppgaven.
• Når grensen krysses: kontekstuell gjennomgang eller en spesifikk regel.
• Ved en ekstern virkning eller en virkning som er vanskelig å reversere: menneskelig godkjenning med synlig innhold og destinasjon.

Slik konsentreres oppmerksomheten der den er mest verdifull. Fagpersonen gjennomgår ikke hundre tekniske steg, men tar stilling til de få handlingene som kan sette konfidensialitet, penger, rettigheter, omdømme eller produksjonsmiljøet i fare.

Ni spørsmål før du trykker «Tillat»

Før en agent brukes med advokatkontorets data eller verktøy, er det klokt å svare skriftlig:

1. Hva er den nøyaktige oppgaven, og når er den ferdig?
2. Hvilke filer og systemer trenger agenten å lese?
3. Hvor kan den skrive, og hvilke originaler er beskyttet?
4. Trenger den nettverk? Til hvilke destinasjoner?
5. Hvilke tilgangsopplysninger skal den bruke, og hvordan tilbakekalles de?
6. Hvilke eksterne eller irreversible handlinger krever godkjenning?
7. Hva får den som godkjenner, se?
8. Hvilken logg vil finnes over instruksjoner, beslutninger og resultater?
9. Har vi testet både en tillatt handling og en handling som skal blokkeres?

Tilliten kan vokse etterpå. Tillatelsene bør ikke komme den i forkjøpet.

En nyttig agent er ikke den som får alle nøklene. Det er den som kan fullføre arbeidet sitt med én nøkkel med begrenset tilgang, i den tiden som trengs, mens de viktige dørene fortsatt er under menneskelig kontroll.