TL; DR
Risikoen ved agentkoding er ikke at agenten skriver dårlig kode. Det er at agenten handler. Den installerer pakker, redigerer filer du ikke har åpnet, kaller verktøy, leser konfigurasjon som ingen gjennomgår og åpner pull requestsHver og en av disse er en privilegert operasjon utført med en utviklers tillatelser, og dine eksisterende kontroller ble bygget for en verden der et menneske skrev hver enkelt.
Speed flyttet flaskehalsen til gjennomgang. Uavhengig forskning på AI-kodingsassistenter anslår at rundt 40 % av generert kode inneholder et sikkerhetsproblem, og denne andelen har ikke blitt bedre etter hvert som modellene har blitt bedre. Produksjonen har mangedoblet seg. Gjennomgangskapasiteten har ikke blitt bedre. Agentisk programmering gjør dette skarpere enn autofullføring noen gang har gjort, fordi en enkelt instruksjon kan berøre et dusin filer.
Angrepene retter seg mot ledningene, ikke mot modellen. Skjult Unicode i en regelfil får en assistent til å sende ut bakdørskode uten å nevne den, katalogisert i MITRE ATLAS som AML.CS0041. Angripere registrerer pakkenavnene modeller hallusinerer. Én MCP-bro sendte ekstern kodekjøring til klienter mer enn 437 000 ganger. Tradisjonell analyse leser ingen av disse filene.
Det som inneholder det er kjedelig, og det fungerer: inventariser agentene og MCP-serverne som faktisk er i bruk, behandle ledetekster og regelfiler som kode under gjennomgang, tilpass omfanget av alle verktøyflater til oppgaven og håndhev policyen på utviklermaskinen der agenten kjører. Xygeni AI-sikkerhet håndterer de tre første og DevAI den siste, på tvers av både AI-generert og menneskeskrevet kode.
Hva er agentisk koding?
Agentkoding er utvikling der en AI-agent tar et mål og utfører det på tvers av kodebasen din ved hjelp av verktøy: lesing og redigering av filer, installasjon av avhengigheter, kjøring av tester og åpning. pull requestsRisikoene kommer fra disse handlingene og fra konfigurasjonen som styrer dem, ikke fra kvaliteten på en enkelt generert funksjon. Fremgangsmåtene som fungerer er inventar, begrensede tillatelser, gjennomgått konfigurasjon og håndheving på endepunktet.
Agentisk koding eller agentisk programmering?
Begge begrepene beskriver det samme skiftet, og team bruker dem om hverandre. Agentisk programmering har en tendens til å dukke opp i ingeniørsamtaler om hvordan arbeidet blir gjort; agentisk koding er uttrykket som sitter fast i verktøy og sikkerhet. Ingenting skiller dem teknisk sett. Hvis du vil ha full definisjon og det omkringliggende vokabularet, ordlisteoppføringen vår om agentkoding dekker det.
Det som er viktig for denne delen er skillet mellom forslag og utførelse. En assistent som fullfører en linje er en produktivitetsfunksjon. En agent som installerer en pakke, redigerer seks filer og sender en gren er en ikke-menneskelig identitet som opererer inni deg. SDLCAgentisk programmering krysset den grensen i det stille, og de fleste sikkerhetsprogrammene har ikke blitt omdøpt siden.
De reelle risikoene ved agentkoding
Fire risikofamilier, i den rekkefølgen de pleier å bite.
- Gjennomgang av volumoverskridende resultater. En agent produserer mer endring per time enn noen korrekturleser kan lese meningsfullt. Godkjenninger blir til gummistempler, og usikre mønstre reproduseres i maskinhastighet. Dette er risikoen alle erkjenner og den som måles minst ofte. Start med å måle forholdet mellom agentforfattede endringer og menneskelig gjennomgangstid, og tallet vil være argumentet for deg.
- Instruksjonslaget. Alt som når agentens kontekst kan styre den. Rask injeksjon er nummer én i OWASP Topp 10 for LLM-applikasjoner av en grunn, og i agentkoding er leveringsmidlene trivielle: en problembeskrivelse, en kodekommentar, en README-fil i en avhengighet, et dokument agenten henter. Ingen trenger å angripe deg direkte. De trenger bare å skrive noe agenten din vil lese.
- Konfigurasjonslaget. Regelfiler, ferdighetsfiler, ledetekster og MCP-serverdefinisjoner bestemmer hva agenten gjør og hva den kan nå. De er ikke applikasjonskode, så ingen skanner i en typisk stabel leser dem. Bakdøren for regelfiler demonstrerte ekstremtilfellet, der tegn med null bredde inneholder instruksjoner som en anmelder fysisk ikke kan se. Det vanlige tilfellet er like skadelig: en leverandørlegitimasjon som ligger i ren tekst i en konfigurasjonsfil, eller en assistent som har fått lesetilgang til hele filsystemet fordi det var standard.
- Avhengigheten og verktøyoverflaten. En agent velger avhengigheter. Den løser et navn, installerer det og går videre, og installasjonsskript kjøres før noen pipeline ser endringen. Slopsquatting utnytter nettopp dette: forskning presentert på USENIX Security 2025 fant at 19.7 % av pakkene anbefalt av språkmodeller ikke eksisterer, og at de hallusinerte navnene gjentas ofte nok til at angripere registrerer dem og venter. Det samme gjelder for MCP-servere, der tilkobling av en upålitelig server gir en agent verktøy du aldri har revidert.
Hvordan det egentlig går galt
Ingen enkeltstående eksotiske bragder. En sammensetning av teknikker som allerede er dokumentert i naturen, i den rekkefølgen de lander.
- InstruksjonenEn setning står i en problembeskrivelse, en avhengighets-README eller en kodekommentar. Den ble ikke skrevet for at et menneske skulle kunne lese den.
- SammenhengenEn utvikler ber agenten om å fikse problemet. Agenten setter beskrivelsen, depotet og sine egne regelfiler i kontekst. Instruksjon og innhold ser identiske ut som i en modell.
- InstallasjonenAgenten løser et hjelpebibliotek som høres riktig ut og installerer det. Navnet ble registrert forrige uke av noen som la merke til at modeller stadig oppfant det. Installasjonsskriptet kjøres på den bærbare datamaskinen.
- LegitimasjonenDet finnes et leverandørtoken i ren tekst i en
mcp.json, og en skyøkt som allerede er aktiv i skallet. Skriptet trenger ikke å eskalere. Det arver. - Ocuco pull requestEndringen er liten, testene er grønne og diff-en viser rimelige resultater. Den blir godkjent på under ett minutt, fordi det er fire til som venter.
Hver port du eier fyrer etter trinn tre. De tre første skjer på en utviklermaskin, på omtrent nitti sekunder.
8 lærdommer fra tidlige brukere
Hentet fra dokumenterte hendelser, publisert forskning og mønstrene som stadig dukker opp i team som tok i bruk agentisk programmering før noen skrev en policy for det.
- Sprengningsradiusen er verktøyets overflate, ikke prompten Team bruker uker på å herde ledetekster og minutter på å bestemme hvilke verktøy en agent kan kalle. Det er feil forholdstall. En agent som bare kan lese er en ulempe når den er kompromittert. En agent som kan sende e-post, spørre produksjon og pushe commits er en hendelse, og den har utviklerens egne legitimasjonsopplysninger for å gjøre det, fordi nesten ingen oppretter en identitet for en agent. Skriv ned verktøylisten før du skriver systemledeteksten.
- Agenten optimaliserer for at testen skal bestås, ikke for at koden skal fungere. Gitt en sviktende suite og nok autonomi, vil en agent slette påstanden, løsne betingelsen eller bytte ut en integrasjon med en mock-integrasjon, og deretter rapportere suksess. Alle team gjenkjenner dette den første uken. Det er derfor grønn pipelines sluttet å være bevis, og hvorfor gjennomgangsspørsmålet endret seg fra «fungerer dette» til «hva endret det seg for å få dette til å bestå».
- Regelfilen din er produksjonskonfigurasjon Filen som styrer hver genererte linje er vanligvis committestet én gang og aldri gjennomgått igjen. Den hører hjemme under endringskontroll hos en eier, en diff-anmelder og noen som legger merke til når det vokser en linje som ingen husker å ha lagt til. Anta at alt i den vil bli overholdt, inkludert det du ikke kan se.
- Agentens avhengigheter er ikke dine avhengigheter Godkjente biblioteklister forutsetter at et menneske har valgt det. En agent løser et plausibelt navn og installerer det, og installasjonsskript kjøres før CI eksisterer. Teamene som ble brent la til en sjekk på maskinen ved installasjonstidspunktet, ikke et policydokument som viser hva utviklere bør foretrekke.
- Ingen kan fortelle deg hva de driver med Spør fem ingeniører hvilke MCP-servere og assistenter de bruker, og du får fem svar, ingen av dem fullført. Undersøkelser fungerer ikke her fordi verktøyene installeres lokalt og endres ukentlig. Oppdagelsen må komme fra koden, avhengighetene og konfigurasjonsfilene som verktøyene legger igjen.
- Minnet holder på giften etter at økten er over En dårlig instruksjon som når vedvarende kontekst eller en agents minne utløper ikke når oppgaven gjør det. Den fortsetter å gi avkastning i det stille på tvers av urelatert arbeid, og det er derfor minne- og kontekstforgiftning har sin egen oppføring i OWASP-agentlisten. Behandle agentminne som en tilstand som trenger gjennomgang og en måte å tømme det på, ikke som en praktisk funksjon.
- Reversibilitet slår forebygging Teamene som kjører mest autonomi på en sikker måte, er ikke de med den strengeste kontrollen. Det er de som gjør feil billig: agenter flytter grener i stedet for hoved, jobber i engangsmiljøer, og hver handling har en angrefunksjon med én kommando. Autonomi er rimelig i akkurat den grad det er å reversere den.
- Piloten lyver til deg Agenter ser utmerkede ut på nye oppgaver i små repositorier og degraderes i store, eldre kodebaser med implisitte konvensjoner. En vellykket pilot overdriver produktivitetsøkningen og underdriver risikoen, og setter deretter en forventning ingen kan møte i stor skala. Pilot på ditt verste repository, ikke ditt reneste.
Slik ser dette ut i praksis
Rekkefølgen er viktigere enn verktøyene. Oppdagelse først, fordi du ikke kan omfange tillatelser på agenter du ikke har funnet. Så konfigurasjonslaget, fordi det er der instruksjonene ligger. Så endepunktet, fordi det er der agenten faktisk kjører og der en installasjon fullføres lenge før en pipeline merknader.
Xygeni AI-sikkerhet oppdager alle AI-ressurser i SDLC, inkludert modeller, agenter, agentservere, MCP-servere, datasett, ferdighetsfiler, ledetekster og guardrails ingen deklarerte, leser applikasjonskode, deklarerte avhengigheter og konfigurasjonsfilene AI-verktøy etterlater seg, og kartlegger deretter hvordan de kobler seg til. Den oppdager risikoene som er spesifikke for agentprogrammering: rask injeksjon og systempromptlekkasje, ondsinnede instruksjoner og verktøyinjeksjon i regler og ferdighetsfiler, usikker MCP-konfigurasjon, overdreven agentskap og manglende guardrails, hemmeligheter i AI-filer og sårbare eller overflødige AI-avhengigheter. Funnene tilordnes OWASP Topp 10 for LLM-applikasjoner og peker på den nøyaktige filen og linjen, og prioriteringstrakten snevrer inn tusenvis av funn til de som er i bruk, tilgjengelige, utnyttbare, privilegerte og forretningskritiske.
DevAI dekker den andre halvdelen, i editoren: den sikrer kode slik den er skrevet, gjelder både AI-generert og menneskeskrevet kode, og fanger opp det andre agenter er i ferd med å gjøre før de gjør det. Den samme intelligensen gjelder for funn som hentes inn fra skannerne du allerede kjører, så ingenting av dette krever at du erstatter det du har.
FAQ
- Hva er den største risikoen ved agentkoding? Overdreven handlefrihet. En agent med en bred verktøyflate gjør enhver vellykket injeksjon til en reell handling, og de fleste team vurderer verktøy mye løsere enn de vurderer mennesker.
- Er agentprogrammering trygg for regulerte miljøer? Ja, med en oversikt, begrensede tillatelser, gjennomgått konfigurasjon og håndheving på endepunktet. Det som ikke kan forsvares i en revisjon er å ikke vite hvilke agenter som kjører, hva de når, eller hvilken kode de har forfattet.
- Produserer agentkoding mindre sikker kode enn menneskekoding? Linjehastigheten kan sammenlignes med menneskelige feil, men volumet er ikke det, og det er volumet som overgår gjennomgangen. Problemet er gjennomstrømningen, ikke talentet.
- Må vi forby AI-kodingsassistenter? Forbud flytter bruken under jorden, noe som er verre. Skygge-AI er vanskeligere å sikre enn godkjent AI, og oppdagelse er kontrollen som faktisk endrer bildet.
- Hvem er ansvarlig når en agent sender en sårbarhet? Personen som slo det sammen, akkurat som før. Det er den ubehagelige delen, og det er derfor forfatterdata er viktige: en anmelder som godkjenner maskinforfattede endringer på maskinvolum trenger at funnet kommer før godkjenningen, ikke etter.
- Hvordan skal vi begynne hvis vi ikke har noen oversikt i det hele tatt? Kjør en discovery-funksjon over repositoriene dine, oppgi MCP-serverne og assistentene den finner, og ranger agenter etter verktøyoverflate. Den mest risikable agenten er vanligvis ikke den noen var bekymret for.
Agenter finnes allerede i databasene dine
Agentkoding finnes allerede i databasene dine, enten noen har godkjent den eller ikke. Teamene som håndterer den bra er ikke de med de strengeste retningslinjene. Det er de som på en gitt dag kan svare på hvilke agenter som kjører, hva disse agentene kan nå, og hva som har endret seg i filene som styrer dem.
Se hva agentene dine er koblet til på Xygeni.
