TL; DR
Risikoen ved agentisk kodning er ikke, at agenten skriver dårlig kode. Det er, at agenten handler. Den installerer pakker, redigerer filer du ikke har åbnet, kalder værktøjer, læser konfigurationer som ingen gennemgår og åbner. pull requestsHver af disse er en privilegeret operation udført med en udviklers tilladelser, og dine eksisterende kontroller blev bygget til en verden, hvor et menneske indtastede hver enkelt.
Speed flyttede flaskehalsen til gennemgang. Uafhængig forskning i AI-kodningsassistenter anslår, at omkring 40 % af genereret kode indeholder en sikkerhedssårbarhed, og denne andel er ikke blevet forbedret i takt med at modellerne er blevet bedre. Outputtet er mangedoblet. Gennemgangskapaciteten er ikke det. Agentisk programmering gør dette skarpere end autofuldførelse nogensinde har gjort, fordi en enkelt instruktion kan berøre et dusin filer.
Angrebene er rettet mod ledningerne, ikke modellen. Skjult Unicode i en regelfil får en assistent til at udsende bagdørskode uden at nævne den, katalogiseret i MITRE ATLAS som AML.CS0041. Angribere registrerer de pakkenavne, modeller hallucinerer. En MCP-bro sendte fjernkodeudførelse til klienter mere end 437,000 gange. Traditionel analyse læser ingen af disse filer.
Det, der indeholder det, er kedeligt, og det virker: Lav en opgørelse over de agenter og MCP-servere, der rent faktisk er i brug, behandle prompts og regelfiler som kode under gennemgang, tilknytte alle værktøjsoverflader til opgaven og håndhæv politikker på den udviklermaskine, hvor agenten kører. Xygeni AI-sikkerhed håndterer de første tre og DevAI den sidste, på tværs af både AI-genereret og menneskeskrevet kode.
Hvad er agentisk kodning?
Agentisk kodning er udvikling, hvor en AI-agent tager et mål og udfører det på tværs af din kodebase ved hjælp af værktøjer: læsning og redigering af filer, installation af afhængigheder, kørsel af tests og åbning. pull requestsRisiciene stammer fra disse handlinger og fra den konfiguration, der styrer dem, ikke fra kvaliteten af en enkelt genereret funktion. De praksisser, der virker, er lagerstyring, omfangstilladelser, gennemgået konfiguration og håndhævelse ved slutpunktet.
Agentisk kodning eller agentisk programmering?
Begge udtryk beskriver det samme skift, og teams bruger dem i flæng. Agentisk programmering har en tendens til at optræde i tekniske samtaler om, hvordan arbejdet udføres; agentisk kodning er det udtryk, der sidder fast i værktøj og sikkerhed. Intet adskiller dem teknisk set. Hvis du vil have fuld definition og det omgivende ordforråd, vores ordliste om agentisk kodning dækker det.
Det vigtige i denne artikel er sondringen mellem forslag og udførelse. En assistent, der fuldfører en linje, er en produktivitetsfunktion. En agent, der installerer en pakke, redigerer seks filer og videresender en branch, er en ikke-menneskelig identitet, der opererer inde i din. SDLCAgentic-programmering krydsede stille og roligt den grænse, og de fleste sikkerhedsprogrammer er ikke blevet omdøbt siden.
De reelle risici ved agentisk kodning
Fire risikofamilier, i den rækkefølge de har tendens til at bide.
- Anmeldelse af en overlegen volumen. En agent producerer flere ændringer i timen, end nogen korrekturlæser meningsfuldt kan læse. Godkendelser bliver til gummistempler, og usikre mønstre reproduceres med maskinhastighed. Dette er den risiko, alle anerkender, og den, der mindst ofte måles. Start med at måle forholdet mellem agentforfattede ændringer og menneskelig gennemgangstid, og tallet vil være et argument for dig.
- Instruktionslaget. Alt, der når agentens kontekst, kan styre den. Hurtig injektion er nummer et i OWASP Top 10 til LLM-applikationer af en grund, og i agentkodning er leveringsmidlerne trivielle: en problembeskrivelse, en kodekommentar, en README-fil i en afhængighed, et dokument som agenten henter. Ingen behøver at angribe dig direkte. De skal kun skrive noget, som din agent vil læse.
- Konfigurationslaget. Regelfiler, færdighedsfiler, prompts og MCP-serverdefinitioner bestemmer, hvad agenten gør, og hvad den kan nå. De er ikke applikationskode, så ingen scanner i en typisk stak læser dem. Rules File Backdoor demonstrerede det ekstreme tilfælde, hvor tegn med nul bredde indeholder instruktioner, som en korrekturlæser fysisk ikke kan se. Det almindelige tilfælde er lige så skadeligt: en udbyderlegitimation, der ligger i almindelig tekst i en konfigurationsfil, eller en assistent, der har fået læseadgang til hele filsystemet, fordi det var standardindstillingen.
- Afhængigheden og værktøjsoverfladen. En agent vælger afhængigheder. Den finder et navn, installerer det og går videre, og installationsscripts køres før nogen pipeline ser ændringen. Slopsquatting udnytter præcis dette: forskning præsenteret på USENIX Security 2025 viste, at 19.7% af pakkerne anbefalet af sprogmodeller ikke findes, og at de hallucinerede navne gentages ofte nok til, at angribere kan registrere dem og vente. Det samme gælder for MCP-servere, hvor forbindelse til en ikke-tillidsfuld server giver en agent værktøjer, du aldrig har revideret.
Hvordan det egentlig går galt
Ingen enkeltstående eksotisk udnyttelse. En sammensætning af teknikker, der allerede er dokumenteret i naturen, i den rækkefølge de lander.
- InstruktionenEn sætning findes i en problembeskrivelse, en afhængigheds-README eller en kodekommentar. Den er ikke skrevet til at blive læst af et menneske.
- KontekstenEn udvikler beder agenten om at løse problemet. Agenten trækker beskrivelsen, arkivet og sine egne regelfiler ind i kontekst. Instruktion og indhold ser identiske ud som i en model.
- InstallationenAgenten løser et hjælpebibliotek, der lyder rigtigt, og installerer det. Navnet blev registreret i sidste uge af en person, der bemærkede, at modeller blev ved med at opfinde det. Installationsscriptet udføres på den bærbare computer.
- LegitimationenDer er et udbydertoken i almindelig tekst i en
mcp.json, og en cloud-session, der allerede er aktiv i skallen. Scriptet behøver ikke at eskalere. Det arver. - pull requestÆndringen er lille, testene er grønne, og differencen viser rimelige resultater. Den godkendes på under et minut, fordi der er fire flere, der venter.
Hver port du ejer, aktiveres efter trin tre. De første tre sker på en udviklermaskine på cirka halvfems sekunder.
8 lektioner fra tidlige brugere
Ud fra dokumenterede hændelser, publiceret forskning og de mønstre, der bliver ved med at dukke op i teams, der implementerede agentisk programmering, før nogen skrev en politik for det.
- Sprængningsradiusen er værktøjets overflade, ikke prompten Teams bruger uger på at hærde prompts og minutter på at beslutte, hvilke værktøjer en agent kan kalde. Det er det forkerte forhold. En agent, der kun kan læse, er en ulempe, når den er kompromitteret. En agent, der kan sende mails, forespørge produktion og pushe. commits er en hændelse, og den har udviklerens egne legitimationsoplysninger til at gøre det, fordi næsten ingen stiller en identitet til rådighed for en agent. Skriv værktøjslisten ned, før du skriver systemprompten.
- Agenten optimerer til at bestå testen, ikke til at koden fungerer. Med en fejlende suite og tilstrækkelig autonomi vil en agent slette assertionen, løsne betingelsen eller bytte en integration ud med en mock-integration og derefter rapportere succes. Alle teams anerkender dette i den første uge. Det er derfor grøn pipelines holdt op med at være bevis, og hvorfor gennemgangsspørgsmålet ændrede sig fra "virker dette" til "hvad ændrede det for at få dette til at bestå".
- Din regelfil er produktionskonfigurationen Filen, der styrer hver genererede linje, er normalt committed én gang og aldrig gennemgået igen. Den hører under ændringskontrol hos en ejer, en diff-anmelder og en person, der bemærker, når den vokser med en linje, som ingen husker at have tilføjet. Antag, at alt i den vil blive overholdt, inklusive det, du ikke kan se.
- Agentens afhængigheder er ikke dine afhængigheder Godkendte bibliotekslister antager, at et menneske har valgt det. En agent finder et plausibelt navn og installerer det, og installationsscripts udføres, før CI eksisterer. De teams, der blev brændt af, tilføjede en tjek på maskinen under installationen, ikke et politikdokument, der angiver, hvad udviklere bør foretrække.
- Ingen kan fortælle dig, hvad de kører Spørg fem ingeniører, hvilke MCP-servere og assistenter de bruger, og du får fem svar, hvoraf ingen er fyldestgørende. Undersøgelser fungerer ikke her, fordi værktøjerne installeres lokalt og ændres ugentligt. Opdagelsen skal komme fra koden, afhængighederne og de konfigurationsfiler, som værktøjerne efterlader.
- Hukommelsen holder på giften efter sessionen er slut En dårlig instruktion, der når persistent kontekst eller en agents hukommelse, udløber ikke, når opgaven gør det. Den fortsætter med at give afkast stille og roligt på tværs af urelateret arbejde, hvilket er grunden til, at hukommelses- og kontekstforgiftning har sin egen post i OWASP-agentlisten. Behandl agenthukommelse som en tilstand, der skal gennemgås og en måde at blive ryddet på, ikke som en bekvemmelighedsfunktion.
- Reversibilitet slår forebyggelse De teams, der kører mest autonomi sikkert, er ikke dem med den strammeste kontrol. Det er dem, der lavede fejl billigt: agenter flytter grene i stedet for hovedgrene, arbejder i engangsmiljøer, og hver handling har en fortrydelsesfunktion med én kommando. Autonomi er overkommelig i præcis samme grad, som det er at vende den om.
- Piloten lyver for dig Agenter ser fremragende ud på nye opgaver i små repositories og forringes i store, ældre kodebaser med implicitte konventioner. Et vellykket pilotprojekt overdriver produktivitetsgevinsten og underdriver risikoen og sætter derefter en forventning, som ingen kan opfylde i stor skala. Pilotprojekt på dit værste repository, ikke dit reneste.
Sådan ser det ud i praksis
Rækkefølgen er vigtigere end værktøjerne. Først opdagelse, fordi du ikke kan give adgang til agenter, du ikke har fundet. Derefter konfigurationslaget, fordi det er der, instruktionerne findes. Derefter slutpunktet, fordi det er der, agenten rent faktisk kører, og hvor en installation fuldføres længe før en pipeline meddelelser.
Xygeni AI-sikkerhed opdager alle AI-ressourcer i SDLC, inklusive modeller, agenter, agentservere, MCP-servere, datasæt, færdighedsfiler, prompts og guardrails ingen deklarerede, læser applikationskode, deklarerede afhængigheder og de konfigurationsfiler, som AI-værktøjer efterlader, og kortlægger derefter, hvordan de forbinder. Den registrerer de risici, der er specifikke for agentprogrammering: prompt injektion og systempromptlækage, ondsindede instruktioner og værktøjsinjektion i regler og færdighedsfiler, usikker MCP-konfiguration, overdreven agentur og manglende guardrails, hemmeligheder i AI-filer og sårbare eller overflødige AI-afhængigheder. Resultaterne knyttes til OWASP Top 10 for LLM-applikationer og peger på den nøjagtige fil og linje, og prioriteringstragten indsnævrer tusindvis af resultater til dem, der er i brug, tilgængelige, udnyttelige, privilegerede og forretningskritiske.
DevAI dækker den anden halvdel i editoren: den sikrer kode, som den er skrevet, gælder både for AI-genereret og menneskeskrevet kode, og opfanger, hvad andre agenter er ved at gøre, før de gør det. Den samme intelligens gælder for fund, der indtages fra de scannere, du allerede kører, så intet af dette kræver, at du erstatter det, du har.
Ofte stillede spørgsmål
- Hvad er den største risiko ved agentisk kodning? Overdreven handlefrihed. En agent med en bred værktøjsoverflade forvandler enhver vellykket injektion til en reel handling, og de fleste teams vurderer værktøjer langt mere løseligt end de vurderer mennesker.
- Er agentprogrammering sikker i regulerede miljøer? Ja, med en oversigt, begrænsede tilladelser, gennemgået konfiguration og håndhævelse ved slutpunktet. Det, der ikke kan forsvares i en revision, er ikke at vide, hvilke agenter der kører, hvad de når, eller hvilken kode de har forfattet.
- Producerer agentisk kodning mindre sikker kode end menneskekodning? Linjehastigheden kan sammenlignes med menneskelige fejl, men volumen er det ikke, og det er volumen, der overstyrer gennemgangen. Problemet er gennemløbshastigheden, ikke talentet.
- Skal vi forbyde AI-kodningsassistenter? Forbud flytter brugen under jorden, hvilket er værre. Skygge-AI er sværere at sikre end godkendt AI, og opdagelse er den kontrol, der rent faktisk ændrer billedet.
- Hvem er ansvarlig, når en agent sender en sårbarhed? Personen, der fusionerede det, præcis som før. Det er den ubehagelige del, og det er derfor, forfatterdata er vigtige: en korrekturlæser, der godkender maskinforfattede ændringer på maskinniveau, har brug for, at resultatet ankommer før godkendelsen, ikke efter.
- Hvordan starter vi, hvis vi slet ikke har nogen synlighed? Kør en discovery-funktion over dine repositories, angiv de MCP-servere og assistenter, den finder, og rangér agenter efter værktøjsoverflade. Den mest risikable agent er normalt ikke den, nogen var bekymrede for.
Agenter er allerede i dine lagre
Agentkodning findes allerede i dine arkiver, uanset om nogen har godkendt den eller ej. De teams, der håndterer det godt, er ikke dem med den strengeste politik. Det er dem, der på en given dag kan svare på, hvilke agenter der kører, hvad disse agenter kan nå, og hvad der er ændret i de filer, der styrer dem.
Se hvad dine agenter er forbundet til på Xygeni.
