Agentic coding: Har I styr på sikkerheden i jeres setup, før AI-agenten får adgang?
Du har fået en ny kollega på kontoret. Hun er utrættelig, hurtig og ekstremt selvsikker. Agentic coding kan føles som en ny juniorudvikler på teamet, men hun opfører sig ikke som dem af kød og blod. Så hvordan får du styr på sikkerheden, inden du giver din nye kollega nøglerne til alt det, du selv har adgang til?
Der er et stort potentiale i agentic coding, men der følger også risici med. For når vi giver AI-agenter adgang til at kode, giver vi dem i praksis også adgang til en række systemer, beslutninger og handlinger, der kan få konsekvenser, hvis man ikke har styr på sit setup.
I blogindlægget forklarer Lead Security Engineer Mads Schaarup Andersen, hvor organisationer bør starte, før AI-agenter bliver en fast del af udviklingsmiljøet.
Kom i gang!
Det kan virke som en banal pointe, men overraskende mange organisationer kommer i problemer, fordi de ikke kommer i gang rettidigt. Som leder kan du være helt sikker på, at der allerede er medarbejdere, der er i fuld gang med at benytte agentic coding – uanset om du er klar eller ej.
”Det handler ikke om at tegne et skræmmebillede, men om at gribe den mulighed, der er i, at I har nogle dygtige medarbejdere, der allerede benytter AI-værktøjer. Som ledelse er det jeres ansvar at melde ud, hvilke forventninger og muligheder der er. Også selvom I ikke har alle svarene endnu,”
AI-politikker og trusselsmodellering er en proces, der kommer til at udvikle sig over tid. Hvis I beslutter jer for at bygge et forkromet rammeværk, inden I involverer jeres medarbejdere, er I helt sikkert allerede bagud.
”Det gælder ikke om at opnå det højeste modenhedsniveau fra dag ét. Spørg, byg og tilpas. Ellers risikerer I at designe et setup, der reelt ikke passer til udviklernes arbejdsgange,”
Forstå trusselmodellen
Med AI som partner bevæger vi os ind i nyt land. Og som enhver anden opdagelsesrejsende er du nødt til at kortlægge det territorie, du er ved at udforske. Derfor bør I starte med en trusselmodel: Hvad skal beskyttes, hvem eller hvad kan kompromittere det, og hvad er konsekvensen, hvis det sker?
“Før I slipper AI løs i jeres udviklingsmiljø, skal I have en forståelse af, hvad der indgår i en agentbaseret kodningsproces. Hvilke data flyder hvorhen, og hvor i dette flow er der noget, der kan gå galt?”
Start med at få en forståelse for, at der faktisk er mange komponenter i spil, når I laver agentbaseret kodning. Der er modellen (LLM’en), man forbinder til, der er ressourcer i lokalmiljøet på udviklermaskinerne, agent-plugins, MCP-servere, custom-agenter og skills – bare for at starte et sted. Som udgangspunkt kan agenten tilgå alle dele af setup’et, men spørg jer selv, om det er hensigtsmæssigt?
Det er også vigtigt at tænke i ondsindet manipulation. En agent kan ikke kun påvirkes af det, brugeren skriver direkte. Den kan også blive påvirket af bl.a. såkaldte injection attacks, hvor ondsindede instruktioner bliver tilføjet til workflowet fra fx et manipuleret plugin eller en manipuleret hjemmeside.
Opkvalificér og involvér udviklere
Selv de bedste regler og sikkerhedsværn virker kun, hvis udviklerne forstår, hvorfor de findes, og hvordan de skal bruges i hverdagen. Derfor er det organisationens ansvar at klæde udviklerne på til at arbejde sikkert med agentic coding. Og så er det altafgørende for succesen (og sikkerheden), at udviklerne bliver involveret i processen:
”Jeres medarbejdere kommer ikke selv til at opsøge den her viden. Som organisation skal I involvere og motivere og ikke mindst lytte til, hvordan udviklerne reelt arbejder med AI. Hvis I ikke spørger, kan forkerte antagelser føre jer et sted hen, hvor politik og praksis lever adskilte liv,”
Det handler blandt andet om at lære udviklere at genkende risici som prompt injection, usikre plugins, ukritisk package-installation, deling af secrets og for brede rettigheder. Brug anerkendte ressourcer som OWASP, interne guidelines og konkrete eksempler fra jeres egne udviklingsmiljøer, så sikkerheden bliver praktisk og relevant.
“Giv udviklerne adgang til gode ressourcer om sikkerhed, så de ved, hvordan de beskytter både kode og data, når AI bliver en del af værktøjskassen,”
Samtidig bør udviklerne vide, hvornår de skal stoppe op og bede om godkendelse – for eksempel før agenten får adgang til nye tools, eksterne services, produktionsdata eller credentials.
Etabler governance og risikostyring
Når AI-agenter får adgang til dit udviklingsmiljø, er det ikke nok at stole på, at de opfører sig korrekt, eller at den enkelte udvikler selv har styr på alle risici. I skal som organisation sætte rammerne i form af governance: klart definerede regler for, hvilke skills, plugins, MCP-servere og CLI-værktøjer der må bruges, og hvordan de installeres og administreres.
“Sørg for klare regler og styring, så ingen bare kan installere tilfældige AI-plugins eller koble op til eksterne tjenester, hvor både forretningshemmeligheder og personlige data kan ende med at blive lækket,”
”Det bør ikke være op til den enkelte udvikler at vurdere, om et tilfældigt plugin, MCP-server eller ekstern service er sikker nok,”
En god tommelfingerregel er at opfatte agenten som enhver anden del af jeres software supply chain: Det skal vurderes, godkendes, opdateres og kunne fjernes igen, hvis de viser sig at udgøre en risiko.
Implementér sikkerhedsværktøjer og sandboxes
Governance sætter rammerne. De tekniske sikkerhedsværn skal håndhæve dem i praksis. Brug f.eks. sandboxes, containere eller isolerede udviklingsmiljøer, så agenten ikke frit kan læse hele filsystemet, ændre kritiske filer eller køre kommandoer uden begrænsning.
“Brug de indbyggede sikkerhedsfunktioner, så AI ikke kan udføre fatale opgaver som at slette produktionsdata. Det er nemt at overse, men kan koste dyrt,”
Sikkerhedsscanninger, agent hooks og approval gates kan hjælpe med at stoppe risikable handlinger, før de sker. Det kan for eksempel være krav om menneskelig godkendelse, før agenten installerer packages, ændrer CI/CD-konfiguration, bruger secrets, sletter filer, pusher kode eller forsøger at tilgå produktionsmiljøer.
Sikkerhedsfunktionerne skal ikke kun slås til én gang. De bør testes løbende, så I ved, om de faktisk stopper de handlinger, de er sat op til at forhindre.
Opsummering: Fem sikkerhedsanbefalinger, der får jer i gang
Mads’ vigtigste pointe er, at agentic coding med stor hast er på vej ind i udviklingsmiljøerne. I mange organisationer er det allerede i brug – måske også i jeres. Derfor kan arbejdet med sikkerhed, governance og risikostyring ikke vente. Start her:
- Kom i gang nu. Vent ikke på det perfekte rammeværk. Sæt retning, forventninger og rammer, mens I lærer og tilpas løbende.
- Start med trusselmodellen. Få overblik over, hvad der skal beskyttes, hvilke data der flyder hvorhen, hvilke komponenter der indgår i jeres setup, og hvor noget kan gå galt.
- Opkvalificér og involvér udviklerne. Sikkerheden skal passe til den måde, udviklerne faktisk arbejder på. Derfor skal de med fra start – både som brugere, sparringspartnere og medskabere af rammerne.
- Sæt klare rammer for governance og risikostyring. Det bør ikke være op til den enkelte udvikler at vurdere, hvilke plugins, MCP-servere, skills, CLI-værktøjer eller eksterne services der er sikre nok.
- Håndhæv rammerne med tekniske sikkerhedsværn. Brug sandboxes, containere, sikkerhedsscanninger, agent hooks og approval gates, så agenten ikke frit kan tilgå filer, credentials, produktionsdata eller kritiske systemer uden kontrol.
Det er i første omgang organisationens og ledelsens ansvar at skabe de sikre rammer. Ikke den enkelte udviklers. For agentic coding kommer til at fylde mere, og de organisationer, der kommer i gang nu, står stærkere end dem, der først reagerer, når AI-agenten allerede har fået nøglerne.
Mads runder af med en opfordring til at huske, at alle ikke har samme udgangspunkt:
”Det er ikke nok at teste på sig selv eller sine nærmeste tre kollegaer. Sikkerhedsforanstaltningerne skal fungere for hele organisationen i praksis. Alle er ikke AI-eksperter, og vi skal passe på med blinde vinkler. Det er derfor, det er så afgørende at involvere medarbejderne fra start,”
