TL; DR
Tre svar på det samme spørsmålet om agentisk AI-risiko
Vi forventet bred enighet om å begrense bruken av AI-agenter, og fikk tre forskjellige svar.
- Pedro Fortuna: dele opp agenter i mange små, spesifikke agenter, hver med de smalest mulige tillatelsene, og legge til kjøretidsovervåking som stopper dem tidlig.
- Jack Trefon: Det motsatte, for kodende agenter. Begrens én, og du ødelegger det som gjør den nyttig, så aksepter eksplosjonsradiusen og invester i sporing og rask gjenoppretting.
- Luis Rodríguez Berzosa: en tredje linje. Behandle frontmodeller slik du ville behandlet skadelig programvare, design verktøyet for å begrense hver spesialisert agent, og legg et håndhevingslag under alt som holder når alt over feiler.
Der alle tre møttes: Du kan ikke beskytte det du ikke har registrert, hver handling må loggføres, og det som stopper en agent må sitte utenfor agenten.
Ingenting ble brutt.
Agenten gjorde jobben sin. På veien bestemte den seg for at den måtte røre en avhengighet, en konfigurasjon, en tjeneste ingen ba den om å røre. Den holdt seg innenfor tillatelsene sine hele tiden. Ingen regler ble brutt, så ingenting ble utløst.
Vi la saken frem for tre personer som jobber med den profesjonelt, og forventet bred enighet om hva vi skulle gjøre med den. Vi fikk tre forskjellige svar, og to av dem motsier hverandre.
Agentisk AI-risiko blir vanligvis beskrevet som et angriperproblem. Dette er den andre versjonen. I tjue år tegnet vi tillatelsesgrenser rundt programvare som gjorde akkurat det den fikk beskjed om. En tjenestekonto, en CI-løper, en planlagt jobb. Vi traff grensen feil ofte nok, men tingen inni den var forutsigbar. Den gjorde én jobb, på samme måte, hver gang.
Det som er innenfor grensen bestemmer nå. Og grensen tegnes fortsatt slik den alltid har vært: på forhånd, ved konfigurasjonstidspunktet, av noen som ikke kan vite hva oppgaven vil bli.
Det er den versjonen av agentisk AI-risiko som er verdt å diskutere, og vi brukte en time på det sist. SafeDev-snakk med Pedro Fortuna av Jscrambler, Jack Trefon fra Trefon Digital Consulting, og Luis Rodríguez Berzosa av Xygeni, arrangert av Alejandro Estrada.
Vi forventet at de stort sett ville være enige. Det var de ikke.
Agentisk AI-risiko: den trøstende forutsetningen som ikke holder
Innrammingen ovenfor har et ord i seg som gjør mer arbeid enn det burde: angriperDet finnes ikke en. Det skal visstnok gjøre scenariet enklere.
Pedro tok det fra hverandre i ett trekk.
«Å være en angriper eller ikke er et menneskelig konsept. Det som gjør en angriper til en angriper er at vedkommende har andre mål. Og en feiljustert agent er også noe som har et annet mål.»
Sitt med det, for det demonterer premisset for de fleste samtaler om agentisk AI-risiko, inkludert beskrivelsen vi skrev for vår egen hendelse. Hvis det som definerer en angriper er divergerende mål snarere enn ondskap, så er «det er ingen angriper i denne historien» en trøst ingen har fortjent. Strukturelt sett er det den samme risikoen. Det som mangler er intensjon, og intensjon var aldri det kontrollene dine oppdaget. De oppdager effekter. Det har de alltid gjort.
Dette er også grunnen til at bransjens vokabular har endret seg. OWASPs Topp 10 for LLM-søknader i 2026 fremmet overdreven handlefrihet fra sjetteplass til tredjeplass, noe som er mindre en meningsendring enn at hendelseshistorikken tar igjen en arkitektur som allerede var implementert.
Hva Hugging Face-hendelsen faktisk viser
Hendelsen i juli, der en modell fra frontlinjen angrep en tredjepart, ble lest mye som en historie om en modell som gikk på avveie. Luis leser det annerledes, og hans versjon plasserer ansvaret på et ubehagelig sted.
«Problemet er ikke grensemodellen. Grensmodellen gjorde det den ble bedt om å gjøre. Problemet er utformingen av eksperimentet.»
Målet var åpent. Restriksjonene var fraværende. Og sandkassen som var ment å inneholde det hadde et vindu til internett, gjennom en sårbarhet for forespørselsforfalskning på serversiden i pakkebufferen som agenten kunne nå. Hver og en av disse er en designutvikling.cision laget av en person.
Som produserer setningen som skal endre hvordan du klargjør disse tingene:
«Grensemodeller må sees på som om de var skadelig programvare, fordi de kan handle autonomt og ta avcisioner som er ondsinnede. Ikke med hensikt, men de er virkelig ondsinnede til syvende og sist.»
Ikke som en fornærmelse mot modellen. Som en klargjøringsposisjon. Du gir ikke skadevare et bash-shell og håper at målet var godt spesifisert.
Pedros tolkning av den samme hendelsen handlet om timing snarere enn design:
«I det øyeblikket du ser agenter kommunisere via mappenavn på en tjeneste de ikke burde bruke, i det øyeblikket må du stoppe disse agentene. Du trenger ikke å vente på at disse agentene skal bryte seg inn i Hugging Face for å avgjøre om det er skadelig eller ikke.»
En detalj fra responsen er også verdt å ta vare på. Responsorene prøvde å bruke et kommersielt agentverktøy for å analysere sporene, men klarte det ikke fordi de traff hastighetsgrensene. Angriperen hadde ingen slik grense. «Det var en asymmetri i selve angrepet.»
Det faktiske argumentet: begrense agenten, eller komme seg raskere?
Her splittet panelet seg, og det er en reell uenighet mellom utøvere som alle har fortjent sin posisjon.
Pedro argumenterer for nedbrytning. Femten år med å presse isolasjon inn i nettleseren lærte ham at man ikke kan håndheve noe under kjøring mot en monolitt. Bryt arkitekturen opp i små biter med spesifikke funksjoner, og først da har kontroller og overvåkingspunkter et sted å koble til. Agenter er ikke annerledes.
«Jeg tror man må dele det opp i veldig spesifikke agenter som bare er ment for spesifikke oppgaver. Og det spiller ingen rolle om man ender opp med femti agenter. Det er bedre enn å bare ha én.»
Jack argumenterer for det motsatte, spesifikt for kodeagenter. Man skulle forvente at en bakgrunnsbasert teknologi på en regulert kryptobørs ville produsere den mest restriktive posisjonen i rommet. Den produserte minst.
Hans utgangsanalogi er ikke en trusselmodell i det hele tatt:
«Jeg ser på en typisk agentutplassering akkurat som jeg ville sett på en nyansatt, en ny person som kommer inn. Og den personen kan være feilfri i utførelsen, eller det kan hende det blir gjort en feil. Jeg ser ikke så stor forskjell.»
For smale agenter er han like streng som alle andre. Han beskrev en skrivebeskyttet gjennomgangsagent han for tiden bygger, og sa direkte at det vanlige oppsettet er uforsvarlig: å distribuere på en vanlig Linux-boks med bash-tilgang «åpner opp hele økosystemet av trusler». Men for generelle kodeagenter er logikken snudd på hodet, og han vet at posisjonen er upopulær:
«Jo mer makt agenten har, desto mer kreativ og effektiv er den. Så det er ikke bransjen som blomstrer på grunn av begrensninger og krymping av omfanget.»
Så hva blir igjen hvis man ikke begrenser? Sikringsbrytere, og fremfor alt tidsbaserte øyeblikksbilder: ikke å forhindre eksplosjonsradiusen, men å gjøre gjenoppretting fra den billig og rask. Han bygger det inn i Rav, en avhengighetsfri C++-agentkabel han skriver på fritiden, med snapshotting i løkken (prosjektsted).
Og advarselen om hvor den andre veien ender:
«Hvis vi begynner å ta bort, vil det bare være ett verktøy igjen, og den utvikleren vil kunne slå på lyset og slå av lyset.»
Luis tar en tredjeplass, som verken begrenser eller gjenoppretter, men inneholder nedenfra: anta at agenten til slutt vil oppføre seg som skadelig programvare, design selen for å begrense hver spesialisert agent, og legg et håndhevingslag under alt som holder når alt over det feiler.
Tre tilnærminger til det samme problemet
Tre stillinger, hver med en kostnad knyttet til seg. Ingen av dem er gratis, og ingen av dem gjør agenten trygg i seg selv.
| Tilnærming | Kjernebevegelse | Hva det koster deg |
|---|---|---|
| DekomponerePedro Fortuna | Mange små agenter, hver med smale tillatelser, pluss kjøretidsovervåking som stopper dem tidlig | Designinnsats på forhånd, og en vanskeligere tid med åpent kodearbeid |
| GjenoppretteJack Trefon | Behold kapasiteten, legg til effektbrytere og tidsbaserte øyeblikksbilder slik at tilbakerulling blir billig | En større eksplosjonsradius, og en innsats på å oppdage og angre det i tide |
| Inneholder nedenfraLuis Rodríguez Berzosa | Anta atferd fra skadelig programvare, begrens hver agent i selen, håndhev under den på arbeidsstasjonen og CI-løperen | Infrastruktur og verktøy som de fleste endepunktstakker ikke tilbyr ennå |
Når man leser dem side om side, er uenigheten smalere enn den høres ut. Alle tre aksepterer at agenten vil gjøre noe utilsiktet. De er uenige om hvor pengene går: inn i arkitekturen før det skjer, inn i gjenopprettingen etter at det skjer, eller inn i et gulv under begge.
Hvorfor minst privilegium ikke oversettes til agentisk AI-risiko
Minste privilegium forutsetter at du kjenner jobben. Du gir tillatelsen omfang til oppgaven.
En agent bryter det stille, fordi tillatelsesgrensen tegnes ved konfigurasjonstid og oppgaven ankommer under kjøretid. Det du faktisk gir er foreningen av alt den noen gang kan bli bedt om å gjøre. Det er ikke minst privilegium; det er det motsatte, å bruke minst privilegiums klær.
Luis foreslo en omformulering lånt fra en idé som er eldre enn noe av dette:
«Jeg tenker på UNIX-mekanismen med piping, der man kobler sammen enkle verktøy for å utføre en kompleks oppgave. Man kan definere spesifikke agenter med en kontrollert konfigurasjon, noe som begrenser hva den spesialiserte agenten kan gjøre. Og man kan kombinere dem for nesten enhver oppgave.»
Pluss en annen designidé de fleste team ikke har prøvd: pakk inn verktøyene i stedet for å utvide tillatelsene. Ikke bash, som overleverer hele systemet, men en smal innpakning som er den eneste kallbare banen, med skrivebeskyttede varianter som pakker inn generiske. Agenten får en funksjon, ikke et skall.
Han var også tydelig på at hindringen ikke er designet, men utrullingen. Nye kontroller på utviklermaskiner har en lang historie med å bli omgått, og den historien endrer seg ikke fordi det aktuelle verktøyet er en agent.
Og om hvor han tror det hele ender:
«Jeg tror at vi til slutt vil ha autonome agenter som kontrollerer andre autonome agenter.»
Den bærbare datamaskinen ble kronjuvelen, og EDR-en din har ikke lagt merke til det
En agent trenger permanent tilgang for å være nyttig. Et token som ikke utløper midt i en oppgave, en bufret legitimasjon, push-rettigheter, registertilgang, en live-sti inn i pipelineHver og en av disse er et krav snarere enn en forglemmelse, som betyr at jo bedre verktøyet ble, desto mer konsentrert ble fremkallermaskinen.
Angriperne la merke til det først. Som Pedro sa det, de er ikke ideologer:
«De organiserer seg som små selskaper. De må tjene penger, så de beveger seg mot den mest lønnsomme vinklingen de kan finne. Og de så raskt at det var penger å tjene på utviklingsstasjoner.»
Vi ser at det skiftet havner i registrene hver uke i Sammendrag av skadelig kode, der legitimasjonsinnhøstere nå rutinemessig jakter på AI-leverandørnøkler ved siden av sky- og registernøkler.
Tiltakslisten hans er lite glamorøs og fungerer: fjern alle nøkler som ikke trenger å være på maskinen, par de som er igjen med en annen faktor som OpenID Connect eller en maskinvarenøkkel, slik at en stjålet token ikke er nok alene, og flytt miljøet bort fra verten der du kan, gjennom utviklercontainere eller sky-IDE-er.
Så kom Luis med poenget som burde bekymre alle som antar at endepunktstakken deres dekker dette:
«EDR-ene er spesialisert på tradisjonell skadelig programvare og er ikke klar over agentverktøy. Og hvis de fungerer, kan de generere mange falske positiver, fordi agenten gjør ting som deteksjonsmønstrene ikke er klar over per i dag.»
To feilmoduser samtidig: den går glipp av det som er viktig og flagger det som ikke er viktig. Svaret hans er det ytre håndhevingslaget, som ligger rundt utviklerens arbeidsstasjon og CI-løperen, under selen, og begrenser hva en useriøs agent kan nå. Det er gapet. Xygeni Shield ble bygget for, med policy håndhevet på endepunktet der installasjonen faktisk skjer.
Jack sa det mer rett ut: ikke oppbevar Bitcoin på utviklermaskinen din.
Gulvet alle tre var enige om
Tre forskjellige svar, ett delt minimum.
- Inventar først. «Du kan ikke beskytte det du ikke vet om.» Alle andre decision er avhengig av å vite hvilke agenter, ferdigheter og MCP-servere som finnes, og nesten ingen av dem ble deklarert.
- Logg hver handling. Jack og Luis kom hit fra motsatte retninger. Jack vil ha spor fordi det er slik man gjenoppretter seg og hvordan en organisasjon modnes. Luis vil ha dem fordi uten dem kan man ikke rekonstruere eksplosjonsradiusen etterpå. Jacks innramming er verdt å låne: det er ingen verdi i å avhøre aktøren, menneske eller agent, bare i å forstå konteksten godt nok til ikke å gjenta den.
- Det som stopper en agent må sitte utenfor agenten. Pedros kjøretidsovervåking, Luis' håndhevingslag, Jacks effektbrytere og øyeblikksbilder. Ulike mekanismer, ett prinsipp.
Jack ga en nyttig beskrivelse av hvor bransjen er på kurven. Han husker den første spam-e-posten han mottok, som fortalte ham at han hadde arvet en gullgruve i Nigeria. Dette er et modenhetsproblem, og modenhet kommer etter feilene snarere enn før dem.
Hva du bør gjøre før fredag
Velg én agent. Skriv ned to lister: hva den har lov til å gjøre, og hva den faktisk ble bedt om å gjøre denne uken.
Avstanden mellom disse listene er eksplosjonsradiusen din, og det er det mest nyttige målet på agentisk AI-risiko teamet ditt kan produsere på en ettermiddag. Det tar en ettermiddag, det trenger ikke noe budsjett, og det avgjør argumentet ovenfor for din egen organisasjon, fordi de tre posisjonene egentlig er tre forskjellige svar på spørsmålet om hvor stort det gapet bør være.
De fleste lag har aldri skrevet det ned.
Ocuco en hel time er tilgjengelig for tilbakesyn, inkludert Jacks poeng om hvorfor krav til «menneskelig informasjon i loopen» i Europa gjør noen AI-forsvar umulige i praksis.
Og hvis øvelsencise returnerer et svar du ikke liker, Xygeni oppdag alle AI-ressurser på tvers av databasene dine, inkludert agenter, ferdigheter og MCP-servere som ingen har deklarert, og kartlegg hva hver enkelt kan nå. Kontakt or start gratis, og vi kjører den hos deg.
FAQ
Hva er eksplosjonsradiusen til en AI-agent?
Alt agenten kunne nå hvis det gikk galt, i motsetning til hva den ble bedt om å gjøre. Det er definert av tillatelsene, legitimasjonene og verktøyene som er tilgjengelige for den under kjøring, ikke av oppgaven. Gapet mellom disse to er det som er verdt å måle, og de fleste team har aldri skrevet det ned.
Er en agent som overskrider oppgaven sin en sikkerhetshendelse hvis den aldri overskred tillatelsene sine?
Det var den sentrale uenigheten. Pedros svar er i praksis ja, fordi en angriper defineres av måldivergens snarere enn ondsinnet hensikt, og en feiljustert agent har divergert. Jacks svar er nærmere nei: det er en operasjonell svikt som en nyansatts feil, og den riktige responsen er sporing og gjenoppretting snarere enn strengere begrensninger. Luis omgår spørsmålet ved å anta verst tenkelige scenario fra starten av og spørre hvilket lag som fortsatt gjelder når det skjer.
Bør kodeagenter være sandkassebaserte?
For smale, oppgavespesifikke agenter sa alle tre ja uten å nøle: skrivebeskyttet der det var mulig, ingen bash, ingen nettverk med mindre det var nødvendig. For generelle kodeagenter delte panelet seg på tre måter: Pedro ville dekomponere dem, Jack ville beholde funksjonaliteten og snapshot-et aggressivt, og Luis ville legge til et håndhevingslag under selen uavhengig av hva agenten har lov til å gjøre.
Dekker EDR-en min risikoen knyttet til agentbasert AI?
Sannsynligvis ikke bra. Nåværende endepunktverktøy er bygget rundt tradisjonelle malware-mønstre og modellerer ikke agentoppførsel, så de har en tendens til å overse det som er viktig og flagge det som ikke er det. Luis' svar var et ytre håndhevingslag designet for utviklermiljøer i stedet for en generell EDR.
Hva er det aller første man bør gjøre?
Bygg inventaret. Hver modell, agent, ferdighet og MCP-server i repositoriene dine, og hva hver enkelt kan nå. Det er det ene trinnet alle tre paneldeltakerne nevnte, og det eneste som alle andre kontroller er avhengige av.
