# 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: 1. **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. 2. **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. 3. **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”**. 4. **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. 5. **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: - Transcript (natív, emberi, beszélő-címkékkel): - Fejezetek: - 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