Det hemmelighetsløse imperativet: Hvorfor tradisjonelle sikkerhetsmodeller bryter når AI-agenter berører kode

I april 2023,  Samsung oppdaget at deres ingeniører hadde lekket følsom informasjon til ChatGPT. Men det var utilsiktet. La oss nå forestille oss at disse kode-repositoryene hadde inneholdt bevisst plantet instruksjoner, usynlige for mennesker, men prosessert av AI, designet for å trekke ut ikke bare kode, men hver API-nøkkel, database-legitimasjon og tjenestetoken AI-en kunne få tilgang til. Dette er ikke hypotetisk.  Sikkerhetsforskere har allerede demonstrert at disse “usynlige instruksjons” angrepene fungerer. Spørsmålet er ikke om dette vil skje, men når.

Grensen som ikke lenger eksisterer

I årevis har vi bygget sikkerhet på en grunnleggende antakelse: kode er kode, og data er data. SQL-injeksjon lærte oss å parameterisere spørringer. Cross-site scripting lærte oss å escape utdata. Vi lærte å bygge vegger mellom hva programmer gjør og hva brukere skriver inn.

Med AI-agenter har denne grensen forsvunnet.

I motsetning til deterministisk programvare som følger forutsigbare stier, er store språkmodeller probabilistiske svarte bokser som ikke kan skille mellom legitime utviklerinstruksjoner og malisøse inndata. Når en angriper gir en prompt til en AI-kodingassistent, gir de ikke bare data. De representerer i praksis omprogrammering av applikasjonen på fly.

Dette representerer en fundamental brudd med alt vi vet om applikasjonssikkerhet. Tradisjonelle syntax-baserte brannmurer, som søker etter malisøse mønster som DROP TABLE eller <script> -merker, feiler fullstendig mot naturlige språkangrep. Forskere har demonstrert “semantisk substitusjon” -teknikker hvor erstattelse av “API-nøkler” med “epler” i prompter tillater angripere å omgå filtre fullstendig. Hvordan kan du brannmur-intent når det er forkledd som harmløs samtale?

Den null-klikk-realiteten ingen diskuterer

Her er hva de fleste sikkerhetslag ikke forstår: prompt-injeksjon krever ikke at en bruker skriver noe. Disse er ofte null-klikk-eksploateringer. En AI-agent som bare scannrer en kode-repository for en rutineoppgave, gjennomgår en pull-forespørsel eller leser API-dokumentasjon, kan utløse et angrep uten noen menneskelig interaksjon.

Vurdér denne scenariet, basert på teknikker forskere allerede har bevist: En malisøs aktør innsetter usynlige instruksjoner i HTML-kommentarer innen en populær åpen kildekode-biblioteks dokumentasjon. Hver AI-assistent som analyserer denne koden, enten GitHub Copilot, Amazon CodeWhisperer eller noen annen bedriftskodingassistent, blir et potensielt kreditor-høster. Én kompromittert bibliotek kunne bety tusenvis av eksponerte utviklingsmiljøer.

Faren er ikke LLM selv; det er agenten vi gir den. Øyeblikket vi integrerte disse modellene med verktøy og API-er, lot dem hente data, kjøre kode og få tilgang til hemmeligheter, transformerte vi nyttige assistenter til perfekte angrepsvektorer. Risikoen skalerer ikke med modellens intelligens; den skalerer med dens tilkobling.

Hvorfor den nåværende tilnærmingen er dømt

Bransjen er for tiden besatt av å “justere” modeller og bygge bedre prompt-brannmurer. OpenAI legger til flere retningslinjer. Anthropic fokuserer på konstitusjonell AI. Alle prøver å lage modeller som ikke kan narres.

Dette er en tapende kamp.

Hvis en AI er smart nok til å være nyttig, er den smart nok til å bli lurt. Vi faller i det jeg kaller “saniteringsfellen”: å anta at bedre inndata-filtrering vil redde oss. Men angrep kan skjules som usynlig tekst i HTML-kommentarer, begravd dypt i dokumentasjon eller kodet på måter vi ikke har forestilt oss ennå. Du kan ikke sanere hva du ikke kontekstuelt forstår, og kontekst er nettopp hva gjør LLM-er kraftfulle.

Bransjen må akseptere en hard sannhet: prompt-injeksjon vil lykkes. Spørsmålet er hva skjer når det gjør.

Den arkitektoniske skiftet vi trenger

Vi er for tiden i en “patch-fase”, desperat legger til inndata-filtre og valideringsregler. Men likevel som vi til slutt lærte at å forhindre SQL-injeksjon krevde parameteriserte spørringer, ikke bedre streng-escapning, trenger vi en arkitektonisk løsning for AI-sikkerhet.

Svaret ligger i en prinsipp som lyder enkelt, men krever omtenkning av hvordan vi bygger systemer: AI-agenter bør aldri besitte hemmelighetene de bruker.

Dette handler ikke om bedre kreditor-håndtering eller forbedret vault-løsninger. Det handler om å anerkjenne AI-agenter som unike, verifiserbare identiteter i stedet for brukere som trenger passord. Når en AI-agent trenger å få tilgang til en beskyttet ressurs, bør den:

1. Autentisere ved hjelp av sin verifiserbare identitet (ikke en lagret hemmelighet)

2. Motta kun-i- tid-creditorer gyldige bare for den spesifikke oppgaven

3. Ha disse creditorer utløpe automatisk innen sekunder eller minutter

4. Aldri lagre eller “se” langvarige hemmeligheter

Flere tilnærminger er i ferd med å dukke opp. AWS IAM-roller for tjenkekontoer, Googles Workload Identity, HashiCorp Vault-dynamiske hemmeligheter, og spesialbygde løsninger som Akeyless Zero Trust Provisioning, peker alle mot denne hemmelighetsløse fremtiden. Implementasjonsdetaljene varierer, men prinsippet forblir: hvis AI-en ikke har noen hemmeligheter å stjele, blir prompt-injeksjon en betydelig mindre trussel.

Utviklingsmiljøet i 2027

Innen tre år vil .env-filen være død i AI-forsterket utvikling. Langvarige API-nøkler som sitter i miljøvariabler, vil bli sett på som vi nå ser på passord i klartekst: en pinlig levning fra en mer naiv tid.

I stedet vil hver AI-agent operere under streng privilegie-separasjon. Les-tilgang som standard. Handling-whitelisting som standard. Sandboks-utførelsemiljøer som en krav til overholdelse. Vi vil slutte å prøve å kontrollere hva AI-en tenker og fokusere fullstendig på å kontrollere hva den kan gjøre.

Dette er ikke bare en teknisk evolusjon; det er en fundamental skift i tillitsmodeller. Vi går fra “tillit, men verifiser” til “aldri tillit, alltid verifiser og anta kompromiss”. Prinsippet om minst privilegie, lenge forkynnet men sjelden praktisert, blir uforhandelbar når din junior-utvikler er en AI som prosesserer tusenvis av potensielt malisøse inndata daglig.

Valget vi står overfor

Integreringen av AI i programvareutvikling er uunngåelig og i stor grad gunstig. GitHub rapporterer at utviklere som bruker Copilot fullfører oppgaver 55% raskere. Produktivitetsgevinstene er reelle, og ingen organisasjon som ønsker å forbli konkurransedyktig, kan ignorere dem.

Men vi står på et veiskille. Vi kan fortsette ned den nåværende veien ved å legge til flere retningslinjer, bygge bedre filtre, håpe vi kan lage AI-agenter som ikke kan narres. Eller vi kan anerkjenne den grunnleggende naturen til trusselen og bygge om vår sikkerhetsarkitektur i henhold til.

Samsung-episoden var en advarselsskudd. Det neste bruddet vil ikke være utilsiktet, og det vil ikke være begrenset til ett selskap. Ettersom AI-agenter får mer kapasitet og får tilgang til flere systemer, vokser potensiell innvirkning eksponentielt.

Spørsmålet for hver CISO, hver teknisk leder og hver utvikler er enkelt: Når prompt-injeksjon lykkes i din omgivelse (og det vil), hva vil angriperen finne? Vil de oppdage en skattkiste av langvarige kreditorer, eller vil de finne en AI-agent som, til tross for å være kompromittert, ikke har noen hemmeligheter å stjele?

Valget vi gjør nå, vil bestemme om AI blir den største akseleratoren av programvareutvikling eller den største sårbarheten vi noensinne har skapt. Teknologien til å bygge sikre, hemmelighetsløse AI-systemer eksisterer i dag. Spørsmålet er om vi vil implementere det før angripere tvinger oss til.

OWASP har allerede identifisert prompt-injeksjon som #1-risiko i deres Top 10 for LLM-applikasjoner. NIST er i ferd med å utvikle retningslinjer om null-tillit-arkitekturer. Rammerne eksisterer. Det eneste spørsmålet er implementeringshastighet versus angrepsutvikling.