TL;DR: agentseleteknikk og dens skjulte angrepsflate
Agentharness-teknikk er praksisen med å bygge alt rundt en AI-modell (instruksjoner, verktøy, tillatelser, minne og tilbakemeldingsløkker) som gjør den til en fungerende agent. Det er i den selen, ikke i modellen, at mesteparten av den reelle sikkerhetsrisikoen nå befinner seg.
- Skiftet: Teamene sluttet å finjustere ledetekstene og begynte å konstruere seler. Agent = modell + sele.
- Problemet: Selen ligger i klartekstfiler (regler, ferdigheter, MCP-konfigurasjoner) som blir gjennomgått som dokumentasjon, om i det hele tatt.
- Beviset: Bakdøren for regelfilen og ekte MCP CVE-er viser at angripere allerede retter seg mot den.
- Fiksingen: Behandle ledningsnettet som kode. Lag en inventarliste, gjennomgå det og skann det før det sendes.
Alle sikkerhetssamtaler om AI ender til slutt opp på modellen. Kan den jailbreakes? Vil den hallusinere? Trener leverandøren på dataene våre?
Greie spørsmål. Men de er i økende grad de gale. Når en AI-agent sletter en produksjonstabell, bruker en bakdør eller sender en kundeliste på e-post til en fremmed, er det sjelden modellen som feilet. Modellen gjorde akkurat det dens verktøykasse tillot den å gjøre.
Agent = modell + sele
I løpet av det siste året har bransjen i stillhet endret hva det vil si å bygge med AI. Rask konstruksjon ga vei til kontekstkonstruksjon, og kontekstkonstruksjon ga vei til noe større: agent sele engineering.
Ideen er enkel. En modell i seg selv er en resonneringsmotor uten hender. Selen er alt som gir den hender og en jobb: instruksjonene den følger, verktøyene den kan kalle, tillatelsene den har, minnet den beholder og kontrollene som fanger opp feilene dens. Martin Fowlers nettsted beskriver harness engineering som arbeidet som brukere av kodeagenter nå gjør for å gjøre agenter pålitelige, og en akademisk rammeverk publisert i år deler styringen inn i elleve ansvarsområder, fra verktøytilgang og prosjektminne til tillatelser og verifisering.
Resultatene er reelle. Team som praktiserer agentseleteknikk rapporterer at det å bare endre selen, med samme modell under, kan endre en agents resultater dramatisk. Dette reiser et ubehagelig poeng for alle i sikkerhetsbransjen: hvis selen bestemmer hvordan agenten oppfører seg, bestemmer selen hvordan den kan misbrukes.
Ta noe så vanlig som å installere en avhengighet. En utvikler tar en pause for å sjekke pakkenavnet. En agent med riktig verktøy kjører bare kommandoen, og hvis pakken er skadelig, vil ingenting i modellen stoppe den. Det er akkurat det vi pakker ut i denne episoden av SafeDev Talks: hva som endres når AI-agenter installerer avhengigheter på egenhånd, og hvorfor agentseleteknikk i det stille har blitt et problem i forsyningskjeden.
Hvordan agentharness-teknikk ser ut i et repositorium
Åpne et arkiv der utviklere bruker AI-agenter, og verktøyet er der, i filer du sannsynligvis aldri har skannet:
- Regler og instruksjonsfiler (
AGENTS.md,.cursorrules, Instruksjoner for copilot) som forteller agenten hvordan den skal oppføre seg. - Ferdighetsfiler den pakken med gjenbrukbare funksjoner laster agenten inn på forespørsel.
- MCP-serverkonfigurasjoner som kobler agenten til verktøy, databaser og API-er.
- Systemspørsmål og spørsmålsmaler innebygd i applikasjonskoden.
- Agentkabling: hvilke verktøy en agent kan nå, hvilke data den kan hente, og om det finnes et beskyttelsesrekkverk imellom.
Alt er ren tekst. Alt er commitsammen med kode. Og alt blir gjennomgått på samme måte som dokumentasjon blir gjennomgått: et raskt blikk, en godkjenning, en sammenslåing. Likevel kan hver av disse filene stille omskrive hva en agent er instruert til å gjøre og hva den har lov til å berøre.
Det er den virkelige konsekvensen av agentharness-teknikk: den kraftigste konfigurasjonen i programvaren din blir nå minst gjennomgått.
Angriperne har allerede lagt merke til det
Dette er ikke et teoretisk problem. Selen har en kort, men talende hendelseshistorie.
- Bakdøren for regelfilen. I mars 2025 avslørte forskere et angrep der skjulte Unicode-tegn i en regelfil instruerte AI-kodingsassistenter til å sette inn bakdørskode, uten å nevne det i sitt synlige svar. En anmelder som leste filen så ingenting uvanlig. Den er nå katalogisert som MITRE ATLAS casestudie AML.CS0041.
- Forgiftede MCP-verktøy. Frem til 2025 viste forskere gjentatte ganger at agenter stoler implisitt på verktøybeskrivelser, slik at en ondsinnet MCP-server kan styre en agent ganske enkelt ved å beskrive seg selv på riktig måte. Samme år, CVE-2025-6514 i en mye nedlastet MCP-klient tillot ekstern kommandokjøring ved tilkobling til en upålitelig server, vurdert til 9.6 på CVSS.
- Overdreven handlefrihet. Ocuco OWASP Topp 10 for LLM-applikasjoner lister overdreven handlefrihet som en topprisiko: agenter får flere verktøy, tillatelser eller autonomi enn oppgaven krever. Det er ikke en modellfeil. Det er en utforming av verktøylinjencision.
Legg merke til mønsteret. Ingen av disse angrepene ødelegger modellen. De ødelegger selen, og modellen gjør trofast resten.
Hvorfor sikkerhetsstakken din ikke ser den
Her kommer den vanskelige delen. De fleste organisasjoner bruker allerede gode AppSec-verktøy, og nesten ingenting av det ble bygget for dette laget.
Statisk analyse forstår kode, men den vet ikke hva en modell er eller hvorfor uklarert tekst som flyter inn i en systemledetekst er viktig. Komposisjonsanalyse lagerfører pakker, men den lister ikke opp MCP-servere eller ferdighetsfiler. Hemmelige skannere kan mangle en API-nøkkel som ligger i en agentkonfigurasjonsfil. Ingen av disse verktøyene er defekte. De ble rett og slett bygget for en verden der konfigurasjon ikke ga ordre.
Så agentens konstruksjon av kabelnett går raskt, og sikkerhetspersonalet gjennomgår den delen den kan se: modellen og koden. Kabelnettet faller midt imellom.
Fem vaner for å sikre selen
Utvikling av sikringsagentens harness-teknikk trenger ikke et nytt team. Det trenger noen vaner som behandler harnessen som det den er: utførbar intensjon.
| Vane | Hvorfor det betyr noe | Hva du skal gjøre |
|---|---|---|
| 1. Lagerfør alle seler | Du kan ikke sikre agenter som ingen har oppgitt. | Finn alle modeller, agenter, MCP-servere, ferdigheter og ledetekster på tvers av databasene dine, fra selve koden og konfigurasjonsfilene i stedet for fra en undersøkelse. |
| 2. Gjennomgå selefiler som kode | Regler, ferdigheter og MCP-konfigurasjoner kan omskrive hva en agent gjør, men de blir gjennomgått som dokumentasjon. | Gi dem det samme pull request gransking som applikasjonslogikk, inkludert kontroller for skjulte tegn. |
| 3. Fest det agenten laster inn | En ledetekst eller modell som det refereres til av en endringsbar etikett, kan ompekes uten en kodeendring. | Fest ledetekster og modeller til uforanderlige versjoner. |
| 4. Sett et rekkverk på hver vask | Hentede dokumenter, verktøyutdata og brukerinnhold kan alle føre injiserte instruksjoner til modellen. | Plasser et rekkverk i stien der innholdet kan nå modellen. |
| 5. Hold legitimasjon unna selen | AI-leverandørnøkler i promptfiler og agentkonfigurasjoner er en enkel seier for en angriper. | Fjern dem og fortsett å skanne selefiler for hemmeligheter. Det er en enkel løsning. |
Sikring av selen, ikke bare modellen
Xygeni AI-sikkerhet starter der agentharness-utvikling setter sitt fotavtrykk: i databasene dine. Den oppdager AI-ressursene på tvers av kodebasen din (modeller, agenter, MCP-servere, ferdigheter, ledetekster, guardrailsog AI-kodingsverktøyene som er i bruk) fra kode, avhengigheter og konfigurasjonsfilene disse verktøyene etterlater seg.
Deretter analyserer den ferdighetsfiler, regelfiler og MCP-konfigurasjoner som sikkerhetsartefakter, ikke dokumentasjon, og oppdager risikoer knyttet til promptinjeksjonsklassen i agentkabling, for eksempel upålitelig innhold som når en systemprompt eller en hentevask uten beskyttelsesrail. Xygenis hemmelighetsskanning flagger legitimasjonsinformasjon for AI-leverandører i prompter og agentkonfigurasjonsfiler, og avhengighetene til AI-stakken din får samme skadelig programvaredeteksjon som alt annet, før en signatur finnes.
FAQ
Hva er agentseleteknikk?
Agentharness-teknikk er fagfeltet som utformer miljøet rundt en AI-modell (instruksjoner, verktøy, tillatelser, minne, kontekst og verifiseringsløkker) slik at den oppfører seg som en pålitelig agent. Modellen gir resonnement; harnessen bestemmer hva agenten kan se og gjøre.
Hvordan er agentharness-teknikk forskjellig fra prompt-teknikk?
Prompt-utvikling former en enkelt instruksjon. Agentharness-utvikling former hele systemet agenten opererer i, på tvers av mange trinn, verktøy og økter. En prompt er én fil i harnessen.
Hvorfor er selen en sikkerhetsrisiko?
Fordi den kontrollerer hva en agent har lov til å gjøre, og den ligger i klartekstfiler som sjelden blir vurdert som sikkerhetsartefakter. Hvis du kompromitterer en regelfil eller en MCP-konfigurasjon, kontrollerer du agenten uten å berøre modellen.
Hvem bør eie agenten utnytte sikkerheten?
Applikasjonssikkerhet, samarbeid med ingeniørene som bygger og konfigurerer agenter. Selen er en del av programvaren du leverer, så den hører hjemme i de samme gjennomgangs-, skannings- og lagerprosessene som resten av koden din.
