Den hemliga imperativet: Varför traditionella säkerhetsmodeller bryter när AI-agenter kommer i kontakt med kod

I april 2023 upptäckte  Samsung att deras ingenjörer hade läckt känslig information till ChatGPT. Men det var oavsiktligt. Tänk nu om dessa kodrepositoryer hade innehållit medvetet planterade instruktioner, osynliga för människor men bearbetade av AI, utformade för att extrahera inte bara kod utan varje API-nyckel, databasbehörighet och tjänsttoken som AI kunde komma åt. Detta är inte hypotetiskt. Säkerhetsforskare har redan visat att dessa “osynliga instruktions” attacker fungerar. Frågan är inte om detta kommer att hända, utan när.

Gränsen som inte längre existerar

Under decennier har vi byggt säkerhet på en grundläggande antagande: kod är kod, och data är data. SQL-injektion lärde oss att parameterisera frågor. Cross-site scripting lärde oss att fly från utdata. Vi lärde oss att bygga murar mellan vad program gör och vad användare matar in.

Med AI-agenter har den gränsen försvunnit.

Till skillnad från deterministisk programvara som följer förutsägbara vägar är stora språkmodeller probabilistiska svarta lådor som inte kan skilja mellan legitima utvecklarinstruktioner och skadliga indata. När en angripare matar en prompt till en AI-kodhjälpare, tillhandahåller de inte bara data. De omprogrammerar i princip applikationen på flyget. Indata har blivit programmet i sig.

Detta representerar en grundläggande brytning från allt vi vet om applikationssäkerhet. Traditionella syntaxbaserade brandväggar, som letar efter skadliga mönster som DROP TABLE eller <script> taggar, misslyckas helt mot naturliga språkattacker. Forskare har visat “semantisk substitution” tekniker där ersättning av “API-nycklar” med “äpplen” i prompter tillåter angripare att kringgå filter helt. Hur kan du brandvägg avsikt när den är maskerad som ofarlig konversation?

Den nollklicksverklighet som ingen diskuterar

Här är vad de flesta säkerhetsteam inte förstår: promptinjektion kräver inte att en användare skriver något. Dessa är ofta nollklicksexploater. En AI-agent som enbart skannar en kodrepository för en rutinuppgift, granskar en pull-begäran eller läser API-dokumentation kan utlösa en attack utan någon mänsklig interaktion.

Tänk på det här scenariot, baserat på tekniker som forskare redan har bevisat: En skadlig aktör inbäddar osynliga instruktioner i HTML-kommentarer inom en populär öppen källkods biblioteks dokumentation. Varje AI-hjälpare som analyserar den här koden, antingen GitHub Copilot, Amazon CodeWhisperer eller någon annan företagskodhjälpare, blir en potentiell kreditharvester. Ett enda komprometterat bibliotek kunde betyda tusentals utsatta utvecklingsmiljöer.

Faran är inte LLM i sig; det är den agent vi ger den. Ögonblicket vi integrerade dessa modeller med verktyg och API:er, lät dem hämta data, köra kod och komma åt hemligheter, förvandlade vi hjälpsamma assistenter till perfekta attackvektorer. Risken skalar inte med modellens intelligens; den skalar med dess anslutning.

Varför den nuvarande metoden är dömd

Branschen är för närvarande besatt av att “justera” modeller och bygga bättre promptbrandväggar. OpenAI lägger till fler skydd. Anthropic fokuserar på konstitutionell AI. Alla försöker skapa modeller som inte kan luras.

Detta är en förlorad strid.

Om en AI är tillräckligt smart för att vara användbar, är den tillräckligt smart för att bli bedragen. Vi faller i vad jag kallar “saneringsfällan”: antagandet att bättre indatafiltering kommer att rädda oss. Men attacker kan döljas som osynlig text i HTML-kommentarer, begravda djupt i dokumentation eller kodade på sätt vi inte har föreställt oss ännu. Du kan inte sanera vad du inte kan förstå kontextuellt, och kontext är exakt vad som gör LLM:er kraftfulla.

Branschen måste acceptera en hård sanning: promptinjektion kommer att lyckas. Frågan är vad som händer när det gör det.

Den arkitekturiska förändringen vi behöver

Vi är för närvarande i en “patchningsfas”, desperat lägger till indatafilter och valideringsregler. Men lika som vi till slut lärde oss att förhindra SQL-injektion krävde parameteriserade frågor, inte bättre strängflykt, behöver vi en arkitekturisk lösning för AI-säkerhet.

Svaret ligger i en princip som låter enkel men kräver omprövning av hur vi bygger system: AI-agenter bör aldrig besitta de hemligheter de använder.

Detta handlar inte om bättre behörighets hantering eller förbättrade valv lösningar. Det handlar om att erkänna AI-agenter som unika, verifierbara identiteter snarare än användare som behöver lösenord. När en AI-agent behöver komma åt en skyddad resurs, bör den:

1. Autentisera med sin verifierbara identitet (inte en lagrad hemlighet)

2. Ta emot just-in-time behörigheter som är giltiga endast för den specifika uppgiften

3. Ha dessa behörigheter utgå automatiskt inom sekunder eller minuter

4. Aldrig lagra eller ens “se” långlivade hemligheter

Flera tillvägagångssätt dyker upp. AWS IAM-roller för tjänstekonton, Googles Workload Identity, HashiCorps Vault dynamiska hemligheter, och specialbyggda lösningar som Akeyless Zero Trust Provisioning pekar alla mot denna hemlighetslösa framtid. Implementeringsdetaljerna varierar, men principen förblir: om AI har inga hemligheter att stjäla, blir promptinjektion en betydligt mindre fara.

Utvecklingsmiljön 2027

Inom tre år kommer .env-filen att vara död i AI-förstärkt utveckling. Långlivade API-nycklar som sitter i miljövariabler kommer att ses som vi nu ser lösenord i klartext: en pinsam relikt från en mer naiv tid.

Istället kommer varje AI-agent att fungera under strikt privilegie separation. Läsförbehör som standard. Åtgärds vitlistning som standard. Sandlådemiljöer som krav för efterlevnad. Vi kommer att sluta försöka kontrollera vad AI tror och fokusera helt på att kontrollera vad den kan göra.

Detta är inte bara en teknisk evolution; det är en grundläggande förändring av förtroendemodeller. Vi flyttar från “förtroende men verifiera” till “aldrig förtroende, alltid verifiera och anta kompromiss”. Principen om minsta privilegium, som länge predikats men sällan praktiserats, blir oeftergivlig när din juniorutvecklare är en AI som bearbetar tusentals potentiellt skadliga indata dagligen.

Valet vi står inför

Integreringen av AI i programvaruutveckling är oundviklig och till stor del gynnsam. GitHub rapporterar att utvecklare som använder Copilot slutför uppgifter 55% snabbare. Produktivitetsvinsterna är verkliga, och ingen organisation som vill förbli konkurrenskraftig kan ignorera dem.

Men vi står vid en vägskäl. Vi kan fortsätta på den nuvarande vägen genom att lägga till fler skydd, bygga bättre filter, hoppas att vi kan skapa AI-agenter som inte kan luras. Eller så kan vi erkänna den grundläggande naturen av hotet och bygga om vår säkerhetsarkitektur därefter.

Samsung-incidenten var ett varningsskott. Nästa dataintrång kommer inte att vara oavsiktligt, och det kommer inte att begränsas till ett företag. När AI-agenter får fler funktioner och kommer åt fler system, växer den potentiella påverkan exponentiellt.

Frågan för varje CISO, varje teknikledare och varje utvecklare är enkel: När promptinjektion lyckas i er miljö (och det kommer att göra), vad kommer angriparen att hitta? Kommer de att upptäcka en skattkista med långlivade behörigheter, eller kommer de att hitta en AI-agent som, trots att den är komprometterad, inte har några hemligheter att stjäla?

Valet vi gör nu kommer att bestämma om AI blir den största acceleratorn för programvaruutveckling eller den största sårbarheten vi någonsin skapat. Teknologin för att bygga säkra, hemlighetslösa AI-system finns idag. Frågan är om vi kommer att implementera det innan angripare tvingar oss att göra det.

OWASP har redan identifierat promptinjektion som #1 risk i deras Top 10 för LLM-applikationer. NIST utvecklar riktlinjer för nolltillitsarkitekturer. Ramverken finns. Den enda frågan är implementeringshastighet kontra attackutveckling.