En separat openAut-instans specialiserad på IT- och OT-säkerhet. Den 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.
Säkerhetsagentens design utgår från ett enkelt antagande: driftinstanserna kan komprometteras. Om den gör det ska säkerhetsinstansen vara opåverkad, ha bevarat alla bevis och kunna larma utan att använda samma kommunikationskanal som attackerades.
Säkerhetsinstansen körs på separat fysisk hårdvara i ett eget VLAN-segment. Den delar inget minne, ingen process och inga nätverksgränser med driftinstanserna. Komprometteras huvudsystemet är säkerhetsagenten opåverkad — den kör sin egen NemoClaw med sina egna nycklar, sina egna loggar och sin egna nätverksidentitet.
Säkerhetsagenten autentiserar med en dedikerad systemanvändare
(openaut-sec-ro)
som har exklusiv läsrättighet till auditloggar, konversationsloggar,
MQTT-data och systemmetrik. Kontot saknar shell-åtkomst utanför definierade
kommandouppsättningar. Ingen sudo. Ingen skrivåtkomst. Ingen möjlighet att
påverka konfiguration eller fältlager.
Teams-boten lyssnar i alla kanaler där Advisor-boten finns. Den reagerar aldrig på inkommande meddelanden, svarar aldrig på frågor och utför aldrig instruktioner. Prompt injection via Teams fungerar inte — boten har ingen exekveringsväg från inkommande meddelanden till handling. Larm går till ett separat säkerhetsteams-kanalflöde som Advisor-boten inte har åtkomst till.
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 läser angriparkontrollerat innehåll — det är hela poängen med att övervaka konversationer och loggar. Skyddet ligger inte i att innehållet aldrig läses, utan i hur det bedöms. Bedömningen görs i två steg, och det avgörande steget tar inga instruktioner.
Liten, icke-genererande klassificerare som snabb första linje mot prompt injection och jailbreak. Den följer inga instruktioner — den producerar bara en sannolikhet.
Grövre innehållsklassificering mot definierade riskkategorier — körs lokalt på säkerhetsinstansens egen AI-hårdvara.
DeBERTa-baserade detektorer som alternativ eller komplement — encoder-modeller utan textgenerering, och därför svåra att prompt-injicera.
Ytterligare ett öppet alternativ för risk- och innehållsklassificering. Modellvalet är utbytbart — principen är det inte.
Den genererande LLM:en (NemoClaw) används först efter att klassificeraren flaggat — för att formulera larmet, sammanfatta bevis och beskriva mönster på begripligt språk. Aldrig som det som avgör om något är ett hot.
NemoClaw hjälper compliance-ansvariga att tolka krav och generera dokumentation utifrån redan klassificerade händelser — en assistent, inte en beslutsfattare.
En genererande modell följer instruktioner — och kan därför luras av instruktioner gömda i det den läser. Den icke-genererande klassificeraren gör ingen sådan tolkning: den klassar text, den lyder den inte.
Blockerande inline-guardrails — som stoppar ett svar innan det skickas — hör hemma på Advisor och Engineer, där det finns en svarsväg att skydda. Säkerhetsinstansen kör samma klassificerare men i passivt analysläge: den blockerar ingenting i driftflödet, den observerar, korrelerar och larmar — plus compliance-skills. Det är därför den kan se allt utan att själv gå att styra.
Orkestreringen av rails och klassificerare är inte egenutvecklad — den bygger på etablerade öppna ramverk som körs helt lokalt på säkerhetsinstansens egen hårdvara. Inga molnanrop sker med driftdata: det är ett krav, inte en inställning, och en förutsättning för NIS2 och AI Act.
Passar Nemotron-stacken bakom NemoClaw och självhostas via vLLM eller NVIDIA NIM. Kör input-, output-, dialog- och retrieval-rails som kedjar samman klassificerarna ovan med policyer — allt på den lokala AI-hårdvaran.
MIT-licensierad verktygslåda med scanners för prompt injection, känslig data och toxiskt innehåll. Ett öppet alternativ för organisationer som hellre bygger sin egen pipeline.
Ramverk för att lägga flera guardrail-lager — inklusive promptgranskning och granskning av agentbeteende — i ett sammanhållet filter. Ytterligare ett byggblock, inte en låsning.
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.
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.
Säkerhetsagenten är designad med antagandet att även den kan vara ett mål. Varje attackvektor mot den är explicit stängd per design — inte per konfiguration.
En angripare skickar ett meddelande i en driftkanal med en instruktion till säkerhetsboten. Har ingen effekt på beteendet. Säkerhetsboten har ingen svars- eller kommandoväg från inkommande Teams-meddelanden. Innehållet analyseras — men av en icke-genererande klassificerare som inte följer instruktioner — så injicerad text kan inte kapa bedömningen. Den klassas, den lyds inte.
En angripare försöker kommunicera direkt med botkontot i Teams. Genererar ett larm. Kontot svarar inte. Interaktionsförsöket tidsstämplas, bevismaterial bevaras och säkerhetsteamet notifieras i #security-alerts — utan att driftflödet påverkas.
Angriparen tar kontroll över säkerhetsinstansen och försöker använda SSH-kontot för att påverka driftinstanserna. Kontot har inga skrivrättigheter. Filsystemsbegränsningar är i OS-kärnan. Eskaleringsförsök loggas i driftinstansernas auditdaemon och flaggas av säkerhetsagentens egna logganalys.
Angriparen komprometterar säkerhetsinstansen och försöker radera bevis. Audit-databasen är append-only med signaturer per post. Dessutom replikerar säkerhetsinstansen larmposter till ett append-only-mål i en separat förtroendedomän — en WORM-logg eller en extern syslog-mottagare — angriparen kan inte radera vad som redan skickats.
En angripare på säkerhetsinstansen försöker nå OT-nätverket. VLAN-ACL:er på switchnivå blockerar all trafik utom SSH mot driftinstanserna och Teams-API utgående. Säkerhetsinstansen har ingen routad väg till VLAN 10 (OT) eller VLAN 20 (Mgmt) — det är en nätverksarkitekturrestriktion, inte en mjukvarurestriktion.
En angripare försöker lura säkerhetsagentens AI-analys genom att plantera normaliserande mönster i konversationer över tid — för att dölja framtida attacker i baselinen. Säkerhetsinstansen korrelerar alltid mot OT-auditloggar oberoende av Teams-data — ett spår måste synas i båda källorna för att väljas bort som falskt positiv.
Modellen ovan är ett konceptprojekt, och ärlighet om dess gränser är en del av designen.
Ingen klassificerare fångar allt. Nya jailbreak-tekniker dyker upp, och detektion är ett kontinuerligt kapprustningslopp — inte ett löst problem.
Godartad text med triggerord kan falskflaggas. För hårt satta trösklar skapar larmtrötthet; för lösa missar hot. Slutsatsen är defense-in-depth — flera oberoende lager, inte en enda grind.
Protokollanomalier, okända enheter och värden utanför fysikaliska gränser fångas av statistisk och regelbaserad anomalidetektering plus skills — inte av en LLM-guardrail.
Språkmodellklassificerare hör hemma på IT- och konversationssidan. OT-sidan vilar på deterministiska regler och baseline-jämförelser mot Systemdatabasen — där en LLM aldrig är grindvakt.
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.