AI-agentens tillåtelsestege: läsa, föreslå, godkänna, agera

AI-agenter blir inte farliga för att de kan läsa en Slack-kanal, en portfölj eller ett kodarkiv. Risken kommer när läsning, förslag och åtgärd blandas ihop. En agent som sammanfattar ett underlag är en sak. En agent som kan skicka order, öppna ändringsförslag eller ändra ett kundflöde är något helt annat.

De senaste signalerna från Anthropic, Interactive Brokers och OpenAI pekar åt samma håll: nästa praktiska AI-fråga är inte bara vilken modell som är bäst. Den är: på vilken nivå får agenten agera, och vem äger steget uppåt?

Börja med en stege, inte en ja/nej-lista

En vanlig behörighetslista säger ofta “har åtkomst” eller “har inte åtkomst”. Det räcker dåligt för agentflöden. Samma datakälla kan vara låg risk om AI bara får läsa den, men hög risk om AI får skriva tillbaka, lägga order, ändra filer eller starta en publicering.

Använd i stället en tillåtelsestege:

• Läsa: agenten får se avgränsat underlag, till exempel en Slack-kanal, ett dokument, en portföljöversikt eller ett kodarkiv.
• Sammanfatta: agenten får skapa en lägesbild, men inte ändra något.
• Föreslå: agenten får rekommendera nästa steg och visa varför.
• Skapa utkast: agenten får skriva ett mejl, en orderinstruktion, en patch eller en CRM-anteckning som väntar på granskning.
• Förbereda ändring: agenten får skapa en PR, fylla i ett formulär eller ställa upp ett arbetsflöde utan att verkställa.
• Begära godkännande: agenten får skicka förslag till rätt ägare med logg, källa, test och risk.
• Utföra och följa upp: agenten får agera inom en smal regel, logga resultatet och ha en tydlig rollback.

Poängen är inte att alla organisationer ska nå översta steget. Poängen är att ni vet vilket steg ni faktiskt står på.

Claude Tag visar varför agenten behöver en egen identitet

Anthropic lanserade Claude Tag som en Slack-baserad beta för Claude Enterprise och Team. Team kan lägga till Claude i utvalda kanaler, koppla verktyg och data, och tagga @Claude för asynkront arbete. Anthropic beskriver också en accessmodell de kallar agentidentitet: agenten ska inte bara låna en människas privata behörigheter, utan ha egna identiteter per arbetsyta och kanal som administratörer kan styra.

Det är en viktig skillnad för alla som bygger agentflöden i teammiljö. Om tre personer styr samma agent i en kanal är frågan inte “vems konto lånar agenten?”. Frågan är “vad får agenten göra i just det här rummet?”.

Källa: Anthropics Claude Tag-lansering och Claudes artikel om agentidentitet

För Hammer-läsare är lärdomen enkel: skapa inte en gemensam AI-genväg via någons personliga konto. Börja med ett begränsat flöde, en namngiven agentidentitet, en ägare och en revisionslogg som faktiskt går att läsa.

IBKR-exemplet visar skillnaden mellan förslag och order

Interactive Brokers beskriver AI-integreringar där ChatGPT, Claude och Grok kan anslutas till ett IBKR-konto via certifierade marknadsplatser för certifierade anslutningar. IBKR skriver att kopplingen bygger på MCP, Model Context Protocol, ett sätt att låta AI-verktyg ansluta till externa system genom avgränsade verktyg och datakällor.

Det viktiga är gränsen: AI kan analysera portföljen och skapa orderinstruktioner, men instruktionerna blir inte automatiskt order. Användaren ska granska och skicka ordern i IBKR-plattformen.

Källa: Interactive Brokers om AI-integreringar

Det är en bra modell även utanför finans. Låt AI läsa, räkna, jämföra och skriva utkast. Men när pengar, kunddata, personalärenden eller myndighetsrapportering påverkas ska steget från utkast till åtgärd vara synligt.

OpenAI Daybreak visar samma sak för patchar

OpenAI beskriver Daybreak, Codex Security och Patch the Planet som ett skifte från att bara hitta sårbarheter till att validera, prioritera, föreslå patchar, testa och hjälpa människor att få fixar i produktion. Det är frestande att översätta det till “AI patchar åt oss”. Det är för grovt.

En bättre läsning är: AI kan flytta mycket arbete fram till ett bättre beslutsunderlag. Men patch-kön behöver fortfarande ägare, testbevis, riskbedömning, releasefönster och rollback.

Källa: OpenAI om Daybreak och OpenAI om Patch the Planet

Samma tillåtelsestege passar här: hitta → reproducera → föreslå patch → skapa PR → testa → be om godkännande → driftsätta. Hoppa inte från “fynd” till “produktion” bara för att agenten låter säker.

Så använder du tillåtelsestegen i ett riktigt workflow

Välj ett arbetsflöde där AI redan känns användbart, men där ni inte vill ge full handlingsfrihet. Exempel: inkommande offertmejl, elev-/kundfrågor, fakturaunderlag, supportärenden, portföljanalys eller en liten intern kodändring.

Skriv sedan ner fem saker:

• System och data: vad får agenten läsa, och vad får den aldrig se?
• Maxnivå: vilket steg på stegen är tillåtet i piloten?
• Ägare: vem får höja nivån, stoppa flödet eller godkänna en åtgärd?
• Kvitton: vilka källor, loggar, tester eller osäkerhetsvärden måste följa med?
• Rollback: hur backar ni om agenten föreslår eller gör fel?

Om ni inte kan svara på de fem punkterna är nästa steg inte mer automation. Nästa steg är att rita flödet.

En praktisk pilot: låt agenten stanna på utkastnivån

För många organisationer är en bra första nivå inte “AI gör jobbet”. Det är “AI gör ett granskningsbart utkast”. Agenten får läsa ett avgränsat underlag, sammanfatta, föreslå och skapa ett utkast. En människa tar beslutet.

Det låter långsamt. I praktiken är det ofta den snabbaste vägen till trygg automation, eftersom teamet lär sig var felen uppstår innan AI får skriva till system.

I Hammer Automations Verktygssmide går det här att göra konkret: ett flöde, en agentroll, en maxnivå, en logg och en godkännandepunkt. När det fungerar kan nästa steg läggas till med mindre gissning.