OWASP Agentic Top 10 [Part 2], az utolsó öt kockázat (AI Security Ops #72)¶

Podcast: AI Security Ops (BHIS, Black Hills Information Security) Epizód: #72 — OWASP Agentic Top 10 [Part 2] Dátum: 2026-10-02 Hossz: ~27:07 (1627 sec) Házigazdák: Brian Fehrman, Bronwen Aker Vendég: nincs (házigazda-páros beszélgetés) Platform: Transistor.fm Epizód link: https://share.transistor.fm/s/92ba0d79 MP3: https://media.transistor.fm/92ba0d79/e4d20cfa.mp3 Transcript: Transistor natív, emberi átirat — 4074 szó, beszélő-címkékkel (Brian Fehrman, Bronwen Aker), 0 hallucináció

Bevezetés és a lényeg¶

Az epizód az OWASP Agentic Skills Top 10 lista második felét járja végig: AST06–AST10. A Part 1 (E70) az első öt kockázatot tárgyalta. A házigazdák itt is azzal kezdik, amivel a sorozat minden darabja: mi is az a skill. Bronwen definíciója tömör:

„A skill is a set of predefined instructions that inform an AI of a specific task or process that they are supposed to achieve.”

Brian a recept-hasonlatot erősíti meg: a skill összegyűjti azokat a lépéseket és komponenseket, amik működnek, hogy ne kelljen minden alkalommal újra kitalálni. A hozzáadott érték a finomítás és a kivételek rögzítése: a modell kimenete szerinte gyakran „95%-ban jó”, és a maradék 5% korrekcióját spórolja meg a skill, nem újra beírni ugyanazt a visszajelzést.

A lista utolsó öt eleme a közös szál mentén olvasható: mindegyik arról szól, hogy a skill-ök körüli üzemeltetési réteg hiányzik. Nincs izoláció, nincs pinnelés, nincs szkenner, nincs leltár, nincs szabvány. Ez a diagnózis jóval kevésbé technikai, mint az első öté, és épp ezért a házigazdák kritikája is élesebb: több elem a hagyományos IT-gyakorlat átnevezése, nem új kockázat.

A hivatalos súlyossági besorolás (az OWASP oldaláról ellenőrizve):

AST06. Weak Isolation (High): a skill az agent teljes biztonsági kontextusában fut, sandbox nélkül, minden skill egy lehetséges teljes rendszert érintő kompromittálódás.
AST07. Update Drift (Medium): pinnelés és verifikáció nélkül a skillek csendben elcsúsznak sebezhető, vagy frissen rosszindulatú verziókra.
AST08. Poor Scanning (Medium): a természetes nyelv és a kód keveréke megkerüli a szignatúra-alapú szkennereket, így a rosszindulatú skillek átmennek minden automatizált ellenőrzésen.
AST09. No Governance (Medium): nincs leltár, jóváhagyási folyamat, visszavonási mechanizmus vagy auditnyom, „shadow AI” réteg a biztonsági csapat látókörén kívül.
AST10. Cross-Platform Reuse (Medium): a skilleket platformok között portolják anélkül, hogy a forrásformátum biztonsági tulajdonságai átfordulnának.

Összegzés¶

Öt legfontosabb take-away a beszélgetésből:

Az AST06 fogalmi keveredést tartalmaz, és a házigazdák szerint a javasolt védekezés nehezen értelmezhető. Brian szerint az OWASP „összemosása” a skilleket az agentekkel: a skill nem futtató, hanem betöltött kontextus. Sandboxolni egy subagentet lehet (saját jogosultságokkal), egy betöltött kontextust önmagában nem. Bronwen egyetlen gyakorlatias megoldást lát: fizikailag külön eszköz az LLM-nek és a skilleknek.
Az AST07 valódi, és a verzió-pinnelés kétélű fegyver. A pinnelés megvéd a frissen rosszindulatú verzióktól, de befagyasztja a sebezhető verziót is: Brian megfogalmazásában ha a skill olyan eszközre hivatkozik, amit pinneltél, és abban később hibát találnak, a skilled a sebezhető verzióra mutat. A pinnelés ugyanazt a patch-kihívást hozza be, mint a hagyományos IT.
Az AST08 és az AST09 valójában egy dolog két oldala. Nem lehet patch-elni azt, amiről nem tudod, hogy létezik, vagyis a szkennelés (AST08) és a leltár (AST09) ugyanannak a hiányzó üzemeltetési rétegnek a két funkciója. Bronwen szerint ez code review új néven, Brian szerint új szolgáltatás lesz belőle: „skill reviews”.
Az AST09-nél a governance-t nem a technológia, hanem az ütem hiúsítja meg. Bronwen tapasztalata: a frontier-szolgáltatók felhőbe tolják a skilleket, az eszközök pedig naponta többször változnak (nála volt, hogy egy 8 órás periódusban három frissítés). A szabályok szándéka megvan, de „nincsenek valódi szabályok”, és a governance-t mindig magára hagyják, a határokat utólag már nem lehet meghúzni.
Az AST10 a szabványok hiányát nevezi meg, és a házigazdák szerint ez a legnehezebb. A SKILL.md platform-specifikus, a frontier-modellek pedig „kisbabák a bölcsődében”: ha az egyik csinál valamit, a másik követi. A hasonlatok (celluláris töltőkábelek és autók) pontosan azt mutatják, mennyi ideig tart, amíg egy szabvány kialakul. Bronwen szerint legalább fél év, de lehet több, mire bármi hasonló megszületik.

AST06. Weak Isolation: „összemosás”, és a sandboxolás gyakorlati korlátja¶

Brian rögtön jelzi a fenntartását: az OWASP megfogalmazása szerint a skill az agenttel azonos biztonsági kontextusban fut, és ezt ő fogalmi keveredésnek tartja.

„This one confused me a little bit because I feel like it's conflating skills with agents a little bit. Because to me, a skill is more of, like, it's a context that the agent loads.”

A megkülönböztetés lényeges, mert a védekezés is más: egy subagent kaphat saját jogosultságkészletet, mit tehet és mit nem, mihez férhet hozzá és mihez nem. Egy betöltött kontextus önmagában nem sandboxolható el az őt betöltő agenttől.

Bronwen egyetért, és a gyakorlati oldalt emeli ki: a legtöbb felhasználó felhős inferenciát vagy API-t használ, vagy lokálisan futtat, a skillek mindkét esetben a hoston tárolódnak. Nem látja, hogyan lehetne ezt a gyakorlatban izolálni.

érti az izoláció iránti igényt, és történelmi analógiát hoz:

„Just as we've seen with macros, VBA scripts, all the way back to bat files, there are ways that these scripts can definitely shoot us in the collective foot.”

A különbség szerinte a fekete doboz: rengeteg minden történik az AI-ban olyan rétegben, ami fölött nincs kontrollunk. Az egyetlen járható útnak azt látja, ha az LLM az egyik fizikai eszközön van, a skillek és agentek pedig egy másikon.

Brian is elismeri, hogy az aggodalom jogos, a sandboxolás szerinte a teljes rendszerre értelmes, nem a skill-komponensre önmagában.

A beszélgetés itt átfordul a fejlődési ütem kérdésébe, ami az egész epizód visszatérő motívuma lesz:

„All of this AI stuff is still very much a new frontier. And no matter what people may say, we are all making it up as we go along.”

Bronwen konkrét mértéket ad: a Claude desktop appnál egyszer három frissítést kapott egyetlen nyolcórás periódusban. Nem mind bugfix, és ha mindegyik hoz egy új funkciót, az a saját tanulási görbéjét növeli. Brian: „breakneck pace”.

AST07. Update Drift: két külön probléma, és a pinnelés két éle¶

Brian kettébontja a kategóriát, mert szerinte két különböző dolog van benne összevonva:

A telepített skill elavul. Telepítesz egy skillt, később sebezhetőség keletkezik valamiben, amit hív vagy amit tesz, és nem kap foltot.
Az automatikus frissítés elcsúsztatja a skillt attól, amit eredetileg akartál, ha egy repóból húzod és automatikusan követed a frissítéseket.

Brian a másodikat tartja általánosabbnak, és nem csak biztonsági okból:

„Having those grab down the latest and greatest versions every time — realize that's an absolutely horrible idea, because basically, every time you go to run these automated setups, you don't know if it's gonna work or not.”

A saját automatizált setup-jaik tapasztalatából mondja: a verzió-pinnelés önmagában jó gyakorlat, függetlenül a biztonságtól.

Bronwen ehhez teszi a supply chain dimenziót: a harmadik féltől származó könyvtárak és erőforrások sokkal gyakoribb célpontok, mint tíz évvel ezelőtt. A pinnelés ad egy ellenőrzési pontot: mielőtt egy új verziót bevezetsz, van alkalmad megnézni, van-e benne rejtett payload. A másik oldal viszont: ha nincs patch-folyamat, és az AI-t nem foldoltad be abba, akkor eltávolodsz a legitim, foltozott, megerősített verzióktól.

Brian itt tesz egy éles megfigyelést, ami a pinnelés önmagában vett elégtelenségét mutatja:

„What if within your skill, your skill references tools, and you version pin those tools that the skill references. But now those version pinned tools have a vulnerability, and your skill references those vulnerable versions.”

Bronwen szerint ez ugyanaz a patch-probléma, amit a hagyományos IT-ban is ismerünk, „worked fine this week, next week it's got 50 vulnerabilities to patch”. A megfogalmazása szerint a verzió-pinnelés „another pestle in the flower of IT maintenance”.

Brian ezzel vezeti fel a következő két kategóriát: szerinte az AST08 és az AST09 pontosan ennek a két oldalát fedi le.

AST08. Poor Scanning: „code review, csak AI-val”¶

A kategória lényege, hogy nehéz megállapítani egy skillről, hogy rosszindulatú-e. Brian szerint ez valójában guardrail-építés, és két külön nehézség van benne:

„Not only do you have to try to process and find malicious code, which in itself is difficult, that's not a solved problem at this point. You also have to find malicious intent in natural language.”

Vagyis a statikus elemzés (sebezhetőség-keresés) mellett a prózai utasítások szándékát is érteni kellene, utóbbi nyitott probléma.

Bronwen a szoftverfejlesztői hátteréből olvassa a kategóriát, és szerinte ez egyszerűen code review:

„It almost sounds like they're calling for code review. But instead of it being traditional code, these are skills.”

A párhuzam pontos: a hagyományos fejlesztésben is megkérsz egy másik programozót, hogy nézze át a munkádat, egyrészt hogy tényleg azt csinálja, amit állítasz, másrészt hogy megtalálja a hibákat. Itt ugyanez a kérés: mielőtt egy skillt kiadsz a világba, ellenőrizd, hogy nem lépte át a kijelölt határokat, és nincsenek-e beágyazott nem biztonságos gyakorlatok.

A kritikája nyers:

„I feel like a broken record. This is more of the same thing. It's just AI. Now it's different somehow?”

Brian egyetért, és új szolgáltatást lát a láthatáron:

„Rather than a code review, we'll have skill reviews.”

Ez az epizód egyik legkonkrétabb, gyakorlati javaslata: a skill-review mint a code review megfelelője. Bronwen szerint érdemes terjeszteni, Brian szerint „itt hallottad először”.

AST09. No Governance: a leltár hiánya és a szabályok hiánya¶

Ez a kategória Brian szerint szorosan kapcsolódik az AST07-hez: a foltozáshoz tudni kell, milyen skillek vannak a környezetben.

Az összehasonlítás a hagyományos IT-vel tanulságos. Ahol az alkalmazásokat központilag telepítik (group policy vagy más szoftverkezelés), ott tudod, mi van minden gépen, milyen verzióban, és hatékonyabban tudsz foltokat kipusholni. A skilleknél ez a réteg hiányzik:

„How can you patch something if you don't know it even exists in your environment?”

Bronwen egy friss fejlődési irányt nevez meg, ami rontja a helyzetet: a frontier-fejlesztők egyre inkább felhőalapú szolgáltatásokat kínálnak, ahol a skill és a feladat a fiókodhoz tartozik, de az ő felhőkörnyezetükben fut, így a helyi gépnek nem is kell bekapcsolva lennie. Ez kiveszi a kézből azt a kevés kontrollt is, ami a helyi telepítésnél megvolt.

A governance-ről alkotott véleménye szerint a helyzet volatilis:

„There are no rules, no real ones. The tools themselves are changing so fast. It's impossible to figure out where to draw the fences.”

A szerkezeti problémát is megnevezi: a governance-t általában magára hagyják, és amikor a dolgok félremennek, kiderül, hogy soha nem voltak határok definiálva. Ez mindenkit bajban hagy.

Brian egyetért, és a párhuzamos időzítést emeli ki: a fejlesztés, az adoptáció és a szabályozás egyszerre történik.

Bronwen a 90-es évekből hoz mércét: akkor webmesterként a böngészőháborúk tűntek rossznak, mert naponta kellett új Netscape-et vagy Mosaicot letölteni. Most napi három frissítés van. Szerinte ez az akceleráció magyarázza a visszahúzást és a növekvő félelmet: az emberek azt látják, hogy gyorsabban haladunk, mint ahogy kontrollálni tudnánk.

A gyakorlati tanácsa mégis konstruktív: definiálni kell, mit jelent a kontroll, ha nem lehet olyan részletes, mint szeretnénk, akkor legalább széles vonalakban. Legyen AI-politika, induljon el szélesen, majd szűkítsd a saját felhasználási eseteidre. Kip Boyle-t említi, aki szerinte külön sorozatot szentel az AI-útmutatásnak.

A záró mondata az epizód egyik legidézhetőbb pontja:

„And for god's sake, check all the output.”

AST10. Cross-Platform Reuse: a szabvány, ami még nincs¶

Brian összefoglalása szerint a kategória arról szól, hogy nincs egységes formátum a skillekhez, ezért az egyik platformra tett guardrail, safety measure vagy metaadat nem fordul át a másikra. A javaslat ebből következően egy egységes formátum. A kérdés, amit feltesz:

„Who do you think should decide what that format is? Someone just come out and just say, hey everyone, I think this is what all of us should use — or is it basically the big players are all boxing it out, and whoever's the last one not knocked out gets to declare the format?”

Bronwen szerint minden frontier-modell játszani akar ebben a homokozóban, mert ez segít meghatározni, hogyan tudnak terjedni az eszközeik. A régi párhuzam: a Windows/Mac/Linux közötti kompatibilitás évekig fájdalmas volt, és szerinte itt ugyanaz az interoperabilitási probléma jelenik meg az AI térben.

A SKILL.md-ről konkrét megfigyelést tesz:

„The whole SKILL.md is very much a quad specific thing, but the frontier models are like babies in a nursery. If one starts doing something, another one has to do the same thing.”

Vagyis a formátumok széttartanak, miközben a szereplők egymást másolják, ami nem konvergenciát, hanem versengő szabványokat eredményez. A saját gyakorlatából hozza a handoff dokumentumokat: ezeket a felhasználó meg tudja csinálni LLM-ek között, de nem oldják meg az alapproblémát, mert nincs konzisztens szabvány a skillek átadására a különböző szolgáltatók között, a saját hosztolásról nem is beszélve.

A következmény a biztonságra nézve konkrét: nehezebb azonosítani és követni a sebezhetőségeket. Ha egy GitHubon publikált skill az egyik környezetben jól működik, a másikban mást generál, és minél több platformra tervezel, annál élesebbé válnak ezek a fejfájások.

A hasonlatok sora az epizód legszórakoztatóbb része, és egyben a szabványok értékéről szól:

Celluláris töltőkábelek: Brian felidézi, hogy régen gyakorlatilag minden telefon töltője más volt, nem USB-C kontra micro-USB, hanem „van-e Nokia x3 9 töltőd”. Bronwen megerősíti: minden port a gyártóhoz volt kötve, néha egyetlen modellhez. Ezért van mindig három opció a kábelének végén.
Autók: Bronwen szerint ez a működő szabvány példája. Ford, Dodge, Toyota, Bentley vagy Rolls Royce: mindegyikben van gázpedál, fék, kormány és biztonsági öv, mert vannak szabványok. Brian hozzáteszi: a kuplung, a „zavarba ejtő harmadik pedál” már eltűnőben van.

Az időzítés kérdésére Bronwen visszaszámol: a ChatGPT 2022 augusztusában jelent meg, tehát négy év telt el, és a skillek ennél is újabbak. Minden technológiánál idő kell, amíg kiderül, hogyan működik, mit kell tenni a biztonságáért és hogyan lehet visszaélni vele, és ez az ütem mellett különösen nehéz. Az OWASP munkáját elismeri, de a következtetése:

„I applaud what OWASP has laid out here, but I think it's going to be at least another six months before we get anything like this.”

Brian hozzáteszi: „maybe longer”.

A lista egészéről alkotott összkép¶

A két rész együtt olvasva a lista szerkezete jól látszik, és a házigazdák kritikája konzisztens:

Az első öt (AST01–AST05) a támadás oldala, hogyan lesz egy skillből fegyver vagy hogyan lesz a hozzáférés túl széles. Ezek a kategóriák konkrét támadási mechanizmusokat neveznek meg (credential stealer, supply chain, prompt injection).
Az utolsó öt (AST06–AST10) az üzemeltetés oldala, nem arról szól, hogyan támadnak, hanem hogy milyen kontrollok hiányoznak. Ezért érezhető itt erősebbnek a házigazdák fenntartása: az izoláció, a szkennelés, a governance és a szabványosítás mind olyan terület, ahol a válasz a klasszikus IT-gyakorlat átvétele lenne.
A csomópont az AST07. A pinnelés dilemma (véd a friss rosszindulattól, de befagyasztja a sebezhetőséget) megmutatja, hogy az üzemeltetési kategóriák nem oldhatók meg egyenként: a foltozás leltárt igényel (AST09), a leltár szkennelést igényel (AST08), a szkennelés pedig formátumot (AST10).

Az epizód záró tanulsága ebből következik, és a Part 1-hez kapcsolódik: az OWASP listája keretrendszer, nem megoldás. A házigazdák nem azért kritizálják az átfedéseket és a nehezen értelmezhető elemeket, mert feleslegesnek tartanák, hanem mert a gyakorlati bevezethetőség a tét, és a saját bevallásuk szerint is mindenki „making it up as we go along”.

Vendégek¶

Brian Fehrman (házigazda). BHIS biztonsági kutató, az AI Security Ops társházigazdája
Bronwen Aker (házigazda). Szoftverfejlesztői és webmesteri háttérrel (90-es évek közepe), AI-vezérelt munkafolyamatokkal foglalkozik; ebben a részben Derek Banks helyett társ-házigazda
Vendég: nincs

Kapcsolódó epizódok és források¶

AI Security Ops #70 (2026-09-21). OWASP Agentic Top 10 [Part 1], az első öt kockázat; itt hangzott el a Hermes nevesítése a harnessek között
AI Security Ops #69 (2026-09-14). Agentic Skills, a lista felvezetése
AI Security Ops #71 (2026-09-26). Will AI Take Over?
OWASP Agentic Skills Top 10, a keretrendszer, megjelent 2026. augusztus 17-én, a Black Hat és DEF CON után; két Critical, négy High és négy Medium kategóriával
SKILL.md (OpenClaw), skill.json (Claude Code), manifest.json (Cursor/Codex), package.json (VS Code), a lista által lefedett, egymással nem kompatibilis formátumok
Kip Boyle. AI-útmutatási sorozat, amit Bronwen említ
Antisyphon Training, a BHIS képzési ága (szponzorblokk az epizód elején)

Forrás¶

Epizód: https://share.transistor.fm/s/92ba0d79
Transcript (natív, emberi, beszélő-címkékkel): https://share.transistor.fm/s/92ba0d79/transcription.txt
Fejezetek: https://share.transistor.fm/s/92ba0d79/chapters.json
Az epizód fejezetei: Intro; What Is an Agentic Skill?; AST06; AST07; AST08; AST09; AST10; Final Thoughts
Megjegyzés a kategórianevekről: az epizódban a házigazdák az AST08-at „poor scanning”, az AST09-et „no governance” és az AST10-et „cross platform reuse” néven említik; az OWASP oldalán ezek a hivatalos elnevezések. Az AST06 az epizódban végig „weak isolation” (Brian egyszer „weak isolation risk number six”-ként vezeti be); a hivatalos oldal ugyanezt a nevet használja