AI-säkerhet är inte trasig, vi försvarar bara fel saker

Säkerhetsbranschen har ett mönster när en ny teknik dyker upp, vi börjar omedelbart bygga murar runt den. Vi gjorde det med molnet, vi gjorde det med containrar och nu gör vi det med AI, men den här gången är murarna vi bygger på helt fel platser.

Gå in på vilken som helst företagssäkerhetsgranskning idag och du kommer att höra samma prioriteringar: säkra AI-modeller, skydda utbildningsdata, validera utdata och distribuera AI-styrda copiloter. Leverantörer rusar för att sälja “AI-säkerhetsverktyg” som fokuserar uteslutande på modellbaserade kontroller, såsom räls, prompt-injektionsförsvar och modellövervakningsplattformar.

Men angripare använder dina AI-integrationer som motorvägar in i allt annat.

Den verkliga angreppsytan som ingen tittar på

Ett mönster som vi konsekvent observerar i företagsmiljöer berättar en oroande historia om säkerhetsteam som investerar kraftigt i att säkra sina AI-utvecklingsmiljöer: modellåtkomstkontroller, datagovernance-ramverk, MLOps-säkerhetsverktyg. Detta ger en falsk trygghet att deras AI är “låst”.

När du kartlägger den faktiska angreppsytan ser du att AI-chattbotar ofta har OAuth-token för dussintals SaaS-plattformar, API-nycklar med överdrivna molntillstånd och identitetstillitsrelationer som kan skapa direkta vägar från en enkel promptinjektion till produktionsinfrastruktur. Modellerna i sig kan vara säkra, men ekosystemen de lever i är ofta helt öppna och detta är inte en randfallssituation.

Företag använder i genomsnitt 130+ SaaS-applikationer, med AI-integrationer som omfattar identitetsleverantörer, molninfrastruktur, databaser och affärskritiska system. Varje integration är en potentiell angreppsväg och varje API-anslutning är en tillitsgräns som angripare aktivt provar.

Problemet är inte att våra AI-säkerhetsverktyg är trasiga. Det är att vi säkrar enskilda komponenter medan angripare utnyttjar anslutningarna mellan dem.

Varför modellbaserad säkerhet missar poängen

Den nuvarande tillvägagångssättet för AI-säkerhet bygger på en grundläggande missförstånd av hur moderna attacker fungerar. Vi behandlar AI som en fristående tillgång som behöver skydd, liknande hur vi skulle säkra en databas eller webbapplikation. Men AI i produktion existerar inte i isolering. Det är en nod i ett komplext nätverk av identiteter, behörigheter, API:er och dataflöden.

Överväg en typisk företags-AI-distribution. Du har en AI-agent med åtkomst till din Google Workspace. Den är ansluten till Salesforce via API:er. Den är integrerad med Slack för meddelanden. Den hämtar data från AWS S3-bucketar. Den autentiseras via Okta eller Azure AD. Den utlöser arbetsflöden i ServiceNow.

Traditionell AI-säkerhet fokuserar på modellen i sig: dess säkerhetspostur, promptvalidering, utdatasäkerhet. Men angripare fokuserar på integrationerna: vad de kan nå genom komprometterade tjänstekonton, var de kan vända sig genom API-manipulationer, vilka tillitsgränser de kan korsa genom utnyttjade integrationer.

Angreppet börjar inte eller slutar med AI-modellen. Modellen är bara ingångspunkten.

Angreppsvägar respekterar inte produktgränser

Här är där de flesta organisationer fastnar. De har distribuerat säkerhetsverktyg som var och en ger synlighet i ett enskilt domän. Ett verktyg övervakar molntillstånd. Ett annat spårar SaaS-konfigurationer. Ett tredje hanterar identitetstillsyn. Ett fjärde hanterar sårbarhetsledning.

Varje verktyg visar dig sin del av pusslet. Ingen av dem visar dig hur bitarna kopplar samman.

Enligt Gartner använder organisationer i genomsnitt 45+ säkerhetsverktyg. Trots denna massiva investering lyckas angripare med att kedja samman felkonfigurationer över dessa domäner eftersom inget enskilt verktyg kan se den fullständiga angreppsvägen.

En angripare behöver inte hitta en kritisk sårbarhet i din AI-modell. De behöver bara hitta en kedja. Kanske är det en felkonfigurerad IAM-roll som är kopplad till din AI-tjänst, som har behörighet till en S3-bucket, som innehåller autentiseringsuppgifter till en SaaS-applikation som har administratörsåtkomst till din produktionsmiljö.

Varje enskild felkonfiguration kan få ett “medium” eller “lågt” betyg i dina säkerhetsverktyg. Men kedjade samman? Det är en kritisk exponering. Och det är helt osynligt om du tittar på varje säkerhetsdomän i isolering.

Exponeringshanteringsimperativet

Detta är varför samtalet behöver skifta från “AI-säkerhet” till kontinuerlig hotexponeringshantering för AI-integrerade miljöer.

Det räcker inte att fråga om våra AI-modeller är säkra. Säkerhetsteam behöver förstå vad en angripare faktiskt kan nå om de komprometterar en AI-tjänstekonto. De behöver synlighet i hur felkonfigurationer över moln, SaaS och identitetssystem kan kedjas samman. De behöver veta hur AI-integrationer förändrar deras angreppsyta i realtid. Och de behöver prioritera risker baserat på faktisk angreppbarhet, inte bara allvarlighetsbetyg.

De flesta säkerhetsprogram prioriterar fortfarande risker i isolering, med hjälp av CVSS-betyg och regelefterlevnadslistor som helt ignorerar om en sårbarhet faktiskt är utnyttjbar i er specifika miljö.

Detta gap är ännu mer uttalat med AI-system eftersom de förändras konstant. Nya integrationer läggs till varje vecka. Behörigheter utvecklas. API-anslutningar skiftar. Er angreppsyta från förra månaden är inte er angreppsyta idag, men er säkerhetsbedömning är förmodligen densamma.

Vad angreppsvägsmedveten säkerhet faktiskt ser ut

Att säkra AI i produktion kräver ett fundamentalt annorlunda tillvägagångssätt, och det handlar om fyra nyckelomsvängningar i tänkande.

För det första behöver du enad synlighet över säkerhetsdomäner. Sluta fråga varje säkerhetsverktyg att operera i sin egen silo. Dina molnsäkerhets-, identitetstillsyns-, SaaS-hanterings- och sårbarhetsscanningsverktyg alla innehåller bitar av angreppsvägpusslet. De behöver dela data i realtid så att du kan se hur felkonfigurationer kedjas samman.

För det andra, anta kontinuerlig angreppsvägssimulering. Vänta inte på penetrationstester eller röd team-övningar för att upptäcka utnyttjbara vägar. Testa kontinuerligt hur en angripare kan röra sig genom er miljö, med fokus på faktisk utnyttjbarhet snarare än teoretiska allvarlighetsbetyg.

För det tredje, prioritera baserat på sammanhang. En felkonfigurerad S3-bucket är inte kritisk bara för att den är offentlig. Den är kritisk om den är offentlig och innehåller autentiseringsuppgifter och dessa autentiseringsuppgifter har privilegerad åtkomst, och de är åtkomliga från en internetexponerad tillgång. Sammanhang betyder mer än något enskilt betyg.

Fjärde, gå mot förebyggande avhjälpning. När ditt SOC-team utreder en varning har du redan förlorat värdefull reaktionstid. Modern försvar kräver förmågan att stänga utnyttjbara vägar innan de vapenbeläggs, inte efter en incident.

Varningen vi inte kan ignorera

När AI blir inbäddat i varje lager av företagsstacken expanderar angreppsytan snabbare än säkerhetsteam kan manuellt resonera om den. Vi lägger till AI-integrationer i 10 gånger snabbare takt än vi säkrar dem.

Om du säkrar AI i isolering, skyddar modellen medan du ignorerar ekosystemet det opererar i, är du redan efter. Angripare tänker inte i verktyg, de tänker i vägar. De utnyttjar inte enskilda sårbarheter. De kedjar samman felkonfigurationer över hela er miljö.

De företag som kommer att lyckas säkra AI kommer inte att vara de med de flesta AI-säkerhetsverktygen. De kommer att vara de som förstår att AI-säkerhet är oskiljaktig från exponeringshantering över hela deras angreppsyta.

Modellsäkerhet är en grundförutsättning. Vad som betyder något är att förstå vad en angripare kan nå när de komprometterar en AI-integration. Tills säkerhetsteam kan svara på det kontinuerligt, i realtid, över hela sin miljö, säkrar de inte AI. De hoppas bara att murarna de byggt är på rätt platser.