Agentic ransomware er ikke en ny risiko. Det er en hurtigere risiko.

Jeg synes ikke, at “AI-drevne angreb” er skræmmende, fordi de er intelligente. Jeg synes, de er skræmmende, fordi de er hurtige.

Hastighed ændrer alt. I en menneskestyret hændelse får forsvarerne minutter, nogle gange timer, med friktion. I en automatiseret hændelse kan angriberen scanne, privilege-hoppe, stage payloads og eksekvere i ét sammenhængende run. Din organisation fejler ikke, fordi I mangler en smart detection rule. I fejler, fordi jeres kontroller er designet til en verden, hvor mennesker var nødt til at stoppe op.

I industrielle miljøer lærte vi den lektie for længe siden. Vi stolede aldrig på “smart” adfærd uden governance-primitiver, man kan pege på, teste og auditere. Constraints skaber driftssikkerhed. Recoverability skaber tryghed. Håb er ikke en kontrol.

Dette essay er mit operatørblik på agentic ransomware: behandl det som hurtigere automation, og svar igen med kontroller på automationsniveau.

Tidskomprimering er threat model

De fleste cyberprogrammer antager stadig en tidslinje med menneskelige “sømme”: en angriber skal researche, bygge og iterere. Den antagelse siver ind i governance. Godkendelser er langsomme. Privilegier hober sig op. Logs kan ændres. Backups er “et sted”. Incident response er en PDF.

Når angrebskæden er automatiseret end-to-end, forsvinder de sømme. Angriberens loop bliver: discover, exploit, propagate, encrypt, extort — som én maskinproces. I får ikke lov til at “opdage det” halvvejs, hvis jeres miljø tillader lateral movement og privilege escalation i maskinhastighed.

Derfor er det første mentale skift for bestyrelser og operatører enkelt: mål jeres eksponering i minutter, ikke i dage. Hvis jeres antagelser om containment og recovery kræver timer, planlægger I for en anden type modstander.

Industriel automation fik én ting rigtigt: constraints slår cleverness

Da jeg brugte år i effektelektronik og industriel automation, leverede vi systemer, der skulle køre videre i vand- og spildevandsanlæg, HVAC-infrastruktur og produktionsmiljøer. I de verdener diskuterede vi ikke, om en controller var “smart”. Vi diskuterede, om den var bounded.

Bounded systemer opfører sig forudsigeligt under pres. De fejler på kendte måder. De viser tydelig state. De har isolationsgrænser. De giver operatøren et stop og en vej til genstart.

Senere, da jeg stod i spidsen for en international forretningsenhed inden for smart-building og connected controls, gjaldt samme logik. Embedded devices, gateways, cloud services, installatører og facility operators dannede et rodet socio-teknisk system. Driftssikkerhed kom aldrig af at tilføje mere automation. Den kom af at sætte hegn omkring automation.

Agentic angribere udnytter det modsatte: unbounded automation i jeres eget miljø. Overprivilegerede identiteter. Flade netværk. Scripts, der kan køre overalt. Logs, der kan manipuleres fra samme admin plane, som de er sat til at auditere.

Hvis du vil have et tidløst princip: gør virksomheden sikker at automatisere. Det betyder, at du designer constraints, så enhver hurtig aktør — ondsindet eller buggy — rammer hårde grænser hurtigt.

De kontrol-primitiver der betyder noget (og hvordan du pressure-tester dem)

Jeg kan godt lide at reducere “agentic security” til tre spørgsmål, en operatør kan svare på uden slides:

1. Hvilke værktøjer kan køre?
2. Hvor kan de køre?
3. Hvordan stopper vi og kommer os?

1) Definér toolchain: least privilege for automation — ikke for mennesker

De fleste organisationer arbejder med least privilege som en HR-øvelse. Joiner, mover, leaver. Det er nødvendigt, men det rammer ikke det moderne problem: automation identities.

Jeres mest risikable credentials er ofte non-human: CI/CD runners, RPA bots, integration keys, device provisioning tokens, service accounts og “midlertidig” admin-adgang givet til scripts.

• Lav et inventory over automation identities og behandl dem som produktionsaktiver.
• Afgræns deres rettigheder til enkeltjobs. Hvis en build runner også kan nå production secrets, har I bygget en angrebsbro.
• Rotér og udløb credentials som standard. Langlivede tokens er hændelser i slowmotion.
• Krav om signeret eksekvering for privilegerede scripts og binære filer. Hvis det ikke kan verificeres, kan det ikke køre.

Det er også her, anvendt AI kan hjælpe defensivt: ikke ved at “detektere hackere”, men ved løbende at afstemme, hvad identiteter bør gøre, versus hvad de faktisk gør. Men det virker kun, hvis den underliggende permissions-model er ren.

2) Segmentér som om du mener det: reducér blast radius til noget, du kan leve med

I produktion er segmentering ikke en “best practice”. Det er sådan, du sikrer, at en fejl i én celle ikke stopper hele fabrikken. Cyber er det samme. Hvis jeres netværk er fladt, er jeres incident globalt pr. design.

• Segmentér efter funktion og kritikalitet: bruger-endpoints, build-systemer, business apps, operationelle systemer, backups, logging og identitetsinfrastruktur.
• Default-deny east-west movement. Tillad kun de specifikke flows, I kan forklare på én side.
• Adskil jeres “keys to the kingdom”: identity provider admin, backup admin, logging admin og production admin bør ikke være samme plane.
• Design til containment: antag, at ét segment bliver kompromitteret. Jeres opgave er at forhindre, at det bliver to.

Hvis du arbejder med IoT eller smart-building, så husk: valg om connectivity bliver til valg om trust. I det øjeblik du behandler connectivity som “bare data”, overser du det control plane, du eksponerer. Jeg har skrevet om den tankegang i eSIM som trust anchor, fordi den kommercielle model ofte glemmer at budgettere for sikkerhedsmodellen.

3) Gør logs og backups modstandsdygtige mod en modstander: immutable, off-path, auditeret

Automatiserede angribere krypterer ikke kun data. De går efter jeres evne til at forstå, hvad der skete — og jeres evne til at genskabe drift. Derfor er “vi har backups” ikke en sætning. Det er et system.

• Skriv logs til et immutable store, som production admins ikke kan ændre.
• Hold backups væk fra det primære identity plane. Hvis samme SSO-kompromis også giver sletning af backups, har I ingen backups.
• Test restores fast. Restore-tid er en KPI, ikke en beroligende antagelse.
• Følg jeres recovery point objective som en finansiel eksponering. Hvor meget data har I råd til at miste?

Det er forskellen på at blive hacket og at være ude af drift.

Øv kill switch som et nødstop

I industriel drift øver vi nødstop, fordi det øjeblik, du har brug for dem, er det værste tidspunkt at opdage uklarheder. Det samme bør gælde for cyberhændelser drevet af automation.

Jeg taler ikke om et war room. Jeg taler om en praktisk kill-switch playbook:

• Decision rights på én side: hvem kan isolere netværk, disable SSO, fryse deployments og lukke integrationer.
• Foruddefinerede isolation actions: quarantine et segment, disable non-human tokens, stop build runners, revoke privilegerede sessions.
• Indøvet kommunikation: internt, til kunder og til leverandører. Stilhed skaber kaos.
• Clean-room recovery: et kendt-godt miljø og en procedure til at genopbygge kritiske services uden at stole på det kompromitterede plane.

Når jeg bygger og driver mine egne ventures som Shopeno og IBHQ, behandler jeg “stop og recover” som et produktkrav — ikke som en IT-opgave. Små teams overlever ikke ved at være heldige. De overlever ved at kunne komme sig. Den samme disciplin skalerer op: jo større organisationen er, desto mere har du brug for øvelser, fordi koordinering bliver flaskehalsen.

Hvis du vil have en dybere version af denne operatørvinkel, har jeg udfoldet pointen i AI value og stop-knappen. Kontrollen er værdien.

Et bestyrelsesperspektiv: kontroller der virker, når angriberen er hurtigere end jer

Hvis du sidder i en bestyrelse eller leder en forretningsenhed, behøver du ikke blive security architect. Du skal insistere på det rigtige evidensgrundlag.

Her er de spørgsmål, jeg ville stille i en kvartalsvis review — og jeg ville ikke acceptere vage svar:

• Blast radius: Hvis én endpoint kompromitteres, hvad er den maksimale skade, før vi kan contain’e?
• Automation identities: Hvor mange non-human credentials findes der, hvor ligger de, og hvilke af dem kan røre production?
• Bevis for segmentering: Vis mig de ti vigtigste tilladte east-west flows, og hvem der har godkendt dem.
• Immutability: Hvilke logs og backups er reelt immutable, og hvem kan slette dem?
• Restore drills: Hvornår var sidste succesfulde restore-test af et kritisk system, og hvor lang tid tog det end-to-end?
• Kill-switch drill: Hvornår øvede vi sidst at disable SSO eller isolere et segment — og hvad brød sammen?

Det her er operationel governance. Det er den samme muskel, du bruger til at styre kvalitet, sikkerhed og oppetid. Hvis du kan lide produktionsrammen, vil du også genkende mønsteret i ruggedization som en driftssikkerhedskontrakt. Sikkerhed er også en kontrakt. Du betaler for den, og du håndhæver den.

Min holdning: behandl autonomi som et privilegie, du gør dig fortjent til

Agentic ransomware er en forcing function. Det kræver ikke en ny filosofi. Det kræver operationel alvor.

Autonomi — både i jeres egne AI agents og i en angribers automation — er kun sikker, når den er bounded af hårde kontroller: least-privilege toolchains, reel segmentering, immutable evidens og indøvede stop. De organisationer, der vinder, er ikke dem med de pæneste dashboards. Det er dem, der kan contain’e hurtigt, beslutte hurtigt og recover’e hurtigt.

Det er den samme lektie, jeg har taget med fra factory-adjacent systemer, embedded devices og drift på tværs af lande: constraints skaber driftssikkerhed, og recoverability skaber hastighed. Alt andet er teater.