--- title: "En identitet för människor och agenter: vem som får göra vad" url: "https://hurukan.com/sv/blog/en-identitet-for-manniskor-och-agenter" description: "Ett delat servicekonto gör varje handling från en agent anonym. Varför en agent behöver en egen identitet, delegerad från en människa, med behörigheter som löper ut." --- # En identitet för människor och agenter: vem som får göra vad 22 oktober 2026·4 min läsning·Redaktionen En rad identiska vita passerkort på ett skrivbord i ett rent kontor, ett av dem upplyst av en tunn blå linje längs kanten, en administratörs hand som sträcker sig efter det, en bärbar dator i bakgrunden som visar en abstrakt blågrå lista, kort skärpedjup En leverantörs bankkonto ändras i grunddata en torsdagseftermiddag. Betalningskörningen på fredagen använder det nya kontot. Tisdagen därpå ringer leverantören och undrar var pengarna är, och ekonomiteamet öppnar revisionsloggen för att se vem som gjorde ändringen. Loggen säger: INTEGRATION\_SVC. Det kontot tillhör mellanvaran. Genom det går webbshopssynkroniseringen, lagerkopplingen, ett schemalagt städskript och, sedan i våras, två agenter som uppdaterar grunddata när ett bekräftat dokument säger att de ska. Sex processer, ett namn, ett lösenord som lagras på tre ställen. Ändringen gjordes av en av dem, för någons räkning, av ett skäl, och posten kan inte säga vilken, för vem eller varför. Det här är inget säkerhetsintrång. Varje process gjorde det den var konfigurerad att göra. Det är ett identitetsproblem: företaget gav sin programvara ett gemensamt ansikte, och ett gemensamt ansikte går inte att ställa frågor till. I samma stund som agenter börjar agera mångfaldigas antalet handlingar som det ansiktet utför, och var och en av dem är anonym per konstruktion. ## Vad ett delat servicekonto döljer **Aktören.** Sex processer bakom ett namn betyder att loggen registrerar att något hände och inte vad som gjorde det. En människas misstag, ett skripts bugg och en agents felbedömning ser likadana ut och rättas på samma sätt: långsamt. **Uppdragsgivaren.** En agent som uppdaterar en leverantör gör det för att en människas roll bad om det eller för att en process tillät det. Servicekontot bär inget spår av den kedjan, så frågan “för vem gjordes det här” har inte heller något svar. **Omfattningen.** Ett servicekonto samlar på sig rättigheter. Varje integration behövde en tabell till, en ändpunkt till, och ingen tog bort dem som inte längre används. Agenten som lades till i fjol ärvde alla, inklusive rätten att ändra ett bankkonto den aldrig behövde. **Tiden.** Kontot har varit giltigt sedan det skapades. En människas åtkomst upphör när hon slutar; en delegerad uppgift upphör när den är klar. Det delade kontot upphör aldrig, så en inloggningsuppgift som läckt en gång har läckt för gott. **Gränsen mellan att läsa och att skriva.** Kontot som läser order för en rapport är samma konto som skriver en betalfil. Ett komprometterat skript, en felkonfigurerad prompt, och läsvägen blir en skrivväg. Varför skrivningen är den farliga halvan utvecklas i [en agent som skriver till ERP](https://hurukan.com/sv/blog/en-agent-som-skriver-till-erp). **Behörigheter knutna till tabeller.** Databasroller ger åtkomst till en tabell, inte till en kund. En agent som får läsa ordertabellen läser varje order, även de som tillhör den kundgrupp dess roll aldrig borde se. Skärmbilden brukade dölja dem; agenten använder inte skärmbilden. ## Hur en agents identitet måste se ut **Ett eget namn.** Varje agent är en principal i katalogen, som en människa och till skillnad från ett lösenord i en konfigurationsfil. Loggen namnger då agenten, och en ifrågasatt ändring kan spåras till en process i stället för till en pool av sex. **Delegerad från en människa eller en roll.** En agent har inga egna rättigheter; den agerar för någon. Inköpsagenten agerar under inköpsrollen, inom det den rollen får göra, och posten visar agenten och rollen tillsammans. Om människan bakom rollen slutar upphör delegeringen med henne. **Omfattningar som löper ut.** En delegering gäller en uppgift, ett område och en period. Att läsa öppna fakturor de närmaste trettio dagarna är en omfattning; att läsa allt för alltid är ett servicekonto under annat namn. När omfattningen löper ut frågar agenten igen, och frågan registreras. **Behörigheter på affärsobjekt, inte tabeller.** Det är här ontologin förtjänar sin plats. Modellen definierar en kund, en order, en leverantör, ett bankkonto och de åtgärder som finns på var och en: läsa, föreslå, ändra, godkänna. En behörighet säger då att serviceagenten får läsa reklamationer för kunderna i en region och föreslå svar, inte att den får göra select från tre tabeller. Samma regel gäller människor, så en människa och en agent i samma roll ser exakt samma saker. **Upprätthållen på servern, läsbar för alla.** Behörigheten ligger under agenten, i lagret som kontrollerar varje begäran, inte i agentens instruktioner. En prompt kan inte ge sig själv åtkomst, och en människa som läser modellen ser vad varje agent får göra utan att läsa någon kod. **Samma svar för en människa och en agent.** “Vem gjorde det här, för vem, på vilket underlag, och vem godkände det” besvaras på samma sätt oavsett om aktören var en handläggare eller en process. Om posten kan svara för personal men inte för agenter är agenterna ett hål i revisionen, inte en del av den. ## Ett test du kan göra i dag Öppna revisionsloggen i ert ERP- eller ekonomisystem och filtrera den senaste månaden på de tekniska kontona: integrationsanvändaren, API-användaren, allt med “svc”, “sync” eller “system” i namnet. Räkna ändringarna. Ta sedan fem av dem på måfå och försök svara, för var och en, vilken process som gjorde ändringen och vilken människa eller roll den gjordes för. Om ni inte kan svara inom några minuter utifrån posten ensam, utan att fråga IT-teamet, är var och en av de ändringarna anonym. Lista nu de processer som delar varje tekniskt konto och de rättigheter kontot har. Skillnaden mellan vad varje process behöver och vad kontot har är den angreppsyta ni har kört med hela tiden, och det är den yta en agent skulle ärva från dag ett. I Hurukan når varje begäran servern med en identitet: en människa, en agent som agerar för en människa eller en process, eller systemet självt. Behörigheter kontrolleras där, på servern, mot de roller och regler som [ontologin](https://hurukan.com/sv/system/ontologi) definierar på affärsobjekt, och varje ändring registreras med sin upphovstyp, vad som ändrades och på vems godkännande. Det är det som gör en agent ansvarig i samma mening som en medarbetare, och det är grundlagret i [Hurukan](https://hurukan.com/sv), beskrivet i [suveränitet är ett arkitekturbeslut](https://hurukan.com/sv/blog/suveranitet-ar-ett-arkitekturbeslut). - identitet - behörigheter - agenter - revisionsspår - ontologi ## Läs vidare - [Det levande tillståndet och registret: två minnen i ett operativsystem för företaget](https://hurukan.com/sv/blog/det-levande-tillstandet-och-registret-tva-minnen) - [En agent som skriver till ERP: gränsen mellan att läsa och skriva](https://hurukan.com/sv/blog/en-agent-som-skriver-till-erp)