TL; DR
Alle styrer spør nå om AI-risiko, og de fleste sikkerhetsteam svarer med adjektiver i stedet for tall. Styringsrammeverkene forteller deg hva du skal styre. De forteller deg ikke hva du skal telle. Disse risikomålingene for AI kommer alle fra samme sted: koden organisasjonen din allerede sender ut.
- En agentisk AI-strategi har tre lag, og bare ett av dem er modellen. Hva agenten skriver, hva agenten er koblet til, og hva agenten henter inn. De fleste programmene måler det første og ignorerer de to andre.
- Eksplosjonsradiusen er ikke med i modellen. Den finnes i ferdighetsfilen, MCP-konfigurasjonen, verktøyomfanget og legitimasjonen agenten kjører under. En ren modellering og en agent med overprivilegier kan sameksistere komfortabelt.
- Ni AI-risikomålinger, hver av dem et tall snarere enn et adjektiv. Ikke-godkjente AI-ressurser, umiddelbare injeksjonsbaner som når en verktøyvask, hemmeligheter i
.mcp/servers.json, agenttilførte avhengigheter flagget før en signatur fantes. - Hvis du ikke kan produsere tallet dette kvartalet, er ikke metrikken problemet. Inventaret er det. Start med tre tellinger, ikke et program.
Hva betyr egentlig AI-risiko når det er du som leverer programvaren?
Spør ti personer hva AI-risiko betyr, og du får ti svar. Modellskjevhet. Hallusinasjoner. Datalekkasje. Regulatorisk eksponering. Jobbforskyvning. Alt reelt, alt verdt oppmerksomhet, og ingen av dem kan holdes ansvarlige for av et sikkerhetsteam på en tirsdag ettermiddag.
Det finnes en smalere versjon av spørsmålet som et sikkerhetsteam faktisk kan eie: hvilken AI kjører i programvaren vi bygger, hva den kan nå, og hva skjer når noen manipulerer den. Den versjonen har et svar, og svaret finnes i arkivene dine og pipelines snarere enn i et policydokument.
Dette er den versjonen av AI-risiko dette innlegget handler om. Ikke fordi styringsspørsmålene ikke betyr noe, men fordi styringsspørsmålene ikke kan besvares før dette er tilfelle. Et rammeverk ber deg om å inventarisere AI-systemene dine. Det forteller deg ikke at inventaret ligger i en .mcp/servers.json fil som ingen har åpnet siden den ble committed.
Hvorfor måler de fleste AI-risikoprogrammer feil ting?
Tre feilmønstre, og de fleste organisasjoner bruker minst to av dem.
- Måling av adopsjon i stedet for eksponering. «72 % av utviklerne våre bruker AI-verktøy» er en produktivitetsmåling med et sikkerhetsmerke. Den forteller deg ingenting om hva disse verktøyene kan oppnå.
- Å måle modellen i stedet for systemet. Å sette et endepunkt i «red teaming» svarer på om en modell kan overtales til å si noe den ikke burde si. Det svarer ikke på hva som skjer videre, fordi eksplosjonsradiusen ligger i verktøyomfanget, legitimasjonen agenten kjører under og konfigurasjonsfilene som definerer begge deler. En ren modellenvaluering og en agent med sterkt overprivilegier sameksisterer komfortabelt.
- Å måle det som er lett å telle. Antall publiserte AI-policyer. Antall ansatte som har fullført AI-opplæring. Disse tallene går opp pålitelig og korrelerer med ingenting.
Ocuco NIST AI Risk Management Framework er eksplisitt at måling er en av dens fire kjernefunksjoner, sammen med styring, kartlegging og administrasjon. Rammeverket er bevisst resultatbasert snarere enn forskrivende, noe som er riktig for en standard og lite nyttig på en tirsdag. Du må fortsatt bestemme hva du skal telle.
Hvilke AI-risikomålinger forteller deg faktisk noe?
Ni målinger. Hver av dem er et tall, hver av dem endres når eksponeringen din endres, og hver av dem kan produseres fra kode i stedet for fra en undersøkelse.
| Metric | Hvorfor det betyr noe | Hvor tallet kommer fra |
|---|---|---|
| 01Totalt antall oppdagede AI-ressurser, og endringen siden forrige måned | Du kan ikke rapportere om AI-risiko du aldri har telt med. Trenden er viktigere enn det absolutte tallet | Kontinuerlig oppdagelse av modeller, rammeverk, datasett, inferensendepunkter, agenter, MCP-servere, ferdigheter og AI-kodingsverktøy |
| 02Ikke-godkjente AI-ressurser som prosentandel av totalen | Dette er din skygge-AI-rate. Det er den mest siterte AI-risikomålingen for et styre. | Godkjenningsstatus spores per aktivum mot policyen din |
| 03AI-ressurser uten navngitt eier | En eiendel ingen eier er en eiendel ingen vil reparere. Vanligvis det styggeste tallet i settet. | Eierskap sporet mot eiendelen |
| 04Raske injeksjonsbaner som når en verktøyvask | Upålitelig inndata som når en systemledetekst betyr bare noe hvis noe farlig befinner seg i den andre enden | AI-risikodeteksjon tilordnet til OWASP Topp 10 for LLM-applikasjoner |
| 05MCP-servere i bruk, og hvor mange som inneholder funn | MCP-konfigurasjonen er der agenten tar imot ordrene sine. Det er også der legitimasjon hoper seg opp | MCP-serverkonfigurasjon analysert som en sikkerhetsartefakt |
| 06Hemmeligheter funnet i AI-konfigurasjonsfiler | Forskning i 2026 fant over 24 000 hemmeligheter i MCP-konfigurasjonsfiler på den offentlige GitHub, hvorav mer enn 2,000 fortsatt er gyldige. | Hemmelighetsoppdagelse på tvers av kode, konfigurasjoner, containere og pipelines |
| 07Agenttillagte avhengigheter flagget før en offentlig signatur eksisterte | Agenter henter pakker raskt, og navnet modellen din oppfant er en farmbar angrepsflate | Tidlig advarsel om skadelig programvare, bevisdeteksjon etterfulgt av AI-validering |
| 08Andel av AI-funn som er tilgjengelige og i aktivt utviklet kode | Skiller etterslepet du aldri vil fjerne fra arbeidet som endrer eksponeringen din | AI-prioriteringstrakten |
| 09Prosentandel av agentforfattere pull requests slått sammen med en menneskelig godkjenning | Styringsmålingen en regulator vil be om, og den ingen sporer | Pull request analyse og godkjenningsporter |
Hvis du bare tar én, ta målestokk 02. Forholdet mellom ikke-godkjente og totale AI-ressurser er antallet som overlever oversettelsen fra et sikkerhetsteam til en revisjon. committee, og den beveger seg når du faktisk gjør noe.
Hva må en agentisk AI-strategi dekke?
Tre lag. Feilen nesten alle gjør er å starte med det første og stoppe der.
- Lag én: hva agenten skriver. Generert kode har de samme sårbarhetsklassene som menneskelig kode, og forskning som går tilbake til 2022 har konsekvent funnet at en betydelig andel av AI-genererte programmer inneholder sikkerhetsfeil. Dette laget er det mest kjente, og det er nettopp derfor det absorberer all oppmerksomheten.
- Lag to: hva agenten er koblet til Ferdighetsfiler, regelfiler, MCP-serverkonfigurasjoner, verktøyomfang, legitimasjonen agenten kjører under. Dette er laget som bestemmer hvor langt et vellykket angrep beveger seg, og det er usynlig for alt som tester modellen gjennom endepunktet. GJÆR ATLAS katalogiserer dette grunnlaget direkte: casestudien Rules File Backdoor, AML.CS0041, beskriver tegn med nullbredde i en regelfil som gjør dokumentasjon om til instruksjoner som en agent følger i stillhet. En anmelder som leser pull request ser ingenting.
- Lag tre: hva agenten trekker inn. Avhengigheter, modeller, datasett, eksterne verktøy. Forskning presentert på USENIX Security i 2025 genererte 2.23 millioner kodeeksempler på tvers av 16 modeller og fant at 19.7 % av anbefalte pakker ikke eksisterte, noe som produserte mer enn 205 000 unike hallusinerte navn. Angripere trenger ikke lenger å kompromittere en vedlikeholder. De registrerer navnet agenten din oppfant og venter.
En agentisk AI-strategi som kun dekker lag én, produserer en ren rapport og en uendret AI-risikoprofil. OWASP Topp 10 for LLM-applikasjoner gjenspeiler dette i sin egen struktur: overdreven handlefrihet står øverst på listen førcisfordi det er et ledningsproblem, ikke et modellproblem.
Hvordan implementerer du dette uten å forsinke agentene?
Instinktet er å porte alt. Det mislykkes fordi hele poenget med agenten er gjennomstrømning, og en kontroll som halverer gjennomstrømningen fjernes innen en fjerdedel.
Tre implementeringsprinsipper som holder mål:
- Mål kontinuerlig, gate selektivt. Alle ni AI-risikomålinger kan samles inn på hver skanning uten å blokkere noe. Reserver harde porter for det lille settet der feilen ikke kan gjenopprettes: en ondsinnet avhengighet, en levende hemmelighet, en ikke-godkjent modell som håndterer regulerte data.
- Plasser sikkerhet der agenten allerede er. En agent koblet til via MCP kaller sikkerhetsplattformen mens den genererer, skanner det den nettopp skrev, og itererer på rettelsene til koden når terskelverdiene dine. Ingen mennesker i løkken på det stadiet, og ingenting å installere der agenten kjører. Det er det eneste intervensjonspunktet som skalerer med agentens gjennomstrømning i stedet for mot den.
- Hold mennesket ved pull request. Alt som når produksjonskoden, godkjennes av en person. Dette er ikke forsiktighet, det er uansett den designposisjonen EUs AI-lov presser deg mot, og det er mye billigere å bygge inn nå enn å ettermontere under revisjonspress. Det er også målestokk 09, og det er derfor den målestokken er verdt å spore fra dag én.
Raden som ikke er tildelt i de fleste organisasjoner er den andre. Konfigurasjonsfiler faller mellom applikasjonssikkerhet, som behandler dem som infrastruktur, og plattformteknikk, som behandler dem som dokumentasjon. Det er i dette gapet de interessante angrepene havner.
Hvordan begynner du å måle AI-risiko dette kvartalet?
Ikke bygg hele programmet. Lag tre tall. Tell AI-ressursene dine. Tell hvor mange av dem ingen har godkjent. Tell hvor mange hemmeligheter som ligger i AI-konfigurasjonsfiler. Disse tre får plass på ett lysbilde; de er alle forsvarlige, og de vil være verre enn den som ba om dem forventer.
Så velg den som er verst og fiks den før neste styremøte. Det er et fungerende AI-risikoprogram. Alt annet er utdyping.
Organisasjonene som vil slite med AI-risiko i 2027 er ikke de som handlet raskt. Det er de som brukte 2026 på å skrive AI-policyer og aldri telte noe. En policy ingen kan måle seg mot er et dokument. AI-risikomålinger er det som gjør den til en kontroll.
Se dine egne tall. Koble til et arkiv, så returnerer Xygeni AI-beholdningen din, de ikke-godkjente eiendelene, risikoene som er kartlagt til rammeverkene revisorene dine bruker, og en AI-BOM du kan eksportere. Start gratis or bestill en demo.
FAQ
Hva er forskjellen mellom AI-risiko og AI-sikkerhet?
AI-sikkerhet handler stort sett om hva en modell gjør: om den oppfører seg som tiltenkt, om resultatene er skadelige, om den kan manipuleres til noe den bør avvise. AI-risiko, i en sikkerhetskontekst, handler om hva et kompromittert eller feilaktig AI-system kan nå inn i miljøet ditt. De to overlapper hverandre, men de eies av forskjellige team og måles med forskjellige instrumenter. Et sikkerhetsteam kan handle ut fra det andre i dag.
Hvor mange risikomålinger for AI bør vi rapportere til styret?
Tre til fem. Et brett kan ikke handle på ni tall, og en kortstokk med ni har en tendens til å skjule det som betyr noe. Rapporter det totale antallet AI-ressurser, den ikke-godkjente prosentandelen og én eksponeringsmåling, for eksempel oppnåelige AI-funn i aktiv utvikling. Ta vare på resten til den operative gjennomgangen.
Trenger vi en AI-BOM hvis ingen regulering krever det ennå?
Ingen forskrifter pålegger en AI-BOM for øyeblikket, og det er nettopp derfor det er billig å generere en akkurat nå og dyrt senere. Det finnes to maskinlesbare formater i dag, og en revisor vil godta begge. Verdien er ikke samsvar; det er at produksjonen av filen tvinger deg til å ha beholdningen, og beholdningen er det alle AI-risikomålinger er avhengige av.
Utviklerne våre bruker AI-verktøy vi aldri har godkjent. Hvor skal vi begynne?
Tell før du overvåker. Å kunngjøre en policy mot verktøy du ikke kan se, driver bruken i det skjulte og ødelegger synligheten du trenger. Kjør en discovery-prosess først, publiser antallet internt uten kreditering, og bruk det til å bli enige om en godkjent liste som gjenspeiler hva folk faktisk trenger. Håndheving er mye bedre når den følger bevis enn når den går forut for dem.
