Den hemlighetslösa imperativet: Varför traditionella säkerhetsmodeller går sönder 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 ett olyckshändelse. Tänk nu om dessa kodrepositoryer hade innehållit avsiktligt planterade instruktioner, osynliga för människor men bearbetade av AI, utformade för att extrahera inte bara kod utan också alla API-nycklar, databasautentiseringsuppgifter och tjänsttoken som AI kunde komma åt. Detta är inte hypotetiskt. Säkerhetsforskare har redan visat att dessa “osynliga instruktionsattacker” 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 flydda 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, matar de inte bara in 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 -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 man brandvägga 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 nollklicks-exploater. En AI-agent som bara scannar en kodrepository för en rutinuppgift, granskar en pull-förfrågan eller läser API-dokumentation kan utlösa en attack utan någon mänsklig interaktion.

Tänk på följande scenario, 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 koden, antingen GitHub Copilot, Amazon CodeWhisperer eller någon annan företagskodhjälpare, blir en potentiell autentiseringsuppgiftsinsamlare. Ett enda komprometterat bibliotek kunde betyda tusentals utsatta utvecklingsmiljöer.

Faran är inte LLM i sig; det är den agent som vi ger det. Ö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, begraven djupt i dokumentationen eller kodad på sätt som vi inte har tänkt på ännu. Du kan inte sanera vad du inte kan kontextuellt förstå, 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 den gör det.

Den arkitektoniska förändringen vi behöver

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

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

Detta handlar inte om bättre autentiseringshantering eller förbättrade valv. Det handlar om att känna igen 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. Få just-in-time-autentiseringsuppgifter som är giltiga endast för den specifika uppgiften

3. Få dessa autentiseringsuppgifter att upphöra automatiskt inom sekunder eller minuter

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

Flera tillvägagångssätt är på väg. 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:n inte har några 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ångvariga 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.

I stället kommer varje AI-agent att operera under strikt privilegieuppdelning. Läsförbehör som standard. Åtgärdsvitlistning som standard. Sandlådekörningsmiljöer som en krav för efterlevnad. Vi kommer att sluta försöka kontrollera vad AI:n tänker 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 “lita men verifiera” till “aldrig lita, alltid verifiera och anta kompromettering”. Principen om minst privilegium, länge predikad men sällan praktiserad, 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 intrå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ångvariga autentiseringsuppgifter, 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 avgöra 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 den innan angripare tvingar oss till det.

OWASP har redan identifierat promptinjektion som den största risken i sin topp 10 för stora språkmodellapplikationer. NIST utvecklar riktlinjer för nolltillitsarkitekturer. Ramverken finns. Den enda frågan är implementeringshastighet kontra attackutveckling.

Bio: Refael Angel är medgrundare och CTO på Akeyless, där han utvecklade företagets patenterade Zero-Trust-kryptoteknologi. En erfaren programvaruutvecklare med djup expertis inom kryptografi och molnsäkerhet, Refael tjänstgjorde tidigare som senior programvaruutvecklare på Intuits FoU-center i Israel, där han byggde system för att hantera krypteringsnycklar i offentliga molnmiljöer och utformade maskinautentiseringstjänster. Han har en kandidatexamen i datavetenskap från Jerusalem College of Technology, som han avlade vid 19 års ålder.