Hvad betyder Mindst mulige rettigheder?
Princippet om mindst mulige rettigheder betyder, at adgang begrænses til det, en opgave kræver. For en AI-agent gælder det både, hvilke oplysninger den kan læse, og hvilke ændringer den kan udføre. En assistent, der skal foreslå et mødetidspunkt, behøver ikke automatisk ret til at slette kalenderaftaler.
Princippet begrænser konsekvensen af fejl og misbrug. En model kan misforstå en besked eller blive påvirket af instruktioner i et dokument. Hvis værktøjerne kun tillader en snæver handling, er der mindre, systemet kan gøre forkert. Adgangsbegrænsningen skal være teknisk håndhævet og ikke kun stå i prompten.
Mindst mulige rettigheder handler også om tid og identitet. En permanent fælles administratorkonto gør det svært at afgrænse ansvar og tilbagekalde adgang. Separate tjenesteidentiteter og opgavebestemte tilladelser giver bedre muligheder for kontrol, når en integration eller medarbejder ikke længere skal have adgang.
Design små værktøjer med tydelige grænser
Giv agenten en funktion til at oprette et udkast frem for fri adgang til at sende enhver mail. Begræns funktionens parametre, modtagere og datakilder efter behov. Adskil læsning fra ændring, og lad en nødvendig godkendelse vise præcis, hvad der sker. Et bredt værktøj som udfør vilkårlig databaseforespørgsel er vanskeligt at afgrænse, selv hvis systemprompten beskriver en smal opgave.
Gennemgå de rettigheder, der samler sig
Tilladelser vokser ofte under udvikling, fordi teamet midlertidigt åbner mere adgang for at løse en fejl. Før drift bør hver rettighed kunne begrundes. Gennemgå adgang igen efter nye funktioner, afsluttede projekter og leverandørskift. Brug logs til at se, hvilke funktioner der faktisk anvendes, men fjern ikke nødvendige sjældne rettigheder uden at forstå opgaven. Test også, at en tilbagekaldt tilladelse stopper handlingen med det samme.
Et eksempel fra praksis
Illustrativt eksempel: En salgsassistent skal hjælpe med opfølgning på tilbud. Første integration bruger en CRM-administratornøgle. Teamet erstatter den med adgang til at læse relevante tilbud og oprette interne opfølgningsopgaver. Ændring af rabat og udsendelse til kunder bliver separate funktioner med godkendelse. Assistenten kan stadig løse den oprindelige opgave, men en fejl i et hentet dokument giver ikke fri mulighed for at ændre hele kunderegisteret.
Typiske faldgruber
- At genbruge en medarbejders fulde administratoradgang i en agent.
- At kalde en handling sikker, fordi den normalt kun læser data.
- At beholde midlertidige udviklingsrettigheder efter lancering.
Det skal I afklare
- Begrund hver datakilde, handling og tjenesteidentitet.
- Adskil læsning, udkast og eksterne ændringer.
- Test tilbagekaldelse, afvisninger og udløbne tilladelser.
Spørgsmål og svar
Gør få rettigheder agenten mindre nyttig?
Grænserne skal passe til opgaven. En præcis funktion kan ofte løse arbejdet med færre risici end bred adgang. Nye behov kan tilføjes efter særskilt vurdering.
Er read-only adgang altid ufarlig?
Nej. Læsning kan afsløre fortrolige eller personlige oplysninger. Datamængde, modtagere og mulighed for at sende oplysninger videre skal stadig begrænses.
Kilder og videre læsning
De tekniske begreber bygger på nedenstående kilder. Eksemplerne er illustrative og viser, hvordan I kan arbejde med emnet.
- OWASP: Excessive Agency ↗Primærkilde gennemgået 7. september 2026.
- OWASP: Authorization Cheat Sheet ↗Primærkilde gennemgået 7. september 2026.