Følg os

Tanke ledere

Det hemmelighedsløse imperativ: Hvorfor traditionelle sikkerhedsmodeller bryder sammen, når AI-agenter rører ved kode

mm

I april 2023, Samsung opdagede, at deres ingeniører havde lækket følsomme oplysninger til ChatGPT... Men det var et uheld. Forestil dig nu, hvis disse kodelagre havde indeholdt bevidst plantede instruktioner, usynlige for mennesker, men behandlet af AI, designet til at udtrække ikke kun kode, men alle API-nøgler, databaseoplysninger og servicetokens, som AI'en kunne få adgang til. Dette er ikke hypotetisk. Sikkerhedsforskere har allerede vist Disse "usynlige instruktions"-angreb virker. Spørgsmålet er ikke, om det vil ske, men hvornår.

Grænsen der ikke længere eksisterer

I årtier har vi bygget sikkerhed på en grundlæggende antagelse: kode er kode, og data er data. SQL-injektion lærte os at parametrisere forespørgsler. Cross-site scripting lærte os at undslippe output. Vi lærte at bygge mure mellem, hvad programmer gør, og hvad brugerne indtaster.

Med AI-agenter er den grænse forduftet.

I modsætning til deterministisk software, der følger forudsigelige stier, er store sprogmodeller probabilistiske sorte bokse, der ikke kan skelne mellem legitime udviklerinstruktioner og ondsindede input. Når en angriber sender en prompt til en AI-kodningsassistent, leverer de ikke bare data. De omprogrammerer i bund og grund applikationen undervejs. Inputtet er blevet selve programmet.

Dette repræsenterer et fundamentalt brud med alt, hvad vi ved om applikationssikkerhed. Traditionelle syntaksbaserede firewalls, der leder efter ondsindede mønstre som DROP TABLE eller tags, fail completely against natural language attacks. Researchers have demonstrated “semantic substitution” techniques where replacing “API keys” with “apples” in prompts allows attackers to bypass filters entirely. How do you firewall intent when it’s disguised as harmless conversation?

Nul-klik-virkeligheden, som ingen diskuterer

Her er hvad de fleste sikkerhedsteams ikke forstår: prompt injection kræver ikke, at en bruger skriver noget. Disse er ofte zero-click exploits. En AI-agent, der blot scanner et kodelager for en rutineopgave, gennemgår en pull request eller læser API-dokumentation, kan udløse et angreb uden nogen menneskelig interaktion.

Overvej dette scenarie, baseret på teknikker, som forskere allerede har bevistEn ondsindet aktør integrerer usynlige instruktioner i HTML-kommentarer i dokumentationen til et populært open source-bibliotek. Enhver AI-assistent, der analyserer denne kode, uanset om det er GitHub Copilot, Amazon CodeWhisperer eller en hvilken som helst anden kodningsassistent for virksomheder, bliver en potentiel indsamling af legitimationsoplysninger. Ét kompromitteret bibliotek kan betyde tusindvis af eksponerede udviklingsmiljøer.

Faren er ikke selve LLM'en; det er den handlefrihed, vi giver den. I det øjeblik vi integrerede disse modeller med værktøjer og API'er, så de kunne hente data, udføre kode og få adgang til hemmeligheder, forvandlede vi hjælpsomme assistenter til perfekte angrebsvektorer. Risikoen skalerer ikke med modellens intelligens; den skalerer med dens forbindelse.

Hvorfor den nuværende tilgang er dømt til at mislykkes

Branchen er i øjeblikket besat af at "tilpasse" modeller og bygge bedre firewalls til prompts. OpenAI tilføjer flere rækværk. Anthropic fokuserer på konstitutionel AI. Alle prøver at lave modeller, der ikke kan narres.

Dette er en tabt kamp.

Hvis en AI er smart nok til at være nyttig, er den smart nok til at blive bedraget. Vi falder i det, jeg kalder "saneringsfælden": Vi antager, at bedre inputfiltrering vil redde os. Men angreb kan skjules som usynlig tekst i HTML-kommentarer, begraves dybt i dokumentation eller kodes på måder, vi endnu ikke har forestillet os. Man kan ikke sanere det, man ikke kan forstå kontekstuelt, og kontekst er præcis det, der gør LLM'er kraftfulde.

Industrien er nødt til at acceptere en barsk sandhed: hurtig injektion vil lykkes. Spørgsmålet er, hvad der sker, når det sker.

Det arkitektoniske skift, vi har brug for

Vi er i øjeblikket i en "patchfase", hvor vi desperat tilføjer inputfiltre og valideringsregler. Men ligesom vi til sidst lærte, at det at forhindre SQL-injektion krævede parametriserede forespørgsler, ikke bedre streng-escape, har vi brug for en arkitektonisk løsning til AI-sikkerhed.

Svaret ligger i et princip, der lyder simpelt, men kræver, at vi gentænker, hvordan vi bygger systemer: AI-agenter bør aldrig besidde de hemmeligheder, de bruger.

Det handler ikke om bedre administration af legitimationsoplysninger eller forbedrede løsninger til opbevaring af databaser. Det handler om at genkende AI-agenter som unikke, verificerbare identiteter i stedet for brugere, der har brug for adgangskoder. Når en AI-agent skal have adgang til en beskyttet ressource, bør den:

  1. Godkend ved hjælp af dens verificerbare identitet (ikke en gemt hemmelighed)

  2. Modtag just-in-time-legitimationsoplysninger, der kun er gyldige for den specifikke opgave

  3. Få disse legitimationsoplysninger til at udløbe automatisk inden for sekunder eller minutter

  4. Gem aldrig eller "se" langvarige hemmeligheder

Flere tilgange er ved at dukke op. AWS IAM-roller for servicekonti, Googles arbejdsbyrdeidentitet, HashiCorp Vaults dynamiske hemmeligheder, og specialbyggede løsninger som Akeyless' Zero Trust Provisioning peger alle mod denne hemmelighedsløse fremtid. Implementeringsdetaljerne varierer, men princippet forbliver: hvis AI'en ikke har nogen hemmeligheder at stjæle, bliver prompt injection en betydeligt mindre trussel.

Udviklingsmiljøet i 2027

Inden for tre år vil .env-filen være død i AI-forstærket udvikling. Langlivede API-nøgler, der sidder i miljøvariabler, vil blive set, når vi nu ser adgangskoder i almindelig tekst: en pinlig levn fra en mere naiv tid.

I stedet vil alle AI-agenter operere under streng privilegieadskillelse. Skrivebeskyttet adgang som standard. Handlings-hvidlistning som standard. Sandbox-eksekveringsmiljøer som et compliance-krav. Vi vil holde op med at forsøge at kontrollere, hvad AI'en tænker, og fokusere udelukkende på at kontrollere, hvad den kan gøre.

Dette er ikke blot en teknisk udvikling; det er et fundamentalt skift i tillidsmodeller. Vi bevæger os fra "stol på, men verificer" til "stol aldrig på, verificer altid og antag kompromis". Princippet om mindste privilegier, som længe er blevet prædiket, men sjældent praktiseret, bliver ufravigeligt, når din juniorudvikler er en AI, der behandler tusindvis af potentielt ondsindede input dagligt.

Det valg vi står over for

Integrationen af ​​AI i softwareudvikling er uundgåelig og i høj grad gavnlig. GitHub rapporterer, at udviklere, der bruger Copilot, udfører opgaver 55% hurtigereProduktivitetsforbedringen er reel, og ingen organisation, der ønsker at forblive konkurrencedygtig, kan ignorere den.

Men vi står ved en skillevej. Vi kan fortsætte ad den nuværende vej ved at tilføje flere rækværk, bygge bedre filtre og håbe på at kunne lave AI-agenter, der ikke kan narres. Eller vi kan anerkende truslens grundlæggende natur og genopbygge vores sikkerhedsarkitektur i overensstemmelse hermed.

Hændelsen med Samsung var et varselsskud. Det næste brud vil ikke være et uheld, og det vil ikke være begrænset til én virksomhed. Efterhånden som AI-agenter får flere muligheder og adgang til flere systemer, vokser den potentielle effekt eksponentielt.

Spørgsmålet for enhver CISO, enhver ingeniørleder og enhver udvikler er simpelt: Når prompt injection lykkes i dit miljø (og det vil det), hvad vil angriberen så finde? Vil de opdage en skattekiste af langlivede legitimationsoplysninger, eller vil de finde en AI-agent, der, på trods af at være kompromitteret, ikke har nogen hemmeligheder at stjæle?

Det valg, vi træffer nu, vil afgøre, om AI bliver den største accelerator inden for softwareudvikling eller den største sårbarhed, vi nogensinde har skabt. Teknologien til at bygge sikre, hemmelighedsløse AI-systemer findes i dag. Spørgsmålet er, om vi vil implementere den, før angribere tvinger os til det.

OWASP har allerede identificeret hurtig injektion som den største risiko i deres top 10 for LLM-ansøgninger. NIST udvikler vejledning på zero trust-arkitekturer. Frameworks findes. Det eneste spørgsmål er implementeringshastighed versus angrebsudvikling.

Biografi: Refael Angel er medstifter og teknisk direktør for Nøglefri, hvor han udviklede virksomhedens patenterede Zero-Trust-krypteringsteknologi. Refael er en erfaren softwareingeniør med dybdegående ekspertise inden for kryptografi og cloudsikkerhed og har tidligere arbejdet som Senior Software Engineer på Intuits R&D-center i Israel, hvor han byggede systemer til håndtering af krypteringsnøgler i offentlige cloud-miljøer og designede maskingodkendelsestjenester. Han har en B.Sc. i datalogi fra Jerusalem College of Technology, som han fik i en alder af 19 år.

Refael Angel er medstifter og teknisk direktør for Nøglefri, hvor han udviklede virksomhedens patenterede Zero-Trust-krypteringsteknologi. Refael er en erfaren softwareingeniør med dybdegående ekspertise inden for kryptografi og cloudsikkerhed og har tidligere arbejdet som Senior Software Engineer på Intuits R&D-center i Israel, hvor han byggede systemer til håndtering af krypteringsnøgler i offentlige cloud-miljøer og designede maskingodkendelsestjenester. Han har en B.Sc. i datalogi fra Jerusalem College of Technology, som han fik i en alder af 19 år.