Från intelligens till befogenheter

Artificiell intelligens går bortom att besvara frågor och skapa innehåll. Allt oftare kan AI-system tolka instruktioner, utforma planer, välja verktyg och utföra uppgifter utan kontinuerlig mänsklig styrning.

Den skillnaden spelar roll.

Ett AI-system som rekommenderar en åtgärd skiljer sig från ett som har befogenhet att genomföra den. Skillnaden handlar inte nödvändigtvis om intelligens eller sofistikering. Den handlar om befogenheter.

Autonoma system är inte begränsade till de mest avancerade stora språkmodellerna. De omfattar specialiserade maskininlärningssystem, robotteknik, autonoma fordon, programvaruagenter och kombinationer av tekniker som självständigt fattar beslut eller utför åtgärder under definierade driftsförhållanden.

De potentiella fördelarna är betydande. Systemen kan bidra till vetenskapliga upptäckter, industriell verksamhet, hälso- och sjukvård, programvaruutveckling och cybersäkerhet. De kan också leda till oavsiktliga konsekvenser, röja känslig information eller vidta åtgärder som går utöver vad operatörerna avsett.

I Säkerhetsutmaningar vid utformning av autonoma system undersöker Mohammad Hamad och Sebastian Steinhorst säkerhetsutmaningar inom autonom incidenthantering, riskbedömning, åtkomstkontroll, datatillförlitlighet och samverkan mellan autonoma system. Deras forskning, som till stor del handlar om cyberfysiska system, visar att utmaningarna med att säkra självständiga maskinåtgärder sträcker sig bortom dagens LLM-agenter.

Autonomins bredare konsekvenser förtjänar att granskas ingående, däribland risken för fysisk skada. Men bevisningen måste tolkas varsamt. Händelser med automatiserade fordon kan till exempel inte automatiskt tillskrivas samma mekanismer som påverkar autonoma cybersäkerhetsagenter. Graden av autonomi, driftsförhållandena, människors medverkan och den kausala bevisningen spelar roll.

På samma sätt visar bevis för att autonom AI kan orsaka skada inte att styrningen nödvändigtvis halkar efter. Vi bör inte heller utgå från att autonoma system i sig är svåra att säkra.

Kärnfrågan är inte om AI kan utföra komplexa arbetsuppgifter, utan om de arkitektoniska, säkerhetsmässiga och organisatoriska ramverk som styr autonoma system kan fastställa lämpliga gränser för delegerade befogenheter och ge verifierbara belägg för att dessa gränser respekteras.

Cybersäkerhet erbjuder ett särskilt användbart perspektiv på den här frågan, eftersom säkerhetsexperter i årtionden har ifrågasatt antaganden om tillit, behörigheter, åtkomst och systembeteende.

Katt-och-råtta-leken i maskinens hastighet

Cybersäkerhet har länge beskrivits som en katt-och-råtta-lek.

Angripare upptäcker svagheter, försvarare inför skyddsåtgärder och båda sidor anpassar sig. Cykeln fortsätter när tekniker, taktiker och driftsmiljöer förändras.

Autonom AI förändrar inte nödvändigtvis spelets grundläggande regler. Den kan förändra vem – eller vad – som deltar, hur snabbt aktörerna agerar och hur mycket arbete som kan utföras utan kontinuerlig mänsklig inblandning.

Ett autonomt system för offensiv säkerhet kan identifiera exponerade tjänster, undersöka sårbarheter, ta fram möjliga angreppsvägar och testa om de går att utnyttja. Ett defensivt system kan använda liknande förmågor för att undersöka hot, identifiera svagheter och verifiera att åtgärderna har avhjälpt problemen.

Denna potential för användning i både offensiva och defensiva syften är central för förståelsen av de säkerhetsmässiga konsekvenserna av autonom AI.

Anthropics Project Glasswing är ett exempel på AI-stödd sårbarhetsidentifiering. I sin forskningsuppdatering från maj 2026 rapporterade Anthropic betydande resultat inom sårbarhetsidentifiering och betonade samtidigt de praktiska utmaningarna med verifiering, offentliggörande och uppdateringar.

Den skillnaden spelar roll. Att upptäcka en sårbarhet är inte detsamma som att bekräfta att den går att utnyttja, åtgärda den eller visa att det berörda systemet är säkert.

Fler upptäckter kan ge bättre överblick, men samtidigt öka kraven på de människor och processer som ansvarar för att hantera dem.

Säkerhetsutfallet beror på vad som händer härnäst.

Om angripare och försvarare kan automatisera delar av sitt arbete är den relevanta frågan inte bara vilken sida som har den mest kapabla modellen. Frågan är om försvararna kan omsätta upptäckter i effektiva åtgärder och oberoende verifiera resultaten.

Traditionella penetrationstester blir inte obsoleta för att AI kan utföra offensiva uppgifter. Testernas omfattning måste utökas till att innefatta system som tolkar instruktioner, använder verktyg, kombinerar behörigheter och strävar mot mål i flera steg.

Målet är detsamma som tidigare: hitta svagheter, fastställa hur allvarliga de är, åtgärda dem och bevisa att skyddsåtgärderna fungerar.

Arkitektoniska skarvar: där säkerhetsgränser möts

En av de mer subtila riskerna med autonoma system uppstår när komponenter som var för sig är behöriga samverkar på sätt som leder till oavsiktliga följder.

Jag kallar dessa samverkanspunkter för arkitektoniska skarvar.

Tänk på ett vanligt exempel. En organisation begränsar åtkomsten till en fil med hjälp av NTFS-behörigheter. En separat tjänst för molnbaserad fildelning gör det möjligt för en behörig användare att dela informationen externt.

Varje system kan fungera enligt sina egna regler. Men samspelet mellan dem kan leda till att information delas på ett sätt som överskrider den säkerhetsgräns organisationen avsett.

Detta är ett exempel på potentiellt motstridiga policyer, inte ett påstående om att någon fildelningsprodukt är sårbar.

Problemet behöver inte bero på en brist i något av skydden var för sig. Det kan handla om att den avsedda säkerhetspolicyn inte upprätthålls genom hela arbetsflödet.

Liknande situationer kan uppstå med autonoma AI-system när modeller, applikationer, identiteter, verktyg, kodarkiv och externa tjänster kopplas samman.

En agent kan ha behörighet att läsa ett dokument, skapa ett kodarkiv och ladda upp filer. Det innebär inte nödvändigtvis att den har befogenhet att kombinera dessa åtgärder på ett sätt som röjer konfidentiell information.

Forskningen ger ett praktiskt skäl att undersöka dessa samspel.

I AgentDojo utvärderade forskare promptinjektionsattacker mot AI-agenter som använder verktyg, med 97 realistiska uppgifter och 629 säkerhetstestfall. Resultaten visade att skadliga instruktioner som fördes in via obetrodda verktygsutdata kunde äventyra vissa säkerhetsegenskaper, även om varken attackerna eller agenterna lyckades i alla fall.

Forskningen fastställer inte hur ofta dessa attacker lyckas i produktionsmiljöer. Den visar däremot varför det inte räcker att enbart utvärdera modellernas svar för att förstå hur ett system som är anslutet till verktyg beter sig.

En närbesläktad risk beskrivs ibland som behörighetstvätt: en handling framstår som legitim eftersom den utförs via ett behörigt verktyg eller en mellanhand, trots att det samlade beteendet överskrider den avsedda befogenhetsgränsen.

När flera agenter samarbetar krävs uttryckliga regler för medverkan, informationsutbyte och tillåtna åtgärder.

Ansvarsfördelningen måste också fastställas för hela arkitekturen.

Modellleverantörer, plattformsoperatörer, agentutvecklare och organisationer som driftsätter systemen kan kontrollera olika delar av dem. En fungerande modell för delat ansvar tydliggör vem som kontrollerar varje gräns, vem som kan godkänna undantag, vem som övervakar körningen och vem som agerar när något går fel.

Autonomi undanröjer inte ansvar. Den gör det ännu viktigare att veta var ansvaret ligger.

Offensiv stringens: att testa det vi tror oss veta

Här kommer vi till ett begrepp som jag beskriver som offensiv stringens.

Offensiv stringens är ett disciplinerat förhållningssätt till adversariella tester, kritisk granskning och evidensbaserad validering som utmanar antaganden om säkerhet. Det utvärderar hur system beter sig under realistiska förhållanden i stället för att enbart förlita sig på arkitekturdesigner, dokumenterade skydd eller upplevd säkerhet.

De grundläggande metoderna är väletablerade. Penetrationstester, hotmodellering, red teaming och säkerhetsvalidering har länge utmanat antaganden om försvar.

Offensiv stringens förenar dessa metoder kring en central fråga:

Vilka belägg visar att den avsedda säkerhetsgränsen håller?

En organisation kan ha policyer som begränsar känslig information, en modell som konfigurerats för att avvisa otillåtna förfrågningar och en agent med begränsade behörigheter.

Det är betydelsefulla skyddsåtgärder. Att de finns visar dock inte i sig att hela systemet beter sig säkert under adversariella förhållanden.

En modell kan avvisa en skadlig instruktion samtidigt som ett behörigt verktyg ändå tillåter en oavsiktlig åtgärd. En policy kan verka korrekt, trots att samspelet mellan systemen skapar en oväntad väg runt den.

Ibland kallar jag detta för en ”skyddsrälsillusion”: att man misstar förekomsten av skyddsräcken för belägg för att systemet inte kan passera den gräns som de är avsedda att upprätthålla.

Skyddsräcken är användbara. Men deras effektivitet måste fortfarande kunna beläggas.

Tänk på en autonom agent som har fått i uppdrag att utreda en misstänkt kompromettering. Den kan hämta loggar, granska användaraktivitet och rekommendera åtgärder för att begränsa incidenten.

Under ett godkänt säkerhetstest för in en adversariell testare vilseledande instruktioner i information som agenten förväntas ta del av.

Testet bör inte stanna vid att fastställa om agenten följde instruktionerna.

Det bör också undersöka om agenten försökte utföra en obehörig åtgärd, om oberoende skydd hindrade den från att genomföras, om försöket loggades och om systemet återhämtade sig på lämpligt sätt.

Offensive Rigor knyter samman fem aktiviteter:

1. Fastställ antagandet: Identifiera den säkerhetsegenskap som arkitekturen förväntas upprätthålla.
2. Utmana antagandet: Testa realistiska angreppsvägar, manipulerade indata och kombinationer av legitima funktioner.
3. Samla in bevis: Ta reda på vad systemet försökte göra, vad som faktiskt genomfördes och vilka skyddskontroller som aktiverades.
4. Åtgärda svagheten: Hantera den modell, det arbetsflöde, de behörigheter, den arkitektur eller den operativa process som orsakade felet.
5. Verifiera korrigeringen: Testa den relevanta angreppsvägen igen och bekräfta att den avsedda säkerhetsegenskapen upprätthålls.

Det är skillnaden mellan att testa hur en modell svarar och att testa säkerheten i hela systemet.

Det kräver också att man undersöker vad som händer efter att en angripare först fått fotfäste. Angriparen kan försöka samla in autentiseringsuppgifter, eskalera behörigheter, bibehålla åtkomst eller förflytta sig i sidled genom att missbruka funktioner som redan finns tillgängliga i miljön.

Att ett verktyg är legitimt innebär inte att all användning av det är legitim.

Syftet med Offensive Rigor är inte att utgå från att autonoma system är osäkra. Syftet är att genom tester fastställa var deras säkerhetsgränser håller.

Villkorad autonomi: skilj intelligens från befogenheter

Ett arkitektoniskt sätt att hantera detta är att skilja mellan vad ett AI-system kan göra och vad det har befogenhet att göra.

Jag beskriver detta tillvägagångssätt som villkorad autonomi.

Villkorad autonomi innebär att lämplig grad av självständighet beror på uppgiften, driftmiljön, de möjliga konsekvenserna, osäkerheten och vilka belägg som finns för att motivera en åtgärd.

En agent som sammanfattar offentlig information behöver inte nödvändigtvis samma tillsyn som en agent med befogenhet att inaktivera konton, ändra brandväggsregler eller göra ändringar i produktionsinfrastruktur.

Den senare kan behöva uttryckliga regler för uppdraget, behörigheter som upprätthålls oberoende av agenten, starkare auktorisering och mänskligt godkännande av åtgärder med betydande konsekvenser.

Dessa gränser bör inte utvidgas enbart för att en agent bedömer att bredare åtkomst skulle hjälpa den att nå sitt mål.

En agent kan ompröva hur den ska utföra en godkänd uppgift utan att skaffa sig ytterligare befogenheter.

OWASP:s topp 10-risker för LLM-applikationer tar upp detta problem i kategorin LLM06:2025 Överdriven handlingsfrihet. OWASP identifierar överdriven funktionalitet, alltför omfattande behörigheter och autonomi som riskkällor och rekommenderar att funktionerna begränsas och att auktorisering upprätthålls oberoende av agenten.

Villkorad autonomi tillämpar dessa principer utifrån den operativa risken.

Åtkomsten till information bör begränsas till det som uppgiften kräver. Verktygsbehörigheter bör begränsas till godkända åtgärder. Handlingsbudgetar, hastighetsbegränsningar, krav på godkännande och villkor för att avbryta kan begränsa körningen.

Dessa skyddsåtgärder är särskilt viktiga vid autonom offensiv testning.

En testagent kan legitimt upptäcka autentiseringsuppgifter eller känslig information när den arbetar mot ett godkänt mål. Men att den upptäcker en autentiseringsuppgift innebär inte att modellen behöver få tillgång till dess värde i klartext.

Ett säkerhetslager kan hålla känsliga autentiseringsuppgifter åtskilda från modellen och förmedla användningen av dem genom auktorisering som upprätthålls oberoende av modellen. En förmedlingstjänst för autentiseringsuppgifter kan till exempel tillhandahålla en hemlighet direkt till en godkänd tjänst utan att i onödan exponera den för modellen.

Detta tillämpar de etablerade principerna om minsta möjliga behörighet och åtskillnad av arbetsuppgifter.

Det väcker också en intressant fråga om arkitekturen Bring Your Own Model (BYOM) eller Bring Your Own LLM (BYO-LLM).

Om den underliggande modellen byts ut i morgon, vilka säkerhetsgarantier består då?

Auktorisering av uppgifter, isolering av autentiseringsuppgifter, begränsningar av åtkomstens omfattning, loggning och tillämpning av policyer kan finnas i det omgivande säkerhetslagret i stället för att helt förlita sig på modellens beteende.

Det innebär inte att säkerhetslagret automatiskt är säkert eller att modellerna är utbytbara. Olika modeller kan tolka instruktioner på olika sätt, anropa verktyg på olika sätt och medföra olika typer av fel.

En meningsfull utvärdering måste testa både de kontroller som är avsedda att förbli oförändrade och de beteenden som förändras när modellen byts ut.

Kanske är några av de mest beständiga säkerhetsegenskaperna de som kan upprätthållas oberoende även när intelligenskomponenten utvecklas.

När AI agerar på AI: verifieringsproblemet

Tänk dig ett hypotetiskt arbetsflöde för säkerhetsarbete:

Undersök den här incidenten, samla in bevisen, identifiera vilka identiteter som har påverkats, föreslå åtgärder för att begränsa incidenten, genomför de godkända åtgärderna och verifiera resultatet.

En utredande agent analyserar telemetridata. En annan rekommenderar inneslutningsåtgärder. En behörig agent för verkställighet genomför ändringar. En verifieringsagent utvärderar resultatet.

Det här illustrerar autonom incidenthantering med återkoppling, inte ett dokumenterat misslyckande i hela branschen.

Anta att den första agenten felaktigt identifierar en identitet som komprometterad. En andra agent godtar den slutsatsen och inaktiverar kontot. En tredje bekräftar att kontot har inaktiverats och rapporterar att åtgärden lyckades.

Den valda åtgärden slutfördes.

Men var den ursprungliga bedömningen korrekt? Var åtgärden behörig? Hanterade inneslutningen det faktiska hotet? Orsakade den onödiga störningar?

Verifiering kan inte enbart bestå i att bekräfta att en agent har genomfört den åtgärd som den själv valde.

Att låta en annan AI-agent sköta verifieringen gör inte heller automatiskt resultatet oberoende.

Olika agenter kan förlita sig på samma felaktiga telemetridata, komprometterade information eller bristfälliga antaganden. Att de är överens fastställer inte de underliggande sakförhållandena oberoende av varandra.

Ju allvarligare konsekvenserna av en autonom åtgärd är, desto större är behovet av verifiering som är oberoende av det system som fattar beslutet.

Det oberoendet kan bygga på bevis som hämtats från separata källor, deterministiska policykontroller, begränsade exekveringsmiljöer, mänsklig granskning eller en kombination av skyddsåtgärder.

Kontrollerna bör stå i proportion till konsekvenserna av ett fel.

Åtgärder med liten påverkan som går att återställa kan lämpa sig för automatiserad verifiering. Åtgärder med stor påverkan eller som är svåra att återställa kan kräva starkare behörighetskontroller, oberoende bekräftelse och ett uttryckligt godkännande från en människa.

Fyra frågor hjälper till att skilja mellan de relevanta säkerhetsegenskaperna:

• Tolkade systemet den avsedda uppgiften korrekt?
• Låg åtgärden inom ramen för de befogenheter som hade delegerats?
• Höll sig genomförandet inom de tillåtna gränserna?
• Uppfyllde resultatet det avsedda säkerhetsmålet?

Dessa frågor hänger samman, men de är inte utbytbara.

En agent kan genomföra en behörig åtgärd som får ett oavsiktligt resultat. Den kan också uppnå ett till synes gynnsamt resultat genom en åtgärd som saknar behörighet.

Ingetdera bör automatiskt betraktas som en lyckad säkerhetsåtgärd.

I takt med att autonoma system blir mer kapabla handlar utmaningen inte bara om att göra det möjligt för dem att slutföra komplexa arbetsflöden. Det handlar om att ta fram tillräckliga belägg för att deras åtgärder förblir behöriga, lämpliga och korrekta.

Det innebär också att veta när man ska avbryta, eskalera, återställa en åtgärd eller acceptera en avgränsad och uttryckligen förstådd risk.

Förtroende måste följa beläggen

Autonom AI har inte enbart negativa säkerhetskonsekvenser.

Autonoma system kan hjälpa försvarare att upptäcka svagheter, utreda hot och utföra valideringsarbete som annars skulle kräva betydande mänskliga insatser.

Bättre modeller, starkare externa kontroller och mer mogna arbetssätt kan minska vissa risker som är förknippade med delegerade befogenheter.

Det vore därför för tidigt att dra slutsatsen att autonom AI i sig är osäker eller att styrningen inte kan hålla jämna steg med utvecklingen.

Det finns också ett starkt motargument mot uppfattningen att autonom AI kräver helt nya säkerhetsprinciper.

Många underliggande problem – alltför omfattande behörigheter, otillförlitliga indata, svag behörighetskontroll, inkonsekvent tillämpning av policyer och otillräcklig verifiering – har studerats i årtionden.

Etablerade kontroller kan redan erbjuda fungerande lösningar när de implementeras och testas på rätt sätt.

Autonomi kan förändra tempot, omfattningen och komplexiteten i tillämpningen av dessa kontroller. Den gör dem inte automatiskt ogiltiga.

Beläggen pekar mot en mer användbar fråga: Under vilka förhållanden kan autonoma system anförtros delegerade befogenheter, och hur visar vi att dessa förhållanden är uppfyllda?

Svaret kan inte bygga enbart på modellernas förmåga.

Det krävs arkitektoniska gränser, tydligt fördelat ansvar, behörighetskontroller som tillämpas oberoende, lämplig tillsyn och belägg för att skyddsåtgärderna fungerar under realistiska förhållanden.

Det krävs också en konsekvent men föränderlig syn på säkerhet och risk.

Våra grundläggande säkerhetsprinciper behöver inte ändras varje gång en ny modell lanseras. Men våra antaganden om hur principerna tillämpas måste ständigt ifrågasättas i takt med att förmågor, driftsmiljöer och delegerade befogenheter utvecklas.

Det är syftet med Offensive Rigor.

Inte för att bevisa att AI-system kommer att fallera, utan för att upptäcka var de kan fallera, fastställa konsekvenserna och validera de kontroller som är avsedda att förebygga eller begränsa sådana fel.

Den mer bestående fördelen kanske inte ligger i att bara välja en mer kapabel modell, utan i att bygga en arkitektur där modeller kan bytas ut utan att gränserna för tillit, befogenheter och verifiering äventyras.

Katt-och-råtta-leken fortsätter. I allt högre grad kan båda sidor ha autonoma aktörer.

Det viktiga är att se till att vår förmåga att hitta svagheter, åtgärda dem och påvisa resultaten inte går förlorad i kapplöpningen om att automatisera allt annat.

Tillit måste bygga på belägg.

Författarens anmärkning: De åsikter och tolkningar som framförs i den här artikeln är mina egna och återspeglar inte nödvändigtvis min arbetsgivares officiella ståndpunkter, policyer eller produktfunktioner.