Hvad betyder Værktøjsrettigheder?
Værktøjsrettigheder er de tekniske begrænsninger omkring en agents handlinger. De kan afgøre, om agenten må læse en ordre, ændre et udkast eller udføre en ekstern handling. Rettighederne bør følge opgaven og den bruger eller systemidentitet, som agenten arbejder på vegne af.
En instruktion om at være forsigtig er ikke det samme som en adgangsgrænse. Hvis et værktøj teknisk kan ændre alle kunders oplysninger, kan en fejl få større rækkevidde end nødvendigt. Kontrollen skal derfor ligge dér, hvor værktøjet udføres.
Afgræns både handling og data
Skeln mellem læsning, oprettelse, ændring og sletning. Afgræns også hvilke objekter handlingen må gælde: virksomhed, kunde, mappe eller sag. Et værktøj kan godt være tilladt generelt og samtidig skulle afvise et bestemt objekt. Et brugerleveret ID må ikke alene afgøre, hvilke data der åbnes.
Rettigheder kan variere gennem forløbet. En agent kan undersøge sagen først og først få mulighed for en afgrænset ændring, når betingelserne er opfyldt. Den udvidelse skal være konkret og kunne efterprøves; en bred godkendelse af at “løse opgaven” bør ikke skjule en ændring af adgangens omfang.
En skjult knap er ikke en sikkerhedsgrænse
At fjerne et værktøj fra modellens liste kan reducere fejlagtige valg, men serveren skal stadig kontrollere kaldet. Tokens og serviceidentiteter bør være afgrænsede og kunne tilbagekaldes. Log den handling, der blev anmodet om, den identitet der udførte den, og resultatet. Vær samtidig bevidst om, hvilke personoplysninger og hemmeligheder der ikke skal ende i loggen. Test afvisninger lige så grundigt som de tilladte handlinger.
Et eksempel fra praksis
En intern salgsagent må læse produktdata og oprette tilbudskladder for den aktuelle virksomhed. Den får ikke rettighed til at ændre prislisten eller frigive et tilbud. Når et udkast godkendes, udføres frigivelsen gennem et separat, snævert værktøj. Testen prøver blandt andet et kontakt-ID fra en anden virksomhed og en anmodning om at ændre pris. Begge skal stoppes af systemet, også hvis modellen formulerer et teknisk korrekt kald.
Typiske faldgruber
- At stole på prompten som eneste begrænsning af adgang.
- At bruge en fælles administratoridentitet til alle agentopgaver.
- At kontrollere værktøjets navn, men glemme hvilket objekt handlingen rammer.
Det skal I afklare
- Kortlæg handlinger og dataområder for hver agentrolle.
- Håndhæv adgang ved udførelsen og brug afgrænsede identiteter.
- Test uautoriserede objekter, tilbagekaldt adgang og manglende godkendelse.
Spørgsmål og svar
Bør læseadgang også begrænses?
Ja. Læsning kan eksponere oplysninger, som agenten ikke har behov for. En læseagent bør kun kunne hente relevante data inden for den aftalte bruger- og virksomhedsgrænse.
Kan samme værktøj bruges af flere roller?
Ja, hvis det kontrollerer identitet, objekt og handling ved hvert kald. Det er ikke tilstrækkeligt, at rollerne blot har forskellige instruktioner i deres prompt.
Kilder og videre læsning
De tekniske begreber bygger på nedenstående kilder. Eksemplerne er illustrative og viser, hvordan I kan arbejde med emnet.
- Model Context Protocol: Tools ↗Navn, beskrivelse og skemaer for værktøjsinput og output.
- OWASP: API Security Project ↗Adgangskontrol og sikkerhed ved integrationer.