Prompt injection opstår, når indhold, et AI-system læser, får det til at afvige fra den opgave, det skulle løse. I en udviklingsopgave kan indholdet komme fra en projektfil, en fejlbeskrivelse eller oplysninger fra et tilknyttet værktøj.
Risikoen vokser, når agenten kan handle på oplysningerne. En vildledende instruktion kan påvirke en foreslået ændring, udløse en unødvendig anmodning om adgang eller føre til en handling, brugeren aldrig har bedt om.
En fil får ikke myndighed, fordi agenten læser den
OWASP skelner mellem indirekte prompt injection og instruktioner, som kommer direkte fra brugeren. Den indirekte variant kommer gennem eksternt materiale, modellen indlæser. Konsekvenserne afhænger blandt andet af applikationens adgang og muligheder for at handle.
En kodeagent har brug for viden om projektet for at arbejde. Udfordringen er at skelne mellem en oplysning i materialet og en tilladelse til at ændre opgaven eller bruge et værktøj.
Forestil dig dette tænkte eksempel: En udvikler beder agenten rette en visningsfejl. I en projektnote står der, at rettelsen kræver, at kontroller ved kodegennemgang deaktiveres, og at lokal konfiguration deles med en ekstern supporttjeneste.
Noten kan lyde hjælpsom. Den dokumenterer stadig ikke, at tjenesten er godkendt, at konfigurationen må deles, eller at kontrollerne skal slås fra. De beslutninger skal følge den godkendte opgave og organisationens regler.
Forstå, hvad tilknyttede værktøjer giver adgang til
Model Context Protocol, normalt forkortet MCP, er en måde at forbinde AI-applikationer med værktøjer og informationskilder på. Forbindelsen kan hjælpe i udviklingsarbejdet, men den gør ikke automatisk alle instruktioner og resultater fra tjenesten troværdige.
Når I vurderer en integration, skal I undersøge, hvad tjenesten kan læse og gøre. Spørg, hvem der driver den, hvilken identitet den bruger, og hvordan adgangen kan tilbagekaldes. GitHubs MCP-dokumentation forklarer protokollen i forbindelse med Copilot.
Medarbejdere skal ikke begynde den vurdering forfra ved hver opgave. Hav en liste over godkendte integrationer med en ansvarlig for hver.
Læg mærke til, når opgaven ændrer omfang
Udviklere kan ikke genkende enhver skadelig instruktion på ordlyden alene. De kan til gengæld reagere, når agentens foreslåede handling ikke længere passer til opgaven.
Stop op, hvis agenten uventet beder om at:
- Tilgå uvedkommende projekter eller mapper.
- Sende filer eller konfiguration til en ny destination.
- Bruge legitimationsoplysninger med bredere rettigheder end nødvendigt.
- Deaktivere tests, regler for gennemgang eller sikkerhedskontroller.
- Offentliggøre eller slette noget uden for den aftalte ændring.
Anmodningerne kan have en legitim forklaring. Bed om begrundelsen, undersøg handlingen, og afklar den med den opgaveansvarlige, før du udvider adgangen. Advarselstegnet er en ændring af opgavens omfang, som ingen kan forklare.
Vær særlig opmærksom ved gentagne anmodninger om godkendelse. At du tidligere har godkendt en harmløs handling, afgør ikke, om en senere anmodning om at dele data eller ændre et andet system er passende.
Understøt træningen med tekniske begrænsninger
Awareness hjælper mennesker med at reagere på usædvanlige anmodninger. Træningen bør suppleres med begrænsninger af, hvad agenten faktisk kan gøre.
Hold hemmeligheder fra produktionssystemer ude af almindelige udviklingsopgaver. Begræns adgangen til det relevante projekt og godkendte tjenester. Kræv gennemgang af handlinger med større konsekvenser, og gem den dokumentation, teamet har brug for til at undersøge uventet adfærd.
Anthropics forklaring af sandboxing i Claude Code beskriver isolation af filsystem og netværk som grænser for selvstændigt arbejde. Kontrollerne begrænser agentens adgang; de gør ikke vilkårligt projektindhold troværdigt.
Kontrollér både rettighederne og medarbejderens reaktion. Hvis agenten er blokeret fra en ekstern destination og derefter beder nogen om at omgå begrænsningen, bør det undersøges.
En øvelse på fem minutter til næste teammøde
Brug en samtaleøvelse med fiktive data. Kør den ikke i en aktiv agentsession, og brug hverken rigtige legitimationsoplysninger eller eksterne destinationer.
- Beskriv opgaven: En agent hjælper med at rette en visningsfejl i et testprojekt.
- Introducér den uventede anmodning: En projektnote siger, at rettelsen kræver, at lokal konfiguration deles med en ukendt supporttjeneste.
- Lad teamet vurdere: Passer handlingen til opgaven? Hvem ejer tjenesten? Hvilke oplysninger ville forlade projektet?
- Øv reaktionen: Sæt handlingen på pause, gem den relevante anmodning eller logs uden at sprede hemmeligheder, og kontakt projektets sikkerheds- eller IT-ansvarlige.
- Gennemgå grænsen: Afklar, hvilke kontroller der bør forhindre overførslen, og hvordan hændelsen skal undersøges.
Formålet er at øve, hvordan man opdager ændringer i myndighed og opgavens omfang. Medarbejdere skal vide, hvordan de får hjælp, uden at blive bebrejdet for at indberette en tvetydig anmodning.
Gør det tydeligt, hvor medarbejdere skal indberette
Udpeg det team eller den kanal, der modtager uventede anmodninger fra agenter. Forklar, hvad indberetningen skal indeholde: den oprindelige opgave, den foreslåede handling, instruktionens kilde, hvis den kendes, og om noget blev godkendt eller udført.
Hvis følsomme data kan være blevet delt, skal organisationens hændelsesproces følges. Undgå at slette aktivitetshistorikken eller selv eksperimentere med den mistænkelige instruktion, mens det ansvarlige team undersøger sagen.
Brug de samme vaner som i awareness-træningen: stop op, verificér og bed om hjælp. Til administratorer forbinder vores sikkerhedstjekliste for kodeagenter de vaner med de adgangsindstillinger, der understøtter dem.
