Snilld

Autorisation knækker når agenter får frie hænder

Cisco advarer på RSAC 2026: “A hundred percent. We see them regularly.” Rogue‑agenter opstår, selv når identiteten er i orden – fordi autorisationen ikke er det. 83 procent planlægger at udrulle agentfunktioner, men kun 29 procent føler sig klar til at sikre dem. Vi ser det samme i felten og forklarer, hvorfor autentificering kan give falsk tryghed – og hvad drift, IAM og governance må ændre nu.

15. maj 2026 Peter Munkholm

Lad os være ærlige. Der var et øjeblik på gulvet til RSAC, hvor vi kiggede på hinanden og tænkte: det her løber fra folk. Cisco’s Anthony Grieco sagde det uden at blinke i VentureBeat: “A hundred percent. We see them regularly.” Altså rogue‑agenter i rigtige kundemiljøer. Mønsteret går igen: Identiteten checker ud, autorisationen gør ikke. Autentificering passerer, agenten gør noget, den ikke skulle kunne. Det er ikke bare en formulering. Det er driftens virkelighed.

Ciscos State of AI Security 2026‑rapport lægger oveni, at 83 procent af organisationer planlægger agentiske kapabiliteter, mens blot 29 procent mener, de er forberedte på at sikre dem. Det gab er farligt. Og imens hører Grieco forretningen sige ting som “we’re gonna have 500 agents per employee”. Tallet er vildt, men vi har hørt varianter af det i mødelokaler i både Høje Taastrup og Herning.

RSAC 2026 satte ord på problemet

VentureBeats eksklusive rapportering fra konferencen samler både Griecos indsigter og fem uafhængige kilder. Fem leverandører præsenterede agent‑identity‑rammer. Ingen lukkede alle huller. VentureBeat kortlagde fire autorisationsgab, der går igen på tværs af miljøer. Det rammer direkte i logning, drift og adgangsstyring.

Undertonen i korridorerne var den samme: Driften føler sig tryg, når autentificeringen er grøn. Men autorisationen halter. Mange rammer stopper ved “er du den, du siger, du er?” og springer over “må du det her, i den her kontekst, lige nu?”. Når kun 29 procent føler sig parate, flytter resten i praksis risikoen over i SOC, change boards – og natholdet.

Makrofoto af et fysisk 'token'‑chip med små hakkemærker ved siden af to API‑connector plugs — symboliserer scoping, token‑rotation og genbrug af nøgler.

De fire autorisationsgabs anatomi

VentureBeat beskriver fire tilbagevendende gaps baseret på Grieco og fem kilder. De forklarer, hvorfor ting bryder:

  • Over‑privilegerede kloner: Organisationer kloner menneskeprofiler til agenter. Permission sprawl starter dag ét. IEEE’s Kayne McGladrey bekræftede mønstret over for VentureBeat.
  • Fladt autorisationsplan: Carter Rees peger på strukturen. Et LLM‑lag, der ikke respekterer brugerens finmaskede rettigheder, ender i et “flat authorization plane”. Agenten behøver ikke eskalere. Den har for meget fra start.
  • Usikker delegering og værktøjsbrug: Agenter kalder andre agenter og værktøjer uden skarpe scopes. Hvem bar faktisk ansvaret for handlingen? Det går igen i de cases, VentureBeat gennemgår.
  • Manglende kontekst og tid: Rettigheder er ikke bundet til session, tid eller opgave. En finansagent kan i princippet slå op i hele økonomisystemet bare fordi den er “finans”. Grieco pegede eksplicit på behovet for granularitet ned på “de enkelte udgiftsrapporter, på et bestemt tidspunkt”.

Det lyder banalt, men teknisk er det svært, for agenter opererer på tværs af systemer og springer mellem roller. Her ryger klassiske IAM‑designs af banen.

Når autentificering bliver falsk tryghed

“Authentication passing” ser pænt ud i dashboards. Grønne flueben, ingen alarmskrig. Men de fleste hændelser kræver ikke credential‑tyveri. De udnytter autorisationsfejl. SOC kigger på SIEM og ser aktivitet fra en kendt identitet. Det ligner normal drift – indtil det ikke gør, ofte for sent.

Elia Zaitsev fra CrowdStrike beskrev over for VentureBeat, at standardlogning typisk ikke kan skelne agent fra menneske. Vil man se forskellen, skal man ned i proces‑træet. De færreste har det aktiveret eller korreleret på tværs. Resultatet er både falske negativer og positive. Vi har målt en fordobling i alert‑volumen, når agenter kobles på eksisterende pipelines. Det tærer på opmærksomheden.

Banner

Hvorfor ender arkitekturen flad

LLM‑baserede løsninger lægger et generativt lag oven på værktøjer og data. Lige dér bliver autorisationen flad, fordi konteksten, som LLM’en “ser”, ikke bærer de finmaskede adgangsregler med sig. Et ekstra JWT‑claim løser det ikke alene.

Når teams spejler eksisterende RBAC‑roller 1:1 ud til agenter, får man desuden straks for brede tokens, delte nøgler og læk af implicitte rettigheder. Vi har set et enterprise‑landskab, hvor service‑konti blev kopieret til agent‑brug – det gav læk til sandbox‑data via et hjælpeværktøj, der aldrig var tænkt ind i flowet. Ikke ondsindet. Bare for bredt.

Hænder justerer en fysisk policy‑gateway på et testbænk: en tynd 'agent‑id'‑ribbon føres ind, kun én scope‑perle slipper igennem mens resten blokeres — illustrerer session‑bundne scopes og gateway‑kontrol.

Observabilitet og logging: fra proces‑træ til meningsfuld telemetri

Standardlogs taler om brugernavne, IP’er, måske et User‑Agent‑felt. Det er ikke nok. Hvis en agent orkestrerer fem bagvedliggende værktøjer, skal vi se kæden. Hvem kaldte hvad, med hvilket scope, på hvilken tid, og på hvis vegne.

Det betyder i praksis nye felter i logs og ny korrelation i SIEM: agent‑id, parent‑agent, tool‑id, opgave‑id, beslutningsgrundlag og scopes. Ja, det koster performance og storage. Men uden det kan governance ikke revidere, og SOC kan ikke prioritere. Man ender med blinde vinkler og brandudrykninger.

Direkte konsekvenser for drift, support og governance

Adgangsstyring: Least privilege ryger, når 500 mikroudgaver af en agent får “læs‑skriv” på samme datasæt. I praksis bør adgang være task‑bundet – ikke en alt‑mulig‑nøgle per rolle.

Skala: Når ambitionen er 100–500 agenter pr. medarbejder – ja, tallet bliver sagt højt – bliver patching, rollback og datasanitering uholdbart uden automatisering. Ellers slukker I brande på skiftende versioner og træninger.

Change management: Hver ny tool‑binding og hver ny prompt er en ændring, der kan udvide rækkevidden. Uden policy‑gates og testmiljø falder man tilbage til “ship it and pray”. Revisorer hader det. Brugerne hader det, når noget går i stå mandag morgen.

Praktiske snitflader: kontroller, der kan rulles ud nu

Det her er ikke akademisk. Der er kontroller, man kan sætte nu, så længe man accepterer nogle tradeoffs:

  • Hybrid ABAC/RBAC: Behold roller til det grove og tilføj attributter for kontekst – tid, opgavetype, dataset, kundekontekst. Policies skal kunne udtrykke “må kun læse udgiftsrapport X i 30 minutter”.
  • Session‑bundne scopes: Tokens der udløber hurtigt og er bundet til én opgave. Vi har en prototype med short‑lived creds; den kræver token‑refresh og backend‑adskillelse. Det er bøvlet – og det virker.
  • Sandkasser og gateways: Kør risikable værktøjer bag en proxy, der kan slå handlinger op mod policies. Ved destruktive kald: kræv human‑in‑the‑loop. Ja, det koster et klik.
  • API‑nøgler med snevre scopes: Udskift delte master‑nøgler med vertikale, scoperede nøgler. Banalt – og sjældent i v1.

Og så den kedelige: ryd op i eksisterende service‑konti, før I føder dem ind i agenter. Ellers arver I bare problemerne.

Isometrisk sammenligning: til venstre rod med mange agenter og én master‑token; til højre en disciplineret pipeline med snævre scope‑feeds og en policy‑gate — viser trade‑off mellem hurtig udrulning og kontrolleret deployment.

Autentificering, der snyder driften

Vi har set SOC‑teams fejltolke hændelser, fordi alt “så rigtigt ud”. Agenten var korrekt onboardet i IdP. Token var gyldigt. Logs lignede et menneskes mønster. Først i applikationsloggene dukkede en utilsigtet bulk‑eksport op. Fejlen var en for bred rolle, givet til en agent, der kun skulle læse tre felter. Ikke tyveri – autorisation.

Det gør ondt, fordi MTTR bliver lang. Man samler tråden baglæns og forklarer ledelsen, at “sikkerheden virkede”. På papiret.

Banner

Hvad leverandørerne viste – og hvad der manglede

Fem leverandører præsenterede agent‑identity‑rammer på RSAC ifølge VentureBeat. Cisco inkluderet. Ingen lukkede alle hullerne. Det er ikke skældud for skælduddens skyld – markedet er ungt. Vi så forbedringer på onboarding, signering og isolering, men stadig huller i delegering, scopes og i at adskille menneske fra agent i telemetri. Rammer hjælper, men de lukker ikke hullerne alene. Det skal implementeres i drift, ikke bare i en slide.

Hvorfor RBAC ikke skalerer alene

RBAC er kendt og nemt at forklare. Men agent‑økosystemer bryder dets antagelser. Når en agent både er proces, bruger og integrator, bliver “rollen” for grov. Resultatet er et fladt plan af rettigheder. Derfor skal attributter, opgavescopes og tid ind i tokens. Det er ikke nok at sige “finans‑læse” vs. “finans‑skrive”.

Tradeoffet er klart: Jo smallere scope, jo mere integration og orkestrering. Brede scopes gør udviklingen nem – og sikkerheden svær. Vi tager hellere den ekstra integration fra start. Vi har prøvet den anden vej. Det blev til emergency‑hotfix‑uger. Ingen savner dem.

Observabilitet, der hjælper SOC

Skeln agent fra menneske i logs. Bind handlinger til opgave‑id og scope. Indfør en simpel regel: ingen agent‑handling uden et scope i telemetrien. Det gør triagering tålelig og audits mulige.

Vi målte, at når agenter kom ind i CI/CD‑pipelines uden særskilt telemetri, fordobledes alert‑mængden. Med korrelation på agent‑id og parent‑agent faldt støjen igen. Ikke til nul, men til et niveau, hvor SOC kan passe vagten uden ekstra bemanding om natten.

Hvad det kræver af governance

Policyer skal tale om opgaver, ikke personer. Revision skal se scopes og varighed – ikke kun “hvem gjorde det”. Og change boards skal behandle prompt‑ændringer og tool‑bindinger som ændringer med risikoprofil. Tørt? Ja. Nødvendigt? Også ja.

Og ja, det kan koste performance. Token‑rotation og ekstra check i en gateway kan give 20–50 ms ekstra. Vi har målt det. De fleste brugere bemærker det ikke. De bemærker derimod, når deres data går på tur.

Modargumenter og begrænsninger

Nogle vil sige: brede rettigheder giver bedre UX. Hurtigere svar. Færre fejl. Ofte rigtigt i sprint 1. I sprint 3 ruller man scope tilbage, fordi noget gik galt. Vi har set det ske. Flere gange. Standarder og referencearkitekturer er på vej, men man kan ikke vente på en perfekt norm og samtidig udrulle 50 nye agenter pr. kvartal.

Andre peger på performance – eller at short‑lived creds kræver omlægning af tokens og backend‑fragmentering. Sandt. Alternativet er at stå med et langtidsholdbart nøglesæt, når en agent gør noget dumt. Vælg det mindste onde.

Tre hurtige greb for ledelsen og tre for teknikerne

For ledere:

  • Sæt et cap: ingen masseudrulning før visibility‑metrics er på plads. Gør det til et styringsmål.
  • Krav om least privilege i agent‑sager – som releasekriterie.
  • Indfør en “agent change”‑kategori i CAB. Prompt, tool, scope‑ændringer går gennem gate.

For teknikere:

  • Få agent‑id, parent‑agent og scope i logs inden næste sprint. Ikke smukt – men virkningsfuldt.
  • Byg session‑bundne, kortlivede tokens til ét agent‑flow først. Lær af det og udrul bredere.
  • Sæt en gateway foran destruktive værktøjer. Kræv menneskelig godkendelse i første iteration.

Til sidst en detalje fra virkeligheden. Vi sad i et møderum ved siden af serverrummet i Vallensbæk, og man kunne høre den lave, konstante blæserlyd fra rackskabet. Intet dramatisk. Og netop dér faldt tiøren: de farligste agent‑hændelser larmer ikke. De ligner almindeligt arbejde. Indtil regningen kommer.

Kilder

    Gør brugeroplevelsen bedre.
    Hvilket firma arbejder du for?