Trellix: AI-agenter kan lekke API-nøkler og tokens – uten malware eller ondsinnet hensikt
En Trellix-analyse, omtalt av CyberPress, beskriver hvordan AI-agenter i helt rutinemessige utviklingsoppgaver kan flytte passord, API-nøkler og tokens ut av krypterte lagre og inn i kommandolinjer, logger, filer og til slutt en ekstern modellleverandørs systemer – uten malware, uten ondsinnet hensikt og uten at noen gjør noe galt. Risikomodellen peker på et deteksjonsproblem sikkerhetsteamene knapt har verktøy for å håndtere.
En AI-agent som henter en hemmelighet og bruker den, gjør i utgangspunktet akkurat det den ble bedt om. Problemet, slik sikkerhetsselskapet Trellix beskriver det i en analyse omtalt av CyberPress, er hva som skjer underveis: Hemmeligheten forlater det krypterte lageret, havner i prosessminne, deretter i kommandolinjeargumenter, deretter i logger, telemetri og filer – og i verste fall i kontekstvinduet til en språkmodell drevet av en ekstern leverandør. Ingen ledd i denne kjeden er et sikkerhetsbrudd. Likevel kan sluttresultatet være at en legitim API-nøkkel ligger i en loggfil, i et agenttranskript eller på en modellleverandørs server.
Det er viktig å være tydelig på hva dette er og ikke er: Ingen dokumentert hendelse eller konkret offer er rapportert. Grunnlaget for denne artikkelen er CyberPress' sekundære omtale av Trellix-analysen – det underliggende Trellix-dokumentet, med tittel, dato og forfatterskap, er ikke tilgjengelig for verifisering. Det Trellix beskriver, er en risikomodell: en måte agentdrevne kredentiallekkasjer kan skje på, og hvorfor de er så vanskelige å oppdage.
Isolasjonsgradienten
Analysens sentrale begrep er det Trellix kaller en «isolation gradient» – en isolasjonsgradient der hemmeligheter beveger seg stadig lenger bort fra beskyttelsen. Kjeden ser omtrent slik ut:
- Kryptert lager – OS-nøkkelring, cloud secret manager, miljøvariabler i et hemmelighetsvault. Her er hemmeligheten ordentlig beskyttet av tilgangskontroll og kryptering.
- Prosessminne – En credential helper eller et CLI-verktøy henter verdien, og den eksisterer nå i klartekst i en prosess.
- Kommandolinje – Verdien settes inn som argument eller header i en kommando, for eksempel en curl-kommando mot et API.
- Filer og telemetri – Kommandoen logges av skallet, av overvåkningsverktøy, av agentens eget transkript eller av applikasjonens fillogg.
- Eksterne systemer – Data sendes til den tjenesten som skulle nås – eller, via modellens kontekstvindu, til en ekstern modellleverandør.
Poengmetoden er at hver overgang er legitim og hver for seg uskyldig. Men eksponeringen øker trinnvis for hvert steg, og hvor langt hemmeligheten faktisk vandrer, avhenger av tilgangstillatelser, loggingsinnstillinger og agentens design, ifølge Trellix. Et agentoppsett som logger alle verktøykall, combined med en agent som får lov til å lese konfigurasjonsfiler, kan altså flytte en hemmelighet fra et velbeskyttet vault til en tekstfil på få sekunder – som en del av en helt normal arbeidsøkt.
OAuth-tokenet i curl-headeren
Trellix' illustrasjon av mekanismen er deceptively enkel. En agent får beskjed om å hente en brukerprofil fra Microsoft Graph – en helt routineoppgave. Agenten bruker en credential helper til å skaffe et OAuth-token, og bygger deretter en curl-kommando med tokenet i authorization-headeren. Forespørselen når riktig tjeneste, og alt ser ut til å ha gått bra.
Men tokenet sto nå i klartekst som del av en kommandolinje. Det kan dukke opp i prosesstelemetri, i agentens transkript av egne verktøykall, eller i andre kommandologger. Alle disse stedene er reelle eksponeringsflater: prosesstelemetri leses av EDR-systemer og IT-personell, transkripter kan lagres, delas eller brukes til feilsøking, og kommandologger blir ofte liggende i fredete filer i lang tid. Det er verdt å merke seg at kilden ikke sier om dette eksempelet er hentet fra reelle observasjoner eller er konstruert – CyberPress' omtale beskriver det generisk som et eksempel fra analysen.
Poenget er strukturelt, ikke anekdotisk: Så lenge agenten bygger kommandoer med hemmeligheter som argumenter, blir selve mekanismen for legitim autentisering en lekkasjekanal. Verktøyet fungerer; det er sporadene rundt det som lekker.
Konfigurasjonsfiler inn i kontekstvinduet
Den andre hovedmekanismen går via fillesing. Prosjekter fylles av filer som .env, AWS credentials-filer, Kubernetes-konfigurasjon og applikasjonsinnstillinger – filer som per definisjon inneholder hemmeligheter. Når en agent leser slike filer som en del av et oppdrag («sett opp miljøet», «feilsøk deploymenten»), blir innholdet verktøyoutput – og verktøyoutput havner i agentens kontekstvindu.
For skybaserte modeller betyr det, slik Trellix beskriver det, at hemmeligheter kan sendes til en ekstern modellleverandør. Her er kildens forbehold viktig: Lagring og retensjon varierer mellom tjenester og konfigurasjoner, og eksponering skal ikke automatisk beskrives som permanent. Men det er en strukturell endring i hva et hemmelighetslekkasje-incident er: Tidligere måtte en angriper eksfiltrere data fra maskinen din. Nå kan agentens normale funksjonsmåte sende en legitim hemmelighet som del av en API-forespørsel til en tredjepart, uten at noen klassifiserer hendelsen som eksfiltrering.
Trellix peker også på en tredje variant som er enda mer motsetningsfylt: OS-nøkleringer og cloud secret managers kan levere hemmeligheter i klartekst, helt korrekt. Vaultens tilgangskontroll fungerer som den skal – autentisering, autorisasjon, revisjonslogg. Det som svikter, er det som skjer etterpå: agenten feilhåndterer verdien den nettopp fikk utlevert. Lagerets sikkerhetsmodell slutter der verdien forlater lageret; agentens håndtering av verdien ligger utenfor.
Hvorfor deteksjonen struler
Det som gjør dette til et vanskelig deteksjonsproblem, er at agentens verktøykasse er identisk med utviklerens. Curl, git, node og kubectl er kjernen i enhver legitim utviklings- og driftsarbeidsflyt. At en agent kjører curl med et token i headeren, eller leser en Kubernetes-config, etablerer på ingen måte kredentialtyveri – det er ofte akkurat det oppgaven krevde. Et regelverk som flagger disse mønstrene, vil enten oversvømme analystene med falske positiver eller bli så smalt definert at det mister verdi.
Trellix' konklusjon er at sikkerhetsteamene må over fra enkelt-events til korrelasjon: hvilken agent aksesserte en hemmelighet, hvordan verdien ble brukt, og om data deretter forlot verten. Det krever sammenkobling av kredentialaksess, prosesskjøring, filendringer og nettverkstrafikk på tvers av systemer – en kapabilitet mange organisasjoner verken har verktøy eller prosedyrer for i dag. Enkelt-logg-analyse, som er normen i mange SOCer, ser hver hendelse isolert og kan ikke skille den ufarlige curl-kommandoen fra den problematiske.
Prompt injection som forsterker
Risikomodellen blir skarpere når man legger til en angrepsvei Trellix nevner direkte: prompt injection. Agentens kapabiliteter – lese filer, kjøre kommandoer, hente nettsider – kan omdirigeres av instruksjoner gjemt i ikke-klarerte prosjektfiler eller webinnhold. En ondsinnet README, en pakkebeskrivelse eller en nettside agenten leser, kan styre agenten mot å lese hemmeligheter eller sende dem et sted de ikke skal.
I denne rammen trenger ikke angriperen å kompromittere maskinen eller bryte vaultet. Det holder å få agenten til å bruke de kapabilitetene den allerede har, mot et annet mål. Eksisterende kredentialtilgang plus injiserte instruksjoner gir en lekkasjevei der alle tekniske sikkerhetskontroller nominelt sett har fungert.
Som bakgrunnskontekst – klart adskilt fra Trellix-materialet – har Palo Alto Networks' Unit 42 bekreftet 22 typer prompt injection-teknikker brukt i reelle miljøer, med mål som inkluderer promotering av phishing-nettsteder, uautoriserte transaksjoner, lekkasje av sensitiv data og lekkasje av systemprompter. Det er verdt å understreke at dette stammer fra annen dekning (Masato Kawakami, med henvisning til Unit 42), og ikke dokumenterer Trellix-analysen. Men det viser at kontrollert omdirigering av agentatferd ikke er en teoretisk bekymring; teknikkmønsteret er dokumentert i praksis, og sensitiv datalekkasje er blant målene.
Hva Trellix anbefaler
Mottiltakene fra Trellix, slik CyberPress gjengir dem, angriper problemet på flere nivåer samtidig:
- Hold hemmeligheter ut av kommandoargumenter og modellkontekst. Det er det mest direkte svaret på begge hovedmekanismene: Ikke la tokenet stå i en curl-header eller filinnholdet i en .env-fil nå fram til modellen.
- Credential brokers. I stedet for at agenten selv håndterer verdien, formidles autentisering av en mellomledd som aldri eksponerer hemmeligheten i klartekst overfor agenten eller dens verktøykjede.
- Kontrollerte inputkanaler. Begrens hvilke filer, nettadresser og datakilder agenten kan ta imot instruksjoner og innhold fra – en direkte respons på prompt injection-risikoen.
- Redigering før modellinnsending. Fjern eller masker hemmeligheter fra dataene før de sendes til modellen, slik at kontekstvinduet aldri blir en eksportkanal.
- Restriksjoner på usikker transport og uautoriserte opplastinger. Begrens agentens mulighet til å sende data ut av verten utenom kontrollerte veier.
Felles for tiltakene er at de flytter sikkerhetsgrensen fra lageret – som allerede fungerer – til agentens datasirkulasjon, som i dag i stor grad er uregulert.
Åpne spørsmål
Risikomodellen reiser flere spørsmål som kildene ikke besvarer. Hvordan utbredt er praksisen der agenter faktisk leser .env-filer og credentials-filer inn i kontekstvinduet? Det avhenger av agentens tillatelsesmodell, og Trellix-analysen, slik den er omtalt, gir ingen kvantifisering. Hvor effektive er redigering og credential brokers i praksis, når agenter kombinerer verktøy på uforutsigbare måter? Og hvem bærer ansvaret når en legitim agent sender en legitim hemmelighet til en legitim modellleverandør – utvikleren som kalte agenten, agentleverandøren, eller organisasjonen som konfigurerte tillatelsene?
Kildegrunnlaget setter også grenser: Hele bildet bygger på én sekundær omtale av ett selskaps analyse, uten dokumentert incident og uten tilgang til det underliggende dokumentet. Illustrasjonsekvemplene er ikke bekreftet som reelle observasjoner. Det betyr ikke at risikomodellen er feil – mekanismene er konkrete, og logikken i isolasjonsgradienten lar seg verifisere mot hvordan agentverktøy faktisk fungerer. Men den er ennå ikke understøttet av dokumenterte lekkasjer eller tall.
Det er likevel grunnen til at analysen fortjener oppmerksomhet: Den peker på et hull som verken eksisterende vault-sikkerhet, EDR eller modellens egne sikkerhetsrammer dekker. Hemmelighetens reise fra kryptert lager til modellkontekst består utelukkende av lovlige handlinger. Sikkerhetsmodeller som bare ser etter ulovlige, har foreløpig lite å reagere på.