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

Sikkerhetsbransjen har en mønster når en ny teknologi oppstår, vi begynner umiddelbart å 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 veggerne vi bygger i helt feil steder.

Gå inn i en 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 skynder seg å selge “AI-sikkerhetsverktøy” som fokuserer eksklusivt på modellnivåkontroller, som guardrails, prompt-injeksjonsforsvar og modell-overvåkingsplattformer.

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

Den virkelige angrepsflaten 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, datastyringsrammer, MLOps-sikkerhetverktø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 holder OAuth- token til dusinvis av SaaS-plattformer, API-nøkler med eksessive skytjenestetillatelser og identitetstilitsforhold som kan skape direkte veier 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-integreringer som spenner over identitetsleverandører, skytjenester, databaser og forretningskritiske systemer. Hver integrering er en potensiell angrepsvei, og hver API-tilkobling er en tillitsgrense som angripere aktivt tester.

Problemet er ikke at våre AI-sikkerhetsverktøy er feil. 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 eiendom 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.

Vurdér en typisk bedrifts AI-utplassering. 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: dens sikkerhetspostur, promptvalidering, utgangssikkerhet. Men angripere fokuserer på integreringene: hva de kan nå gjennom kompromitterte tjenekontoer, hvor de kan svinge gjennom API-manipulasjoner, hvilke tillitsgrenser de kan krysse gjennom utnyttede integreringer.

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

Angrepsveier respekterer ikke produktgrenser

Her er hvor de fleste organisasjonene blir fast. De har deployert sikkerhetsverktøy som hver gir visibilitet inn i et enkelt domene. Et verktøy overvåker skytjenestetillatelser. 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 kobles sammen.

Ifølge Gartner, bruker organisasjonene i gjennomsnitt 45+ sikkerhetsverktøy. Likevel, til tross for denne massive investeringen, er angripere suksessfulle i å kjede sammen miskonfigurasjoner over disse domenene fordi ingen enkelt verktøy kan se den fullstendige 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 sikkerhetsverktøy. Men koblet sammen? Det er en kritisk eksponering. Og det er fullstendig usynlig hvis du ser på hvert sikkerhetsdomene i isolasjon.

Exponeringsstyringsimperativet

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

Det er ikke nok å spørre om AI-modellene dine er sikre. Sikkerhetsteam må forstå hva en angriper kan nå hvis de kompromitterer en AI-tjenekonto. De må ha visibilitet inn i hvordan miskonfigurasjoner over skytjenester, SaaS og identitetssystemer kan kobles sammen. De må vite hvordan AI-integreringer endrer deres angrepsflate i sanntid. Og de må prioritere risiko basert på faktisk angrepbarhet, ikke bare alvorlighetspoeng.

De fleste sikkerhetsprogrammene prioriterer fortsatt risiko i isolasjon, ved å bruke CVSS-poeng og overholdelsesliste 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 seg konstant. Nye integreringer 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.

Hva angrepsvei-bevisst sikkerhet faktisk ligner

Å sikre AI i produksjon krever en grunnleggende annen tilnærming, og det kommer ned til fire nøkkelendringer i tenkning.

Først, du må ha samlet visibilitet over sikkerhetsdomener. Slutt å spørre hver sikkerhetsverktøy om å operere i sin egen silo. Dine skytjenestesikkerhets-, identitetstyrings-, SaaS-håndtering- og sårbarhets-scanning-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ødt lag-øvelser for å oppdage utnyttbare veier. Test kontinuerlig hvordan en angriper kan flytte 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 nåbart fra en internett-eksponert eiendom. 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 er våpenisert, ikke etter en hendelse.

Advarselen vi ikke kan ignorere

Ettersom AI blir integrert over hver lag i bedriftsstakken, utvides angrepsflaten raskere enn sikkerhetsteam kan manuelt resonere om det. Vi legger til AI-integreringer ti ganger raskere enn vi sikrer dem.

Hvis du sikrer AI i isolasjon, beskytter modellen mens du ignorerer økosystemet den 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 over hele din miljø.

Bedriftene som vil sikre AI-suksessfullt, vil ikke være de med flest AI-sikkerhetsverktøy. De vil være de som forstår at AI-sikkerhet er uatskillelig fra eksponeringsstyring over hele deres angrepsflate.

Modellsikkerhet er minimumskrav. Hva betyr er å forstå hva en angriper kan nå når de kompromitterer en AI-integrering. Inntil sikkerhetsteam kan svare kontinuerlig, i sanntid, over hele deres miljø, sikrer de ikke AI. De håper bare at vegger de har bygget er på riktig sted.