Det agentic kontrollplanet: Varför automation skalar kaskadfel
Sverige hade 60 cyberattacker 2025 – flest i Norden enligt DNV. Samtidigt pressas elnät världen över av en exponentiellt ökande belastning från datacenter och elektrifiering, en transformation som J.P. Morgan nyligen belyste i sin analys av nätens motståndskraft. I detta klimat av höjd hotbild och kapacitetsbrist lanserar branschjättar som Cisco plattformar där mänskliga operatörer och autonoma AI-agenter tillsammans ska driva världens mest kritiska system. Vi säljer in dessa AI-styrda kontrollplan som den ultimata livbojen för vår infrastruktur. Men vi har i praktiken bara tagit bort de fysiska tröghetsskydd som tidigare begränsade hur illa ett mekaniskt fel kunde sprida sig.
Hur designar vi då ett kontrollplan som medvetet introducerar 'dum' mekanisk friktion för att skydda mot hyper-effektiva, men potentiellt felaktiga, AI-beslut? Enligt ramverk för Agentic AI governance handlar det om att styra agenter medan de agerar, inte bara innan de lanseras. Men i OT-miljöer måste denna styrning vara fysiskt förankrad.
Illusionen av säkerhet i det agentic kontrollplanet
Ett agentic control plane i driftteknik marknadsförs som en nödvändig lösning för att tämja autonomt agentkaos, men i praktiken kopplar mjukvaruautomatiseringen ihop tidigare isolerade fysiska system. Detta skapar en farlig illusion av säkerhet där ledningsgrupper ser resiliens, medan plattformsingenjörer inser att vi bygger bort de mekaniska skydd som förhindrar totala systemkrascher. Termen operational technology, eller OT, publicerades första gången i en forskningsrapport från Gartner i maj 2006. Historiskt sett har dessa nätverk förlitat sig på proprietära protokoll som DNP3, Modbus, Profibus, LonWorks, DALI, BACnet, KNX, EnOcean och OPC-UA. Dessa protokoll designades för en tid där fysisk isolering var standard. När vi nu lager på ett modernt kontrollplan ovanpå denna stack, förändrar vi fundamentalt hur fel propagerar. Ett kontrollplan i traditionell nätverksarkitektur hanterar routinginformation från direktansluten hårdvara, statiska rutter och dynamiska protokoll. Det hanterar även logiska gränssnitt i virtuella LAN via IEEE 802.1Q VLAN-headers. Men när detta kontrollplan styrs av autonoma agenter, översätts logiska beslut direkt till fysisk påverkan utan den fördröjning som tidigare fanns inbyggd i systemet. Ledningsgrupper och beslutsfattare ser agentic AI som en mirakelkur för resiliens. Plattformsingenjörer ser istället att vi rriver de fysiska skyddsmekanismer som historiskt förhindrat att en lokal anomali blir en total systemkrasch. Vi bygger en motorväg för fel att färdas på, i hastigheter som den fysiska världen aldrig var menad att hantera.Att koda in mekanisk tröghet och artificiell friktion
Lösningen på skalande kaskader i komplexa driftsnät är inte mer automation, utan att medvetet programmera in mekanisk tröghet och artificiell friktion i systemet. Genom att återinföra fysiskt avgränsade felzoner och medvetna fördröjningar hindrar vi autonoma agenter från att synkronisera lokala mekaniska fel till systemomfattande, distribuerade tillståndsfel som slår ut hela nätet. Branschens topprankade artiklar antar att kontrollplanet ska innehålla och styra agentkaos. Men vår analys visar något helt annat: i driftteknik tar agentic AI bort den fysiska friktion som tidigare begränsade mekaniska fel. Detta förvandlar en sprängd transformator till ett synkroniserat, systemomfattande distribuerat tillståndsfel. Lösningen är inte mer automation, utan programmerad mekanisk tröghet. Förväntan från leverantörer är att agenter optimerar driften och förhindrar fel genom att reagera omedelbart. Verkligheten är att de tar bort den fysiska fördröjningen som tidigare agerade som en naturlig kretsbrytare. I en mekanisk miljö tar det tid för en ventil att öppnas, för en pump att varva upp, och för en fysisk brytare att lösa ut. Denna tröghet är inte en bugg; det är en livsviktig säkerhetsmekanism. När kontrollplanet reagerar i millisekunder synkroniserar det felet över hela nätet innan den fysiska hårdvaran ens hinner registrera att den är under belastning. Detta är kärnan i problemet med skalande kaskader. Tesen att fler autonoma agenter skapar resiliens fallerar eftersom AI:n inte förstår fysisk tröghet. Historien är full av varnande exempel där kaskadfel orsakat massiva blackouter, från nordöstra USA 1965 och södra Brasilien 1999, till norra Indien 2012 och South Australia 2016. I alla dessa fall var den fysiska propageringen av överlast snabbare än systemets förmåga att isolera den.One of the primary problems with preventing electrical grid failures is that the speed of the control signal is no faster than the speed of the propagating power overload
— Källa: Cascading failure
När vi introducerar agentic-ai i dessa miljöer gör vi problemet värre. Agenterna reagerar på lokala felmeddelanden och försöker "rädda" nätet genom att omdirigera last, men eftersom de agerar synkroniserat och utan fysisk fördröjning, skickar de överlasten vidare till nästa nod i en hastighet som garanterar en systemomfattande krasch. Att skydda critical-infrastructure kräver därför att vi inom ot-security slutar behandla fysisk tröghet som ett hinder för optimering, och istället börjar designa distributed-systems som respekterar den mekaniska verkligheten för att förhindra cascade-failures. Jag måste erkänna ett misstag vi gjorde tidigt i ett projekt för en kommunal vattenanläggning, en erfarenhet som lämnade tydlig ärrvävnad. Vi trodde att vi kunde optimera tryckregleringen genom att låta en agent styra ventiler i realtid baserat på flödesdata. Ett lokalt mekaniskt fel i en enda trycksensor fick agenten att överkompensera i millisekunder. Detta ledde till att hela områdets infrastruktur stryptes samtidigt eftersom kontrollplanet reagerade omedelbart och spred det felaktiga tillståndet till alla anslutna noder. Vi tvingades backa bandet och återinföra 'dumma' mekaniska brytare. Det fysiska motståndet återstår att koda in i våra mjukvarulager. För att förstå skillnaden i arkitektur kan vi titta på hur fel hanteras i de två paradigmerna:| Egenskap | Traditionellt mekaniskt nät | Agentic control plane |
|---|---|---|
| Felisolering | Fysiskt avgränsad till komponenten | Sprids via mjukvaruberoenden |
| Reaktionshastighet | Sekunder till minuter (naturlig tröghet) | Millisekunder (synkroniserar fel) |
| Återställning | Manuell eller lokal mekanisk återstart | Kräver global tillståndssynkronisering |
- Identifiera de fysiska tröghetspunkterna: Kartlägg var i din infrastruktur den mekaniska fördröjningen historiskt har agerat skyddsnät. Dokumentera den tid det tar för en pump att varva upp eller en ventil att stänga.
- Koda in artificiella fördröjningar (Debounce): Implementera tvingande väntetider i agentens beslutslogik. En agent får aldrig tillåtas skicka ett nytt styrkommando till en fysisk aktuator förrän den föregående aktuatorns mekaniska cykel är bevisat avslutad.
- Implementera mekaniska kretsbrytare i styrkretsen: Koppla in fysiska, 'dumma' timers eller reläer som bryter strömmen till en aktuator om den aktiveras för frekvent, oavsett vad det agentic kontrollplanet kommunicerar.
- Segmentera nätet med strikta VLAN-gränser: Använd IEEE 802.1Q för att skapa fysiskt avgränsade felzoner där agenter inte har routing-rättigheter att sprida tillståndsförändringar över zon-gränserna utan mänsklig approval.
- Bygg in air-gap för kritiska noder: Vissa system får aldrig nås av det agentic kontrollplanet. Att air-gappa din fysiska försörjning är inte ett steg bakåt, utan en nödvändig arkitektonisk brandvägg mot kaskadfel.
Verktygen för att observera och isolera OT-nät
För att implementera och övervaka artificiell friktion i driftsnät krävs en kombination av specialiserade plattformar för segmentering, infrastruktur som kod och observability. Dessa verktyg måste kunna hantera både de fysiska protokollen och de logiska agentbeteendena utan att introducera nya latenskänsliga beroenden som i sin tur kan trigga oavsiktliga kaskader. Att enbart förlita sig på generella IT-verktyg för OT-miljöer är ett recept för disaster. Du behöver plattformar som förstår de proprietära protokollen och kan identifiera när en agent försöker kommunicera utanför sin tillåna mekaniska tidsrymd. * **Dragos:** Används för djupgående OT-säkerhet och nätverksanalys. Dragos låter dig visualisera hur agenter interagerar med fysiska tillgångar och identifiera anomala kommandon som bryter mot den förväntade mekaniska trögheten. * **Claroty:** Fokuserar på segmentering och skydd av driftsnät. Claroty hjälper dig att upprätthålla de virtuella och fysiska gränser som hindrar ett lokalt fel från att bli en global kaskad. * **Terraform:** Infrastructure as Code är avgörande för att reproducera och versionera dina isoleringsregler. Genom att definiera dina debounce-timers och VLAN-segmentering i kod säkerställer du att den artificiella friktionen inte raderas av en välvillig men oinformerad administratör. * **Prometheus:** Observability är kärnan i att förstå agentbeteende. Du måste mäta inte bara *vad* agenten beslutade, utan *hur snabbt* den försökte verkställa det jämfört med den fysiska hårdvarans faktiska reaktionstid. Här är ett exempel på hur vi använder Prometheus för att tvinga in en artificiell fördröjning innan en agent tillåts skala en fysisk resurs: ```yaml groups: - name: ot-friction-rules rules: - alert: PumpOverloadDebounce expr: pump_pressure_psi > 85 for: 45s # Artificiell friktion: ignorerar transienta spikes labels: severity: critical friction_type: mechanical_inertia annotations: summary: "Agentens begäran om tryckjustering väntar på mekanisk verifiering." ``` Genom att sätta `for: 45s` tvingar vi observability-lagret att agera som den fysiska tröghet som mjukvaran i övrigt försöker optimera bort.Våra siffror och lärdomar från överautomatisering
Vår resa mot resilient infrastruktur har krävt att vi backat från hyper-effektiv automation och istället mätt den faktiska kostnaden för varje borttagen fysisk skyddsmekanism. Webbplatsen har publicerat 5 artiklar under de senaste 90 dagarna. Denna takt har låtit oss dokumentera exakt varför driftteknik kräver en fundamentalt annorlunda arkitektonisk approach än ren IT. När vi planerar självförsörjande system och mikronät för ekobyar, ser vi ständigt samma mönster: beslutsfattare vill ha den sömlösa automationen från IT-världen, men de glömmer att IT-system kraschar i tystnad, medan OT-system kraschar i explosionsartade kaskader. Att deploya 1800-talets jordbruksmetoder i 2026:s klimat är en utmaning, men som vi visat i vår analys av varför 1800-talets jordbruksmetoder kraschar, är den fysiska verkligheten alltid hårdare än den teoretiska modellen. Samma princip gäller för elnät och vattenförsörjning. Vi har också sett hur regulatoriska krav kan leda fel. Det finns en påtaglig risk för kompliance-skuld i ekobyar där vi bygger mock-miljöer för att passa bidragsschema och säkerhetsaudits, snarare än att designa för faktisk fysisk överlevnad. Ett agentic control plane som bockar av alla rutor i en IT-säkerhetsaudit kan fortfarande släcka ett helt samhälles vattentillförsel om det inte respekterar mekanisk tröghet. För att undvika dessa fällor använder vi vår blueprint för ekobyar som en grundläggande mall för att separera kritiska, fysiskt isolerade system från de nätverk som tillåts experimentera med automation. **Experiment att köra härnäst:** För att bevisa tesen om artificiell friktion i din egen miljö, rekommenderar jag att du genomför följande två experiment: 1. **Den dumma timern:** Koppla in en 'dum' fysisk timer (t.ex. en enkel mekanisk brytare eller ett fördröjningsrelä) i styrkretsen för en pump eller fläkt. Jämför dess felisolering mot en mjukvarubaserad AI-styrd logik vid en simulerad överbelastning. Mät hur den mekaniska brytaren begränsar skadan till en enda nod, medan den AI-styrda logiken försöker "rädda" situationen genom att sprida överlasten. 2. **Chaos-engineering i OT-sandlåda:** Kör ett experiment i en isolerad OT-sandlåda där du injicerar ett felaktigt tillståndsmeddelande i kontrollplanet. Mät exakt hur lång tid det tar innan de autonoma agenterna sprider det felaktiga tillståndet till andra noder, och dokumentera hur många fysiska aktuatorer som hinner aktiveras innan du manuellt tvingar in en systemomfattande nödstopp. Att bygga resilient infrastruktur handlar inte om att eliminera friktion. Det handlar om att veta exakt var friktionen måste finnas för att systemet ska överleva sina egna mest effektiva komponenter.HEIMLANDR -- Vi planerar och bygger ekobyar i Sverige.