Der tegner sig et lidt ubekvemt billede af enterprise-markedets AI-sikkerhed. Virksomhederne er i gang med at sætte agenter tættere på rigtige systemer, rigtige data og rigtige handlinger, men sikkerheden halter efter på det sted, der faktisk gør ondt, når noget går galt. Ikke ved dashboards. Ved indgreb.
VentureBeat bygger den pointe på en survey i tre bølger blandt 108 kvalificerede virksomheder. Hovedfundet er enkelt nok: Den mest almindelige opsætning i produktion er et hul mellem at kunne overvåge, at kunne håndhæve regler og at kunne isolere agenten, hvis den først er sluppet for langt ind. Det lyder tørt. Det er det ikke.
For Gravitee ser man noget af det samme, bare målt fra en anden vinkel. Ifølge rapporten State of AI Agent Security 2026, som omfatter 919 ledere og praktikere, siger 82 procent af lederne, at deres politikker beskytter dem mod uautoriserede agenthandlinger. Samtidig rapporterer 88 procent AI-agentrelaterede sikkerhedshændelser inden for de seneste tolv måneder, og kun 21 procent har runtime-synlighed i, hvad agenterne faktisk foretager sig.
Tre trin og et ret konkret problem
VentureBeats model deler modenheden op i tre trin: observe, enforce og isolate. Første trin er at kunne se aktivitet, trafik og hændelser. Andet trin er at koble observation til handling, blandt andet via IAM-integration og kontroller på tværs af leverandører. Tredje trin er isolation, altså sandboxed eksekvering, der begrænser skadeomfanget, når guardrails ikke holder.
Det er lige præcis tredje trin, der gør historien interessant. Mange organisationer er efter alt at dømme kommet et stykke med logning og noget policyarbejde. Men hvis en agent har adgang til værktøjer, APIer eller interne systemer, er det ikke nok at opdage problemet bagefter. Så er spørgsmålet, om man kan afgrænse agentens miljø, stoppe rækkevidden og undgå, at en fejl bliver til en driftshændelse.
Det er også forskellen på klassisk LLM-brug og agentisk drift. En chatbot, der svarer forkert, er irriterende. En agent, der kalder et værktøj, henter data eller skriver i et system på forkert grundlag, er noget andet. Der bliver hurtigt meget lidt teoretisk over det.
Selvtillid er ikke det samme som kontrol
Gravitees tal er ikke et bevis på hele markedets tilstand alene, men de rammer et mønster, mange nok vil genkende. Høj tillid til egne politikker. Lav indsigt i runtime. Mange hændelser alligevel. Det lugter lidt af, at compliance-slides og faktisk driftskontrol bliver blandet sammen.
Gravitee formulerer selv problemet som et misforhold mellem voksende agent-adoption og sikkerhedsmodeller, der ikke er fulgt med, efterhånden som agenter flytter ind i produktionssystemer. Rapporten peger på huller i identitet, autorisation og runtime governance. Det matcher ikke VentureBeats model ord for ord, men overlapper nok til, at historien hænger sammen.
Og ja, det er værd at holde fast i, hvad 21 procent runtime-synlighed faktisk betyder i praksis. I mange virksomheder vil det være svært at dokumentere, hvad en agent gjorde, på hvilke data og med hvilke rettigheder, hvis noget går skævt. Det er ikke kun et sikkerhedsproblem. Det er også et revisionsproblem, og i nogle miljøer et ret dyrt et.
Når overvågning kommer for sent
Lad os skære det helt ind til benet. Hvis man kan se, at en agent trak følsomme filer, kaldte et værktøj eller bevægede sig på tværs af systemer, men først bagefter, så har man i bedste fald en rapport. Ikke kontrol. Hvis man derudover kan blokere noget i identitetslaget, men ikke isolere agenten, når den allerede er i gang, så er skaden stadig i spil.
Det er den slags forskel, der ofte bliver mudret i glatte leverandørbudskaber. Overvågning er nyttig. Håndhævelse er bedre. Men isolation er det lag, der afgør, om en fejl bliver lokal eller breder sig. Og det lag er efter VentureBeats beskrivelse ikke dér, hvor flertallet står i dag.
Vi ser lidt af det samme mønster, når virksomheder går fra pilot til drift. Først er agenten bare et smart lag oven på søgning eller support. Senere får den skriveadgang, trigger workflows eller kalder interne APIer. Det er dér sikkerhedsbilledet skifter, og mange opdager det først, når arkitekturen allerede er blevet rodet.
Budgetterne peger samme vej
Der er også et prioriteringsspor i materialet. VentureBeat gengiver tal fra Arkose Labs’ 2026 Agentic AI Security Report, hvor 97 procent af enterprise-sikkerhedsledere forventer en væsentlig AI-agentdrevet hændelse inden for tolv måneder. Alligevel adresserer kun 6 procent af sikkerhedsbudgetterne ifølge samme rapport AI-agentrisiko.
Det tal skal læses med korrekt etikette. Det stammer fra en leverandørdrevet rapport, gengivet af VentureBeat. Men som pejlemærke er det svært at overse. Der er åbenlyst et gab mellem det, man tror kommer, og det, man faktisk betaler for at håndtere.
VentureBeats egen survey peger samtidig på bevægelser i budgetterne. Investering i monitorering steg til 45 procent af sikkerhedsbudgetterne i marts efter at være faldet til 24 procent i februar. Samtidig skriver mediet, at nogle tidlige aktører i februar havde flyttet penge over i runtime enforcement og sandboxing. Den læsning er interessant, fordi den antyder et marked, der stadig famler lidt. Først synlighed. Så måske kontrol. Isolation til sidst, hvis man er nået dertil.
Her er der dog en vigtig metodisk kant. Marts-bølgen havde kun 20 respondenter og bliver beskrevet som retningsgivende. Februar havde 50. Så man skal ikke oversælge talserien. Men som signal om, hvor modenheden halter, er den svær at afvise helt.
Maskinhastighed gør efterkontrol tynd
VentureBeat trækker også CrowdStrike ind som bagtæppe. Falcon-sensorerne registrerer mere end 1.800 forskellige AI-applikationer på enterprise-endpoints, og den hurtigste registrerede breakout-tid for en angriber er faldet til 27 sekunder. Også her er tallet gengivet via VentureBeat, så det bør læses som kontekst, ikke som artiklens eneste søjle.
Men selve pointen holder. Hvis trusler og automatiserede handlinger bevæger sig i maskinhastighed, så bliver menneskelig efterkontrol hurtigt for langsom. Et dashboard er fint nok mandag morgen. Det hjælper mindre, hvis agenten allerede har fået lov at gøre noget dumt fredag klokken 02.13.
Det er måske også derfor observe ikke længere virker som et slutmål, kun som en begyndelse. Når agenter opfører sig mere som driftende softwarekomponenter end som passive assistenter, skal sikkerheden kunne reagere i samme tempo. Ellers bliver synlighed mest en pæn måde at være bagud på.
Det enterprise-teams bør læse ud af det
For en platformejer, en sikkerhedschef eller et driftsteam er den nyttige læsning ret jordnær. Hvis en agent må søge i dokumenter, kalde APIer, opdatere et system eller handle på egne tool-calls, så er det ikke nok at logge den. Man skal også vide, hvilke handlinger der kræver policy-tjek, hvor hændelser bliver bundet til identitet og rettigheder, og hvad der sker, hvis agenten skal bremses midt i et flow.
Det er også her governance bliver konkret i stedet for kedelig. Hvem ejer agentens handlinger? Hvilke miljøer må den overhovedet køre i? Hvor meget adgang får den som standard? Og kan man bagefter eftervise, hvad den gjorde. Hvis svaret er uklart, er modenheden som regel også det.
Så nej, historien handler ikke bare om endnu et sæt sikkerhedstal. Den handler om, at mange virksomheder stadig forveksler logning med kontrol. Det kan gå an i en pilot. Ikke i drift, når agenten har hænderne nede i rigtige systemer.
