AI-sikkerhet er ikke brutt, vi forsvarer bare feil ting

Sikkerhetsbransjen har en mønster når en ny teknologi oppstår, vi begynner straks å bygge vegger rundt den. Vi gjorde det med skytjenester, vi gjorde det med containere, og nå gjør vi det med AI, bare denne gangen er vegger vi bygger helt på feil plasser.

Gå inn på noen hvilken som helst bedriftssikkerhetsgjennomgang i dag, og du vil høre de samme prioritetene: Sikre AI-modeller, beskytte treningdata, validering av utdata og deployering av AI-drevne copiloter. Leverandører rusler for å selge “AI-sikkerhet” verktøy som fokuserer eksklusivt på modellnivåkontroller, som guardrails, prompt-injeksjonsforsvar og modell-overvåkingsplattformer.

Men angripere bruker dine AI-integrasjoner som motorveier inn i alt annet.

Det virkelige angrepsflate som ingen ser

En mønster vi jevnt observerer over bedriftsmiljø forteller en bekymringsfull historie om sikkerhetsteam som investerer tungt i å sikre sine AI-utviklingsmiljøer: Modelltilgangskontroll, datagovernance-rammer, MLOps-sikkerhetstverktøy. Dette gir en falsk tillit til at deres AI er “låst ned.”

Men når du kartlegger den faktiske angrepsflaten, ser du at AI-chatboter ofte har OAuth- tokens til dusinvis av SaaS-plattformer, API-nøkler med eksessive skytillatelser og identitetstilitsforhold som kan skape direkte stier fra en enkel promptinjeksjon til produksjonsinfrastruktur. Modellene selv kan være sikre, men økosystemene de lever i er ofte åpne, og dette er ikke en randtilfelle.

Bedrifter bruker i gjennomsnitt 130+ SaaS-applikasjoner, med AI-integrasjoner som omfatter identitetsleverandører, skyinfrastruktur, databaser og forretningskritiske systemer. Hver integrasjon er en potensiell angrepsvei, og hver API-tilkobling er en tillitsgrense som angripere aktivt tester.

Problemet er ikke at våre AI-sikkerhetstverktøy er ødelagte. Det er at vi sikrer enkeltkomponenter mens angripere utnytter forbindelsene mellom dem.

Hvorfor modell-sentrert sikkerhet går feil

Den nåværende tilnærmingen til AI-sikkerhet opererer på en grunnleggende misforståelse av hvordan moderne angrep fungerer. Vi behandler AI som en selvstendig verdi som trenger beskyttelse, lik hvordan vi måtte sikre en database eller en webapplikasjon. Men AI i produksjon eksisterer ikke i isolasjon. Det er en node i et komplekst graf av identiteter, tillatelser, API-er og datastrømmer.

Overveur en typisk bedrifts AI-utbredelse. Du har en AI-agent med tilgang til din Google Workspace. Den er koblet til Salesforce gjennom API-er. Den er integrert med Slack for varslinger. Den henter data fra AWS S3-bøtter. Den er autentisert gjennom Okta eller Azure AD. Den utløser arbeidsflyter i ServiceNow.

Tradisjonell AI-sikkerhet fokuserer på modellen selv: Sikkerhetsposturen, promptvalidering, utgangssikkerhet. Men angripere fokuserer på integrasjonene: Hva de kan nå gjennom kompromitterte tjenestekontoer, hvor de kan svinge gjennom API-manipulasjoner, hvilke tillitsgrenser de kan krysse gjennom utnyttede integrasjoner.

Angrepet begynner eller slutter ikke med AI-modellen. Modellen er bare inngangspunktet.

Angrepsveier respekterer ikke produktgrenser

Her er hvor de fleste organisasjonene blir fast. De har deployert sikkerhetstverktøy som hver gir synlighet inn i en enkelt domene. Ett verktøy overvåker skytillatelser. Et annet sporer SaaS-konfigurasjoner. Et tredje håndterer identitetstyring. Et fjerde håndterer sårbarhetsstyring.

Hvert verktøy viser deg sitt puzzlestykke. Ingen av dem viser deg hvordan stykkene henger sammen.

Ifølge Gartner, bruker organisasjonene i gjennomsnitt 45+ sikkerhetstverktøy. Likevel, til tross for denne massive investeringen, utnytter angripere miskonfigurasjoner på tvers av disse domenene fordi ingen enkelt verktøy kan se den komplette angrepsveien.

En angriper trenger ikke å finne en kritisk sårbarhet i din AI-modell. De trenger bare å finne en kjede. Kanskje det er en miskonfigurert IAM-rolle koblet til din AI-tjeneste, som har tillatelser til en S3-bøtte, som inneholder legitimasjon til en SaaS-applikasjon som har admin-tilgang til din produksjonsmiljø.

Hver enkelt miskonfigurasjon kan score “medium” eller “lav” i dine sikkerhetstverktøy. Men koblet sammen? Det er en kritisk eksponering. Og det er fullstendig usynlig hvis du ser på hver sikkerhetsdomene i isolasjon.

Exponeringsstyringsimperativet

Dette er hvorfor samtalen må skifte fra “AI-sikkerhet” til kontinuerlig trussel-eksponeringsstyring for AI-integerte miljøer.

Det er ikke nok å spørre om AI-modellene våre er sikre. Sikkerhetsteam må forstå hva en angriper faktisk kan nå hvis de kompromitterer en AI-tjenestekonto. De må ha synlighet inn i hvordan miskonfigurasjoner på tvers av sky-, SaaS- og identitetssystemer kan kobles sammen. De må vite hvordan AI-integrasjoner endrer deres angrepsflate i sanntid. Og de må prioritere risiko basert på faktisk angrepsmulighet, ikke bare alvorlighetspoeng.

De fleste sikkerhetsprogrammene prioriterer fortsatt risiko i isolasjon, ved å bruke CVSS-poeng og overholdelseslisteer som fullstendig ignorerer om en sårbarhet faktisk er utnyttbar i deres spesifikke miljø.

Dette gapet er enda mer uttalt med AI-systemer fordi de endrer konstant. Nye integrasjoner legges til ukentlig. Tillatelser utvikler seg. API-tilkoblinger skifter. Din angrepsflate fra forrige måned er ikke din angrepsflate i dag, men din sikkerhetsvurdering er sannsynligvis det samme.

Hva angrepsvei-bevisst sikkerhet faktisk ser ut

Sikring av AI i produksjon krever en fundamentalt annen tilnærming, og det kommer ned til fire nøkkelendringer i tenkemåte.

Først, du trenger forent synlighet på tvers av sikkerhetsdomener. Slutt å spørre hver sikkerhetstverktøy om å operere i sin egen silo. Din sky-sikkerhet, identitetstyring, SaaS-håndtering og sårbarhetsskanning verktøy holder alle stykker av angrepsveipusslet. De må dele data i sanntid så du kan se hvordan miskonfigurasjoner kobles sammen.

Andre, omfavne kontinuerlig angrepsvei-simulering. Vent ikke på penetreringstester eller røde team-øvelser for å oppdage utnyttbare veier. Test kontinuerlig hvordan en angriper kan bevege seg gjennom din miljø, fokusert på faktisk utnyttbarhet fremfor å stole på teoretiske alvorlighetspoeng.

Tredje, prioriter basert på kontekst. En miskonfigurert S3-bøtte er ikke kritisk bare fordi den er offentlig. Den er kritisk hvis den er offentlig og inneholder legitimasjon og disse legitimasjonene har privilegert tilgang, og de er tilgjengelige fra en internett-eksponert verdi. Kontekst teller mer enn noen enkelt poeng.

Fjerde, beveg deg mot forebyggende retting. Når ditt SOC-team undersøker en varsling, har du allerede tapt verdifull respons tid. Moderne forsvar krever evnen til å lukke utnyttbare veier før de blir våpenisert, ikke etter en hendelse.

Advarselen vi ikke kan ignorere

Ettersom AI blir integrert over hele bedriftsstakken, utvider angrepsflaten raskere enn sikkerhetsteam kan manuelt resonere om det. Vi legger til AI-integrasjoner ti ganger raskere enn vi sikrer dem.

Hvis du sikrer AI i isolasjon, beskytter modellen mens du ignorerer økosystemet det opererer i, er du allerede forsinket. Angripere tenker ikke i verktøy, de tenker i veier. De utnytter ikke enkelt sårbarheter. De kobler sammen miskonfigurasjoner på tvers av hele din miljø.

Bedriftene som vil sikre AI med hell, vil ikke være de som har flest AI-sikkerhetstverktøy. De vil være de som forstår at AI-sikkerhet er uatskillelig fra eksponeringsstyring på tvers av hele deres angrepsflate.

Modellsikkerhet er en selvfølge. Hva som teller, er å forstå hva en angriper kan nå når de kompromitterer en AI-integrasjon. Inntil sikkerhetsteam kan svare på det kontinuerlig, i sanntid, på tvers av hele deres miljø, sikrer de ikke AI. De håper bare at vegger de har bygget er på riktig plass.