Fyra misslyckanden. Fyra lager. Arkitekturen i sig är sårbarheten.

En nyligen publicerad episod av New York Times’ Hard Fork-podcast den 10 april 2026 undersökte cybersäkerhetsimplikationerna av avancerade AI-system och ställde en fråga som branschen har undvikit: vad om cybersäkerhet inte presterar dåligt, men är grundläggande felramad?

Avsnittet sändes veckor efter en serie incidenter som gjorde svaret svårt att ignorera. Under en månad bröt en autonom AI-agent igenom McKinseys interna AI-plattform på bara två timmar. En leverantörskedjeattack på en allmänt använd öppen källkods-AI-bibliotek spred sig till nedströmsföretag. Forskare visade att den hårdvara som var tänkt att vara sista försvarslinjen kunde brytas med standarddelar som kostade mindre än tusen dollar. Och Anthropic avslöjade att en frontmodell hade autonomt hittat tusentals noll-dagarssårbarheter i kod som branschen ansåg vara stabil.

Fyra incidenter. Fyra lager av AI-stapeln: applikation, orkestrering, hårdvara och operativsystem. Var och en avslöjade betydande begränsningar i de kontroller som var designade för att skydda dem.

Slutet på perimeter-tänkande

Traditionell cybersäkerhet vilar på en enda premis: med tillräckliga kontroller, övervakning och investeringar kan system säkras. Den premisen har format årtionden av arkitektur, inklusive brandväggar, identitetshantering, slutpunktsäkerhet och SIEM-plattformar, alla byggda på idén att synlighet och sträng hantering motsvarar säkerhet.

Branschens skift mot Zero Trust Architecture speglar en växande erkänsla av att traditionella nätverksgränser inte längre kan antas vara pålitliga. Men även när förtroendemodellerna utvecklas introducerar AI-system en annan utmaning: känsliga data samlas rutinmässigt in, bearbetas och delas över flera lager av infrastruktur.

Detta tillvägagångssätt hade sin betydelse när systemen var relativt centraliserade och data förblev inom tydligt definierade gränser. Det blir långt mindre effektivt när data rör sig kontinuerligt över moln, API:er, tredjepartsleverantörer och AI-pipelines, medan användare och beräkningsresurser är distribuerade globalt. Perimetern är inte längre en gräns. Det är en konstant föränderlig yta, och vi tillämpar fortfarande kontrollbaserat tänkande på system som inte realistiskt kan kontrolleras.

Applikationslagermisslyckande: McKinseys Lilli

Den 9 mars 2026 publicerade säkerhetsstartuppen CodeWall en avslöjande som belyste riskerna som organisationer som distribuerar AI internt står inför.

CodeWalls autonoma offensiva agent, utan behörighet, utan insiderkunskap och utan mänsklig vägledning, uppnådde läs- och skrivåtkomst till produktionsdatabasen bakom Lilli, McKinseys interna AI-plattform, på under två timmar. Lilli används av mer än 40 000 anställda för strategiarbete, kundforskning och dokumentanalys, och genererar hundratusentals prompter per månad.

Inträngningspunkten var inte sofistikerad. Agenten hittade offentligt exponerad API-dokumentation som listade över 200 slutpunkter, varav 22 inte krävde någon autentisering. Sårbarheterna som var inblandade speglar risker som betonats i OWASP Top 10 för LLM-applikationer, särskilt runt exponerade gränssnitt, osäkra integreringar och överdriven tillit till anslutna system.

En av dessa slutpunkter innehöll en SQL-injektionssårbarhet dold i JSON-fältnamn snarare än indata, där de flesta automatiserade skannrar tittar. Därifrån itererade agenten genom blind SQL-injektion tills produktionsdata blev tillgängligt.

Vad den fick åtkomst till: tiotals miljoner chattmeddelanden i klartext, hundratusentals filer, tiotusentals användarkonton och miljontals RAG-dokumentbitar som representerar år av proprietär forskning. Den identifierade också systemprompterna som styrde hur Lilli betedde sig för varje användare.

Den mest alarmerande upptäckten var inte volymen. Det var att systemprompterna var skrivbara. En angripare kunde ha tyst skrivit om instruktionerna som styrde Lillis utdata, förgiftat strategisk rådgivning, inbäddat konfidentiell data i svar eller tagit bort skyddsbarriärer helt, med en enda databasuppdatering. Inga distributioner. Inga kodändringar. Inga spår i applikationsloggar.

I ett offentligt uttalande sa McKinsey att de åtgärdade problemet inom några timmar och, efter en utredning av en tredjepartsforensisk firma, fann inga bevis för att kundkonfidentiell data hade åtkommit. Detta svar är viktigt. Men det ändrar inte den strukturella lärdomen: en decennier gammal sårbarhetsklass exponerade den operativa minnet för ett modernt AI-system eftersom data bakom det existerade i läsbar form.

Orkestreringslagermisslyckande: LiteLLM-attacken

Tre veckor senare dök samma mönster upp från en annan vinkel och genom ett annat lager.

LiteLLM är en öppen källkods-AI-gateway som används av tusentals företag för att dirigera förfrågningar över AI-leverantörer. Dess position i stapeln är kritisk: den sitter på orkestreringslagret, innehåller API-nycklar för varje leverantör den ansluter till. Varje kompromiss på detta lager exponerar autentiseringsuppgifter över varje integrerad tjänst.

Enligt en PyPI-incidentrapport utnyttjade hotaktörgruppen TeamPCP autentiseringsuppgifter kopplade till ett beroende i LiteLLM:s CI/CD-pipeline och använde underhållsåtkomst för att publicera två bakdörrsversioner av LiteLLM-paketet direkt till PyPI. De förorenade versionerna var live i mindre än en timme innan de togs bort. Operationen upptäcktes bara för att skadlig kod innehöll en bugg som kraschade en forskares maskin.

Leverantörskedjan var vektorn. Orkestreringslagret var målet. Genom att kompromettera ett enda beroende uppströms nådde angriparna lagret där varje nedströmsföretags leverantörsnycklar levde.

LiteLLM-teamet detaljerade senare incidenten och åtgärdsarbetet i en offentlig GitHub-avslöjande.

Smittorisken blev synlig nästan omedelbart. TechCrunch, Fortune och The Register rapporterade att Mercor, en 10 miljarder dollar AI-rekryteringsstart som arbetar med företag som OpenAI, Anthropic, Meta och Google, var bland de drabbade organisationerna. Angriparna hävdade att de hade erhållit stora mängder data, inklusive kandidatprofiler, personligt identifierbar information, kontraktvideointervjuer, källkod och API-nycklar. Meta pausade arbetet med Mercor i väntan på utredning. Ytterligare rapportering indikerade liknande skadlig kodsmönster som dykt upp i andra utvecklarverktyg och paket, vilket tyder på att operationen kan ha sträckt sig bortom ett enda projekt.

LiteLLM-incidenten var inte en anomali. Det var systemet som betedde sig som designat. Varje komponent i en AI-pipeline kräver åtkomst till användbar data för att fungera, vilket innebär att varje komponent också är en potentiell extraheringspunkt. Att fästa beroenden och rotera autentiseringsuppgifter är nödvändiga svar, men de hanterar incidenten, inte arkitekturen.

Hårdvarulagermisslyckande: TEE.fail

Om McKinsey-brottet visade att applikationslagret inte kan lita på, och LiteLLM-attacken visade att leverantörskedjan inte kan lita på, visade TEE.fail-forskningen att den hårdvara som är tänkt att kompensera för båda inte heller kan lita på fullt ut.

Den 28 oktober 2025 publicerade forskare från Georgia Tech, Purdue University och Synkhronix TEE.fail, en sidkanalsattack som extraherar kryptografiska nycklar från Trusted Execution Environments med fysisk minnesbussinterposition på DDR5-servrar. Attacken påverkar Intel SGX, Intel TDX och AMD SEV-SNP, inklusive fullt patched, trusted-status-system med AMD:s Ciphertext Hiding aktiverat. Dessa är teknologierna som främst främjas som grunden för konfidentiell datoranvändning.

Forskarna extraherade attestationsnycklar: den kryptografiska materia som används för att verifiera att arbetsbelastningar körs inom säkra miljöer. Med dessa nycklar kan ett komprometterat system presentera sig som pålitligt medan det fungerar helt utanför förväntade skydd. Forskarna demonstrerade detta direkt: de förfalskade TDX-attesteringar på Ethereums BuilderNet för att komma åt konfidentiell transaktionsdata och förfalskade Intel- och NVIDIA-attesteringar för att köra arbetsbelastningar utanför någon TEE medan de såg legitima ut.

NVIDIA-implikationen är viktig för AI specifikt. Eftersom GPU-attesteringen beror på CPU-attesteringen kan en komprometterad CPU-förtroendekedja undergräva garantier som ges av konfidentiella AI-inferensmiljöer. Hårdvarans grund för konfidentiell AI-inferens är, i denna hotmodell, villkorlig för en CPU-TEE som har demonstrerats vara bruten.

Hårdvaruleverantörerna svarade med formella råd. AMD sa att fysiska åtkomstattacker ligger utanför deras standardhotmodell och indikerade att de inte skulle utfärda firmwareuppdateringar. Intel och NVIDIA erkände resultaten och indikerade pågående åtgärdsarbete. Dessa svar är rimliga inom deras hotmodeller. De lyfter också fram en viktig gräns: garantier för hårdvarubaserad säkerhet beror på antaganden, inklusive fysisk kontroll, som suveräna, reglerade och motståndarorienterade distributioner inte alltid kan göra.

TEE.fail gör inte hårdvaruisolering irrelevant. Det visar att den är villkorlig.

OS-lagermisslyckande: Mythos-avslöjandet

Om de tre första incidenterna ifrågasatte applikationslagret, orkestreringslagret och hårdvarulagret, kallade en fjärde avslöjande i april 2026 i fråga lagret under alla dessa: operativsystemen och kärnbiblioteken som alla andra lager körs på.

Den 7 april 2026 tillkännagav Anthropic Claude Mythos Preview, en frontmodell som de vägrade att släppa offentligt på grund av dess offensiva säkerhetsförmågor, och lanserade samtidigt Project Glasswing, ett konsortium med AWS, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorgan Chase, Linux Foundation, Microsoft, NVIDIA och Palo Alto Networks. Anthropic rapporterade att Mythos, inom några veckor, hade autonomt identifierat tusentals tidigare okända sårbarheter över stora operativsystem och webbläsare och kunde producera fungerande exploateringar för många av dem.

De specifika resultaten är svåra att avfärda än någon sammanfattning antyder. En 27-årig bugg i OpenBSD. En 17-årig fjärrkörningsflaw i FreeBSds NFS-server, nu spårad som CVE-2026-4747, som ger rotåtkomst till en oautentiserad angripare. En 16-årig sårbarhet i FFmpeg, en av de mest utbredda mediebiblioteken på internet. I ett fall bad en Anthropic-engineer utan formell säkerhetsträning modellen att leta efter fjärrkörningsflaw över natten och vaknade upp till en komplett fungerande exploatering.

Detta är operativsystemsnivåresultat. OpenBSD och FreeBSD är kärnor. NFS är en kärnnätverksundersystem. FFmpeg är ett systembibliotek som levereras med de flesta Linux-distributioner och underbygger mediepipelines över hela internet. OS-lagret antogs vara säkert inte för att det hade bevisats vara säkert, utan för att att hitta djupa fel i det krävde sällsynt och dyrt mänskligt expertis. Det antagandet var den bästa tillgängliga heuristiken. Det var aldrig en garanti.

Detta villkor har nu lösts upp. Anthropic själv ramade in detta som en dual-use-skift: samma förmågor som tillåter en frontmodell att hitta och laga sårbarheter i skala tillåter den, i fel händer, att hitta och utnyttja dem i skala. Anthropics beslut att begränsa åtkomst via Project Glasswing reflekterar den verkligheten. Det löser den inte. Liknande förmågor kommer, enligt företagets egen bedömning, att spridas. Kostnaden för att granska legacykod har kollapsat, och med det det implicita försvaret att sådan kod var för gammal, för ovanlig eller för mycket granskad för att fortfarande innehålla kritiska fel.

Detta är också där de fyra incidenterna sammanfaller. Hårdvarulagrets konfidentiella skydd körs inte i isolering. De körs som kärnkod. Intel TDX körs i kärnan. NVIDIA:s GPU-drivrutin körs som kärnmoduler. CPU-TEE-attestationskedjan beror på ett pålitligt operativsystem för att rapportera vad den gör på ett trovärdigt sätt. Om OS-lagret under din TEE har årtionden av latent sårbarhet, och en frontmodell kan nu hitta dem i maskinens hastighet, då beror hårdvarulagrets villkorliga säkerhet på ett OS-lager vars säkerhetsgarantier just har försvagats av samma avslöjandecykel.

De tre tidigare incidenterna beskriver hur AI-system är på väg att brytas idag. Mythos beskriver takten vid vilken allt under dem, inklusive operativsystem, kärnmoduler och systembibliotek, kommer att granskas om av maskiner. McKinsey-brottet utnyttjade en SQL-injektionsklass av sårbarhet som har funnits i över två decennier. Sårbarheter av den vintage som modeller i Mythos-klassen är demonstrativt kapabla att hitta i industriell skala.

Mönstret

I varje fall var data i klartext i den stund det var viktigt.

Applikationslagret bearbetade den i klartext. Orkestreringslagret dirigerade den i klartext. Hårdvarulagret, trots sina skydd, krävde slutligen avkryptering vid exekveringspunkten. OS-lagret under alla tre opererade på den i klartext av definition. Fyra lager, fyra misslyckanden, och i varje lager gällde samma villkor: när brottet skedde var data läsbar.

Detta är inte en samling isolerade misslyckanden. Det är arkitekturen i sig.

Moderna AI-system är designade för att fungera på läsbar data. Varje lager, inklusive hämtning, dirigering, inferens och verktygsutförande, kräver plaintextåtkomst för att fungera. Det designvalet innebär att varje brott i varje lager exponerar data bakom det.

Frågan är inte om ett lager kommer att komprometteras. Det är vad angriparen hittar när det är.

Från antaget brott till noll exponering

Branschen har redan börjat skifta från “förhindra brott” till “anta brott”. Men de flesta arkitekturer har inte följt med på implikationerna.

Om brott är oundvikligt, då är den verkliga frågan inte hur man håller angripare ute. Det är vad som händer när de kommer in. Just nu är svaret enkelt: de får data. Eftersom trots all investering i säkerhetsinfrastruktur är data fortfarande exponerad i den exakta stund den blir värdefull, när den används.

Branschens svar har varit förutsägbart: mer övervakning, snabbare upptäckt, ytterligare lager av konfidentiell datoranvändning. Dessa är förbättringar. Men de löser inte det grundläggande problemet. De antar fortfarande att något lager – antingen programvara, hårdvara eller drift – kan lita på att hålla plaintext säker.

Alternativet är att ta bort plaintext helt. Inte att säkra lagren runt data, utan att göra data själv otillgängligt för vem som helst som når det. Beräkning på krypterad data, där prompter, modellvikter och utdata förblir krypterade under hela pipelinen, hanterar exponeringen som dessa incidenter utnyttjade.

Framsteg inom fullständigt homomorf kryptering och andra sekretessbevarande datortekniker börjar göra arkitekturer som minimerar eller eliminerar plaintextexponering alltmer praktiska för verkliga AI-arbetsbelastningar. Medan betydande prestanda-, skalbarhets- och implementeringsutmaningar kvarstår är målet grundläggande annorlunda än traditionella säkerhetskontroller: att minska värdet av en lyckad kompromiss snarare än att bara göra kompromissen mindre sannolik.

Skiftet är inte från ett säkerhetsverktyg till ett annat. Det är från att säkra system till att minska exponering. Från pålitlig infrastruktur till noll-förtroendedata. Från riskhantering till att minimera angreppsytan i sig.

Vad kommer härnäst

Hard Fork-diskussionen väckte frågan om cybersäkerhet är grundläggande felramad. Bevisen från de senaste veckorna tyder på att svaret är ja, åtminstone för AI.

Den gamla modellen antog att system kan säkras, brott kan inneslutas och exponering kan hanteras. Den framväxande verkligheten är att brott måste antas och exponering minimeras. Incidenterna som beskrivs här tyder på att att säkra AI-system kan bero alltmer på att minska mängden känslig data som är tillgänglig när kontroller misslyckas.

Sårbarheterna som avslöjades över dessa fyra incidenter är inte begränsade till ett enda lager. De är systemiska. Att hantera dem kommer att kräva mer än inkrementella förbättringar. Det kommer att kräva ett skift från att säkra system till att minska exponering, från att försvara perimetern runt data till att ta bort plaintext som perimetern byggdes för att skydda.

AI-säkerhet handlar inte längre om att hålla angripare ute. Det handlar om att säkerställa att när de kommer in, och de kommer, finns det ingenting läsbar för dem att hitta.