Behörighet för AI-agenter i produktion

I korthet

• Ge varje agent en avgränsad identitet med kort livstid som agerar för en användare i en organisation, aldrig en delad nyckel som lever länge.
• Kontrollera behörigheten vid varje verktygsanrop, inne i verktyget, mot användaren som agenten agerar för.
• Skilj på verktyg som läser och verktyg som skriver, låt en människa godkänna destruktiva åtgärder och logga varje beslut.

Agenten är ingen superanvändare

Det snabbaste sättet att få ut en agent är ett tjänstekonto som når allt, där instruktionen får avgöra vad agenten rör. Det fungerar i en demonstration. I produktion är instruktionen ingen säkerhetsgräns. En otydlig fråga, ett dåligt sökresultat eller en instruktion som gömts i ett dokument kan styra modellen vart som helst där nycklarna räcker.

Se agenten som en ny sorts klient. Den får en identitet, identiteten får behörigheter, och behörigheterna upprätthålls utanför modellen. Modellen föreslår. Behörighetslagret bestämmer.

Agera för en användare, med en avgränsad identitet

En agent ska alltid agera för någon. När en användare ber den göra något bär anropet två identiteter: agenten som utför och användaren den utför åt. Det som gäller är snittet av deras behörigheter, aldrig summan. Agenten ska inte kunna göra något som användaren inte själv får göra.

Utfärda identiteten per session eller per uppgift, begränsad till en organisation och till de verktyg uppgiften kräver, och låt den gå ut efter några minuter. Standardprotokollen för identitet har flöden för tokenutbyte som är gjorda för just den här sortens delegering. Oavsett lösning ska agenten aldrig se en bred nyckel som lever i månader. Läcker en token via en logg eller ett spår ska den vara värdelös inom några minuter.

Kontrollera behörigheten vid varje anrop

Att kontrollera åtkomsten en gång, när sessionen startar, räcker inte. Varje verktygsanrop är en ny begäran, och kontrollen hör hemma i verktyget, inte i instruktionen. Frågan är alltid densamma: får den här användaren, genom den här agenten, utföra den här åtgärden på den här resursen?

Relationsbaserad behörighetsstyrning passar bra. Behörigheterna följer relationer som redan finns lagrade, som användare till grupp, grupp till projekt och projekt till dokument. Kontrollen för ett enskilt dokument blir då en fråga till behörighetstjänsten. Webbappen och agenten ställer samma fråga, så reglerna finns på ett ställe.

async function callTool(ctx: AgentContext, tool: Tool, args: ToolArgs) {
  const allowed = await authz.check({
    subject: `user:${ctx.userId}`,
    actor: `agent:${ctx.agentId}`,
    relation: tool.requiredRelation,
    object: tool.resourceOf(args),
  })
  audit.log({ ctx, tool: tool.name, args: redact(args), allowed })
  if (!allowed) return { error: "not permitted" }
  return tool.run(args, ctx.scopedToken)
}

Ett nekat anrop ger ett tydligt fel som modellen kan förklara för användaren. Ingen stackspårning, och inget tyst nytt försök med andra nycklar.

Skilj på att läsa och att skriva

Alla verktyg bär inte samma risk. Dela in dem i klasser och ge varje klass egna regler.

• Läsverktyg: söka, slå upp och sammanfatta. De kontrolleras ändå per användare, eftersom det är en incident i sig att läsa en annan organisations data.
• Skrivverktyg: skapa ett utkast, ändra ett fält, öppna ett ärende. Snävt avgränsade, och argumenten valideras mot ett schema innan de körs.
• Destruktiva eller externa åtgärder: radera, betala, skicka e-post, ändra åtkomst. De väntar tills en människa har godkänt exakt den åtgärden.

Godkännandet visar vad som kommer att hända, med de verkliga argumenten, och själva godkännandet kontrolleras mot godkännarens behörigheter. En knapp där det bara står fortsätt, utan detaljer, är ingen kontroll.

Logga varje beslut

När något går fel måste ni kunna svara på vem som frågade, vilken agent som agerade, vad den försökte göra, vad som tilläts och vad som nekades. Logga varje verktygsanrop med användare, agent, verktyg, resurs, beslut och en hänvisning till spåret som ledde dit. Maskera argumenten först, så att personuppgifter och hemligheter aldrig hamnar i loggen. Håll loggen utom räckhåll för agenten, så att den inte kan ändra eller radera sin egen historik.

Samma logg visar när en behörighet är för bred. Ett verktyg som aldrig anropas, eller en behörighet som aldrig används, kan tas bort.

Där det möter ett uppdrag

Att ta en agent i drift med avgränsade identiteter, en kontroll vid varje anrop och en spårbar logg är vad en AI-produktionssprint omfattar. Ska agenten köras på en modell som ni driftar själva, se privata finjusterade modeller. När agenten väl är i drift håller AI-drift som tjänst koll på behörigheter, loggar och utvärderingar när modellen och verktygen ändras.

Vanliga frågor

Räcker systeminstruktionen för att hindra en agent från att missbruka ett verktyg? Nej. En instruktion styr beteendet, men innehåll som agenten läser kan köra över den. Upprätthåll behörigheterna i verktygslagret, utanför modellen.

Ska en agent ha ett eget tjänstekonto? Den kan ha en egen identitet, men den ska agera för en användare och bara få snittet av sina egna och användarens behörigheter, under kort tid.

Vilka åtgärder kräver mänskligt godkännande? Allt som är svårt att ångra eller som lämnar ert system: att radera data, flytta pengar, skicka meddelanden och ändra vem som har åtkomst.