Vilka roller och behörigheter behövs när AI-agenter ska använda era system?

Gustav Brochmann

Roller och behörigheter för AI-agenter bestäms i fem steg: lista vad systemet innehåller, bestäm vem som får läsa, ändra och ta bort varje sort, lägg regler per rad där något tillhör en person, låt varje koppling ha en egen omfattning och testa med en användare som har snäv roll. Agenten ska aldrig kunna mer än den person som startade den.

Roller räcker inte, men de är basen

När en AI-agent ska arbeta i ett system räcker det inte att ge den ”en användare”. Frågan är vad olika personer får göra, och hur det följer med till agenten. Här är en metod i fem steg för att bestämma det innan något byggs. Den bygger på principen att agenten ska agera som den person som startade den, se OAuth och AI-agenter.

Fem steg

1. Lista vad systemet innehåller

Bolag, kontakter, offerter, fakturor, utlägg, tidrapporter, anteckningar. En rad per sorts sak. Det blir det som reglerna ska gälla.

2. Bestäm vem som får göra vad

För varje sorts sak: vem får läsa, vem får ändra och vem får ta bort? Skriv det i klartext, till exempel ”alla ser kunder, bara säljare ändrar dem, bara administratör tar bort”. Vanligtvis räcker tre roller: en som bara läser, en som arbetar och en administratör.

3. Lägg till regler per rad

Vissa saker hör till en person, inte till en roll. Ett utlägg tillhör den som skapade det, och en prospektlista kan vara personlig. Det gäller i appen, och därför ska det gälla för agenten. Se Hur låter man en AI-agent uppdatera ett CRM utan att den förstör något? för varför behörigheten måste kontrolleras innan en förändring visas.

4. Låt varje koppling ha en egen omfattning

Den som kopplar sin agent bör kunna välja läs, skriv eller ta bort, och kunna ta tillbaka kopplingen. Det är rimligt att börja med bara läsning. Verktygen ska vara klassade efter samma tre nivåer, så att omfattningen går att tillämpa. Se Hur ser ett bra MCP-verktyg ut?.

5. Testa med fel person

Skapa en testanvändare med snäv roll och försök få agenten att göra sådant den inte borde. Be den läsa någon annans personliga post, ändra ett belopp eller ta bort något. Allt som lyckas är ett fel i reglerna, inte i agenten.

Fallgropar

  • Fulla rättigheter på serversidan. Om servern når allt med en gemensam nyckel är verktygens klassning och kopplingens omfattning den enda spärren. Då måste de vara noga byggda, och det ska bara finnas ett ställe där verktyg definieras.
  • Roller som växer utan översyn. Gå igenom vem som är administratör en gång per kvartal.
  • Behörighet som bara döljer knappar. Ett dolt gränssnittselement är ingen behörighet. Regeln måste ligga i det lager agenten också använder.

Vad det kostar att hoppa över

Det som oftast händer är att ett bolag ger agenten en administratörsnyckel för att få igång en demo, och sedan aldrig byter. Då har ni en agent som kan mer än alla som använder den, och en logg som inte säger vem som gjorde vad.

Kontrollfrågor

  • Kan en medarbetare med begränsad roll få agenten att göra mer än hen själv får?
  • Går det att begränsa en enskild koppling till läsning?
  • Kontrolleras behörigheten före eller efter att data läses?

Ska ni sätta upp roller för agenter i ert system? Hör av er.