Det Hemmelighedsløse Imperativ: Hvorfor Traditionelle Sikkerhedsmodeller Bryder Sammen, Når AI-Agenter Rører Kode

I april 2023 opdagede Samsung, at deres ingeniører havde lækket følsomme oplysninger til ChatGPT. Men det var et uheld. Forestil dig, hvis de kodebiblioteker, der indeholdt hemmelige instruktioner, usynlige for mennesker, men processeret af AI, var designet til at udtrække ikke kun kode, men også alle API-nøgler, database-legitimationsoplysninger og service-token, som AI’en kunne få adgang til. Dette er ikke hypotetisk. Sikkerhedsforskere har allerede demonstreret, at disse “usynlige instruktion”-angreb virker. Spørgsmålet er ikke, om dette 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 parameterisere forespørgsler. Cross-site scripting lærte os at undgå output. Vi lærte at bygge mure mellem, hvad programmer gør, og hvad brugere indtaster.

Med AI-agenter er denne grænse forsvundet.

I modsætning til deterministisk software, der følger forudsigelige veje, er store sprogmodeller probabilistiske sorte kasser, der ikke kan skelne mellem legitime udviklerinstruktioner og ondsindede input. Når en angriber giver en prompt til en AI-kodningsassistent, giver de ikke kun data. De genskriver i virkeligheden programmet på flyveskema.

Dette repræsenterer en grundlæggende brud med alt, vi ved om program-sikkerhed. Traditionelle syntaks-baserede brandvægge, der søger efter ondsindede mønstre som DROP TABLE eller -tags, fejler komplet mod naturlige sprogangreb. Forskere har demonstreret “semantisk substitution”-teknikker, hvor erstattelse af “API-nøgler” med “æbler” i prompts tillader angribere at omgå filtre helt. Hvordan kan man brandvægge intentioner, når de er forkledt som harmløs samtale?

Den Nul-Klik-Realitet, Ingen Diskuterer

Her er, hvad de fleste sikkerhedsteams ikke forstår: prompt-injektion kræver ikke, at en bruger skal skrive noget. Disse er ofte nul-klik-eksploitationer. En AI-agent, der blot scanner en kodebibliotek for en rutineopgave, gennemgår en pull-anmodning eller læser API-dokumentation, kan udløse et angreb uden nogen menneskelig interaktion.

Overvej dette scenario, baseret på teknikker, som forskere allerede har bevist: En ondsindet aktør indlejrer usynlige instruktioner i HTML-kommentarer inden for en populær open-source-biblioteks dokumentation. Hver AI-assistent, der analyserer denne kode, uanset om det er GitHub Copilot, Amazon CodeWhisperer eller en anden virksomheds kodningsassistent, bliver et potentielt credential-harvester. Et kompromitteret bibliotek kunne betyde tusindvis af eksponerede udviklingsmiljøer.

Faren er ikke LLM selv; det er den agenti, vi giver det. Øjeblikket, vi integrerede disse modeller med værktøjer og API’er, lod dem hente data, udføre kode og få adgang til hemmeligheder, forvandlede vi nyttige assistenter til perfekte angrebsvektorer. Risikoen skalerer ikke med modellens intelligens; den skalerer med dens tilslutning.

Hvorfor Den Nuværende Tilgang Er Dømt Til At Mislykkes

Branchen er i øjeblikket besat af at “justere” modeller og bygge bedre prompt-brandvægge. OpenAI tilføjer mere sikkerhedsforanstaltninger. Anthropic fokuserer på konstitutionel AI. Alle forsøger at lave modeller, der ikke kan narres.

Dette er en tabt kamp.

Hvis en AI er intelligent nok til at være nyttig, er den intelligent nok til at blive narret. Vi falder i, hvad jeg kalder “sanitizations-fælden”: antagelsen af, at bedre input-filtrering vil redde os. Men angreb kan være skjult som usynlig tekst i HTML-kommentarer, begravet dybt i dokumentation eller kodet på måder, vi endnu ikke har forestillet os. Du kan ikke sanere, hvad du ikke kan kontekstuel forstå, og kontekst er netop, hvad der gør LLM’er kraftfulde.

Branchen må acceptere en hård sandhed: prompt-injektion vil lykkes. Spørgsmålet er, hvad der sker, når det gør.

Den Arkitektoniske Ændring, Vi Har Brug For

Vi er i øjeblikket i en “lappingsfase”, hvor vi desperat tilføjer input-filtre og valideringsregler. Men ligesom vi til sidst lærte, at forebyggelse af SQL-injektion krævede parameteriserede forespørgsler, ikke bedre streng-undgåelse, har vi brug for en arkitektonisk løsning til AI-sikkerhed.

Svaret ligger i en princip, der lyder enkel, men kræver en omdefinering af, hvordan vi bygger systemer: AI-agenter skal aldrig besidde de hemmeligheder, de bruger.

Dette handler ikke om bedre adgangsstyring eller forbedrede vault-løsninger. Det handler om at anerkende AI-agenter som unikke, verificerbare identiteter snarere end brugere, der har brug for adgangskoder. Når en AI-agent har brug for adgang til en beskyttet ressource, skal den:

1. Autentificere ved hjælp af sin verificerbare identitet (ikke en gemt hemmelighed)

2. Modtage 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. Aldrig gemme eller endda “se” langvarige hemmeligheder

Flere tilgange er under udvikling. AWS IAM-roller til servicekonti, Googles Workload Identity, HashiCorp Vaults dynamiske hemmeligheder og specialløsninger som Akeyless’s Zero Trust Provisioning peger alle mod denne hemmelighedsløse fremtid. Implementeringsdetaljerne varierer, men princippen forbliver: Hvis AI’en ikke har nogen hemmeligheder at stjæle, bliver prompt-injektion en betydeligt mindre trussel.

Udviklingsmiljøet I 2027

Inden for tre år vil .env-filen være død i AI-forstærket udvikling. Langvarige API-nøgler, der sidder i miljøvariabler, vil blive set som vi nu ser på adgangskoder i klartekst: en pinlig rest af en mere naiv tid.

I stedet vil hver AI-agent operere under streng adgangsstyring. Læs-adgang som standard. Handlings-hvidliste som standard. Sandboks-eksekveringsmiljøer som en overholdelseskrav. Vi vil stoppe med at forsøge at kontrollere, hvad AI’en tænker, og fokusere helt på at kontrollere, hvad den kan gøre.

Dette er ikke kun en teknisk evolution; det er en grundlæggende ændring i tillidsmodeller. Vi bevæger os fra “tillid, men verificér” til “aldrig tillid, altid verificér og antag kompromittering”. Princippen om mindst mulig tillid, der længe har været prædiket, men sjældent praktiseret, bliver uafviselig, når din junior-udvikler er en AI, der behandler tusindvis af potentielt ondsindede input dagligt.

Valget, Vi Står Over For

Integreringen af AI i softwareudvikling er uundgåelig og overvejende nyttig. GitHub rapporterer, at udviklere, der bruger Copilot, gennemfører opgaver 55% hurtigere. Produktivitetsgevinsterne er reelle, og ingen organisation, der ønsker at forblive konkurrencedygtig, kan ignorere dem.

Men vi står ved en skillevej. Vi kan fortsætte ad den nuværende vej ved at tilføje flere sikkerhedsforanstaltninger, bygge bedre filtre og håbe, vi kan lave AI-agenter, der ikke kan narres. Eller vi kan anerkende den grundlæggende natur af truslen og genopbygge vores sikkerhedsarkitektur herefter.

Samsung-episoden var et advarende skud. Det næste brud vil ikke være et uheld, og det vil ikke blive begrænset til ét selskab. Da AI-agenter får mere kapacitet og adgang til flere systemer, vokser den potentielle impact eksponentielt.

Spørgsmålet for hver CISO, hver teknisk leder og hver udvikler er enkelt: Når prompt-injektion lykkes i jeres miljø (og det vil), hvad vil angriberen finde? Vil de opdage en skat af langvarige legitimationsoplysninger, eller vil de finde en AI-agent, der, på trods af at være kompromitteret, ikke har nogen hemmeligheder at stjæle?

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

OWASP har allerede identificeret prompt-injektion som #1-risikoen i deres Top 10 for LLM-applikationer. NIST udvikler retningslinjer for zero-trust-arkitekturer. Rammerne eksisterer. Det eneste spørgsmål er implementeringshastighed versus angrebsudvikling.

Bio: Refael Angel er medstifter og teknisk direktør i Akeyless, hvor han udviklede selskabets patenterede Zero-Trust-krypteringsteknologi. En erfaren software-ingeniør med dyb ekspertise i kryptografi og cloud-sikkerhed, Refael har tidligere arbejdet som senior software-ingeniør på Intuits forsknings- og udviklingscenter i Israel, hvor han byggede systemer til håndtering af krypteringsnøgler i offentlige cloud-miljøer og designede maskin-autentificeringstjenester. Han har en bachelorgrad i datalogi fra Jerusalem College of Technology, som han fik i en alder af 19.