Säkerhetsagentens design utgår från ett enkelt antagande: driftinstanserna kan komprometteras. Om de gör det ska säkerhetsinstansen vara opåverkad, ha bevarat relevanta bevis och kunna larma utan att använda samma driftkanal som attackerades.
En separat openAut-instans specialiserad på IT- och OT-säkerhet läser driftinstansernas loggar via read-only SSH, lyssnar på alla Teams-kanaler utan att kunna ta emot kommandon, och flaggar misstänkt aktivitet till ett isolerat säkerhetsteam — utan att någon kan instruera den via Teams. Principen är medveten: agentstacken är kraftfull och tillåtande som standard, så säkerhetsvärdet ligger i att begränsa vad agenten kan göra — inte bara vad den blir tillsagd. En manipulerad modell har ingen skrivväg att utnyttja.
De tre instanserna svarar på vad systemet får göra. Den här delen svarar på vem som får operera dem — och, viktigast, vem som får ändra reglerna. Alla som arbetar i systemet, såväl intern personal som upphandlade konsulter, kör genom avgränsade, signerade behörighetsprofiler. En profil låter dig göra ditt jobb inom ett bestämt område, men kan aldrig ändra säkerhetsövervakningen, ändra vad andra roller får göra, utöka sin egen behörighet eller nå eller administrera Advisor- eller Security-instansen — det kräver en ändring hos en separat styrnivå (Policy Administration Point) som ingen driftroll når.
Modellen vilar på etablerade principer — minsta privilegium, uppdelade ansvar (IEC 62443, ISO 27001) och en oberoende auditor-roll (Security). Fullständigt designutkast i ADR 0002 och ADR 0003.
Säkerhetsagenten autentiserar mot driftinstanserna med en systemanvändare
(openaut-sec-ro)
som enbart existerar för att läsa loggar. Kontot har inget
interaktivt shell — /sbin/nologin — och
kan bara köra en fördefinierad kommandouppsättning via
authorized_keys-begränsningar.
Försöker säkerhetsagenten skriva en fil, ändra en konfiguration eller köra ett privilegierat kommando avvisas det av operativsystemets filrättighetssystem — inte av NemoClaw. Det finns ingen mjukvarulogik att kringgå. Begränsningen är i kärnan.
Komprometteras säkerhetsinstansen kan en angripare i värsta fall läsa driftloggarna. De kan aldrig använda SSH-kontot för att påverka fältlager, konfiguration eller pågående reglering.
EDGE-01 · 10.20.4.11 · Profil A/D · OnlineEDGE-02 · 10.20.4.12 · Profil B/G · OnlineEDGE-03 · 10.20.4.13 · Profil C/E · OnlineEDGE-04 · 10.20.4.14 · Profil C/F · OnlineopenAut Security-boten registreras som medlem i exakt samma Teams-kanaler som Advisor-boten. Den ser alla meddelanden, filuppladdningar och konversationer. Den svarar aldrig på något i dessa kanaler.
Säkerhetsagentens NemoClaw har ingen svarsväg för inkommande Teams-meddelanden: en felhanterare fångar alla inkommande webhooks så att de aldrig kan utlösa ett svar eller en handling. Innehållet läses ändå — det är så hot upptäcks — men bedömningen görs av en icke-genererande klassificerare, inte av en LLM som kan luras av instruktioner i texten. Skyddet ligger i hur innehållet analyseras, inte i att det aldrig läses.
När ett misstänkt mönster detekteras skickar säkerhetsagenten ett larm till en kanal som Advisor-boten inte är medlem i. Säkerhetspersonalen tar emot larmet i ett flöde som driftsoperatörer inte ser — och som Advisor-boten inte kan manipulera.
Om någon skickar ett direktmeddelande till säkerhetsbotkontot genereras ett automatiskt larm: "Försök att interagera med säkerhetsagenten direkt." Kontot svarar inte. Interaktionsförsöket bevaras i audit-loggen.
Säkerhetsagenten korrelerar Teams-konversationer mot driftinstansernas SSH-auditlogg och kommandologg. En begäran om att lista edge-noder i Teams följt av ovanligt SSH-nyckelutbyte på driftinstanserna är ett sammansatt larm — inget av systemen ser det ensamt.
Säkerhetsagenten täcker två angreppsytor: IT-sidan — konversationer, botar, prompter och autentisering — och OT-sidan — protokollanomalier, ovanliga skrivkommandon och enheter som inte borde finnas på nätverket.
Instruktioner inbäddade i meddelanden, dokument eller bildtexter som försöker överskriva Advisor-botens beteende. Detekteras via mönsteranalys av konversationsinnehåll.
Eskalerande konversationer som gradvis försöker övertala Advisor-boten att utföra skrivåtgärder, lämna ut konfiguration eller agera utanför sin applikationsprofil.
Begäran om att sammanfatta och skicka känslig data externt — nätverkstopologi, IP-adresser, edge-nod-konfiguration, lösenordsrelaterade frågor. Flaggas oavsett avsändare.
Ovanliga inloggningstider, nya SSH-nycklar, misslyckade autentiseringsförsök eller förändrade användarrättigheter på driftinstanserna — synliga via audit-logg.
Kommandon som skickas vid ovanliga tidpunkter, med ovanlig frekvens eller mot objekt som aldrig ingått i normalt driftflöde — korrelerade mot historiska operationsdata.
Modbus- eller BACnet-skrivoperationer mot fältenheter som inte är en del av en aktiv, versionshanterad applikationsprofil. Alla skrivhändelser loggas med timestamp, ursprung och enhet.
Enheter som dyker upp på OT-nätverket och inte finns registrerade i Systemdatabasen. Genererar omedelbart larm — kan indikera rogue device eller lateral förflyttning.
Felaktigt formade Modbus-ramar, BACnet-läsningar av objekt utanför normal adressrymd, MQTT-klienter med ovanliga identiteter, retained messages på känsliga topics eller onormal publiceringsfrekvens.
Styrvärden som kommenderas utanför utrustningens säkra driftintervall — oberoende av om de härstammar från BMS, edge-nod eller manuellt kommando.
Sekvenser av nätverksskanning, ARP-förfrågningar eller portanslutningar mot OT-segment som inte ingår i normal driftprofil — indikerar möjlig rekognoscering inför attack.
Ingen detektionsmodell fångar allt — nya sätt att kringgå övervakning dyker upp, och det är ett pågående arbete, inte ett löst problem. Bevisbevarandet vilar därför inte på att säkerhetsinstansen aldrig kan komprometteras, utan på append-only-loggning med retention lock, replikerad till en extern förtroendedomän under separat administration — utformat så att redan replikerade bevis inte kan raderas i efterhand.
Larmet tar aldrig vägen tillbaka in i driftkanalen. Hela kedjan är isolerad från det kommunikationsflöde som en potentiell angripare kan observera eller manipulera.
Säkerhetsinstansen kör samma typ av lokal AI-hårdvara som driftinstanserna — men aldrig på samma fysiska maskin. Isolering är en arkitektonisk egenskap, inte en konfigurationsinställning.
Säkerhetsinstansen och driftinstanserna kommunicerar via ett VLAN-gränssnitt med explicit ACL: SSH port 22 inåt (till driftinstanserna) och Teams-API utåt. All annan trafik blockeras av nätverksinfrastrukturen — inte av mjukvara. En angripare som tar kontroll över säkerhetsinstansen kan inte använda den som språngbräda mot OT-nätverket eftersom routingtabeller och VLAN-access-listor förbjuder det på switchnivå. Det utgående Teams-API:t är enda egress-vägen — låst med explicit ACL och används enbart för strukturerade larm till säkerhetskanalen. Ingen rådata förs ut den vägen, så den blir ingen exfiltreringskanal.
openAut håller sig medvetet inom fem ramverk med en tydlig ansvarsfördelning — varje ramverk styr sin egen domän. ISO 27001 och IEC 62443 utgör den styrande respektive tekniska grund som allt vilar på. Tre av ramverken — AI Act, NIS2 och CRA — har dessutom dedikerade Security-skills som kombinerar passiv övervakning — flaggar avvikelser i realtid — med aktiv assistans: hjälper compliance-ansvariga att förstå krav, generera dokumentation och svara på revisorer. Skillsen delar underliggande data men analyserar mot separata regelverksmodeller.
Grunden för informationssäkerhetsarbetet — roller, policyer, riskhantering och ständig förbättring. Ramen som de övriga regelverken hängs upp i.
Krav på samhällsviktig verksamhet — riskhantering, leverantörskedja och incidentrapportering inom 24h/72h.
Säkerhetsarkitektur på drift- och fältnivå — zonindelning, security levels (SL) och härdning av OT.
Produktkrav på openAut-mjukvaran — SBOM, sårbarhetshantering och säkerhetsuppdateringar under hela livscykeln.
Krav på själva AI-funktionen — mänsklig kontroll, transparens, loggning och teknisk dokumentation.
AI Act Bilaga III punkt 2 täcker AI-system för förvaltning av kritisk infrastruktur. openAut analyserar och kan påverka el-, värme- och ventilationssystem i byggnader — vilket troligen kvalificerar som högrisk. Klassificeringen avgörs av din organisations jurister, men AI Act-skillet hjälper er att förbereda för det scenariot från dag ett.
Flaggar om AI-genererade åtgärdsrekommendationer inte har ett tydligt mänskligt godkännandesteg i loggen. Varje åtgärd som tangerar fältlager måste kunna spåras till ett explicit operatörsbeslut.
Kontrollerar att Advisor-botens svar innehåller konfidensnivå och motivering. Varnar om AI-output når operatörer utan förklarande kontext — svar som "byt modul" utan rotorsakskedja bryter mot Art. 13.
Verifierar att händelseloggar bevaras i minst den period AI Act kräver, att de är tillräckligt detaljerade för en extern revisor, och att de inte kan ändras i efterhand.
Assisterar i att hålla den tekniska dokumentationen aktuell: modellbeskrivning, träningsdata, testredsultat, riskbedömning, prestandamått. Varnar när dokumentationen inte synkroniserar med deployad version.
Spårar om AI-systemets precision försämras över tid — t.ex. att rotorsaksanalysen träffar sämre mot nya utrustningstyper. Prestandadrift utan dokumenterad åtgärd är en riskhanteringsbrist.
openAut körs helt lokalt utan molnanrop — vilket eliminerar en stor klass av AI Act-risker (dataöverföring, extern beroende, datasuveränitet). Lokalt hostad LLM-inferens med lokal data är den starkaste möjliga utgångspunkten för Art. 10 och 13-efterlevnad.
Kommunala och regionala fastighetsägare som förvaltar samhällsviktig infrastruktur — skolor, sjukhus, energianläggningar — omfattas av NIS2 Art. 21 krav på riskhantering. openAut Security-skillet mappar direktivets tio åtgärdskategorier mot faktisk systemstatus och flaggar när en kategori halkar under kravnivå.
NIS2 kräver tidig varning inom 24h och fullständig rapport inom 72h vid signifikanta incidenter. Skillen spårar detekterade incidenter mot dessa tidsgränser och larmar compliance-ansvarig om rapporteringsfönstret riskerar att missas.
Granskar att alla tredjepartsintegrationer — BMS-leverantörer, protokolldrivrutiner, edge-hårdvara — har dokumenterade säkerhetskrav i avtalen. Flaggar integrationer utan NIS2-kompatibla leverantörsavtal.
Kontrollerar att administrativa åtkomster till openAut-systemet skyddas med MFA och att inga delade konton används. Varnar vid konton utan aktivitetsspår under längre perioder.
CRA gäller produkter med digitala element — mjukvara och hårdvara med nätverksanslutning. openAut-mjukvaran faller under denna definition. MIT-licens och öppen källkod innebär inte undantag, men CRA har specifika lättnader för öppen källkod som inte distribueras kommersiellt. CRA-skillets primära uppgift: hålla er redo oavsett hur definitionen landar.
CRA kräver en aktuell komponentförteckning för alla digitala produkter. Skillen spårar openAuts beroenden — pymodbus, BAC0, paho-mqtt, EMQX, Telegraf, NemoClaw — och flaggar om en komponent har känd sårbarhet (CVE) utan tillämpad patch.
CRA kräver en publicerad policy för sårbarhetsmottagning och koordinerad rapportering. Skillen kontrollerar att openAuts security.txt och disclosure-policy är aktuella och att inkomna rapporter hanteras inom rimlig tid.
Aktivt utnyttjade sårbarheter i openAut-komponenter måste rapporteras till ENISA och relevant CSIRT inom 24h — samma tidsgräns som NIS2. Skillen bevakar CVE-databasen mot SBOM och eskalerar omedelbart vid träff.
CRA kräver att säkerhetsuppdateringar tillgängliggörs under produktens förväntade livslängd. Skillen spårar att openAut-releasen organisationen kör inte är End-of-Life och att kritiska patcher finns tillgängliga utan onödigt dröjsmål.
Läser openAuts deploya beroenden via SSH från driftinstanserna och genererar en aktuell SBOM i CycloneDX- eller SPDX-format. Uppdateras automatiskt vid ny deployment och sparas i revisionsloggen.
Om openAut distribueras på ett sätt som kräver CE-märkning assisterar skillen med att sammanställa teknisk dokumentation och EU-försäkran om överensstämmelse — även om MIT-licensen inte i sig kräver det.
CRA Skäl 18–19 ger lättnader för öppen källkod som inte distribueras i en kommersiell transaktion. Eftersom openAut är MIT-licensierat och gratis kan din organisation falla utanför tillverkaransvaret — men om ni anpassar och distribuerar openAut internt i upphandlad form kan ni klassas som distributör. Skillen hjälper er att utreda er specifika situation.