Szerző: Mike Loukides
Egy, az O’Reilly Radar havi Trends to Watch rovatához készített Claude-skill váratlanul leállt, miután Anthropic Sonnet nevű valós idejű kiberbiztonsági védelmi rétege „veszélyesnek” jelölte a működését. A szerző gyakorlati példán keresztül mutatja be, hogyan okozhatnak problémát a túl szélesre szabott, kontextus-alapú korlátok.
Mi volt a skill célja és hogyan működött
Loukides készített egy Claude képességet (skill), amely naponta körülbelül egy tucat ismert webhelyet — például The New Stack, The Next Web és Hacker News — olvasva készített összefoglalót az elmúlt nap legfontosabb cikkeiről. A skill célja az volt, hogy szolgáljon egyfajta valós idejű ellenőrzésként: nem hagytam-e ki valami fontosat, vagy nem változott-e valami, ami vezető indikátor lehet.
A szerző naponta használta a skille-t hónapok óta, amikor hirtelen ez a hibaüzenet jelent meg:
API Error: Sonnet 5’s safeguards flagged this message. Our intentionally broad safeguards allow us to deliver more capabilities faster, but can sometimes flag legitimate cybersecurity work. Apply to the Cyber Verification Program to reduce these interruptions. Send feedback with /feedback or learn more: https://support.claude.com/en/articles/14604842-real-time-cyber-safeguards-on-claude
A hibajelenség vizsgálata
Egy új Claude Code munkamenetben, Haiku modellnél a skill problémamentesen működött; a szerző nem próbálta ki Opus vagy Fable modelleket, de feltételezi, hogy Sonnet ott is ugyanígy lépett volna fel. GPT‑5.6 „high” reasoning beállítással képes volt nagyon hasonló feladatot végrehajtani gond nélkül. Ez azt jelzi, hogy maga a skill nem alapvetően hibás — a gond a Sonnet nevű védelmi rendszerrel volt.
A szerző a hibajelzést bemásolta egy másik Claude Code munkamenetbe, és megkérdezte a modellt, mi történhetett. A visszajelzés szerint a Sonnet a beszélgetés bizonyos leírásaira reagált: például a Hacker Newsról szóló leírásban szereplő „vulnerabilities, exploits, threat reporting” kifejezés váltotta ki a védőkorlátokat. Ironikus módon ez a leírás pont nem volt igaz, és magától Claude‑tól származott.
Sonnet három lehetséges megoldást javasolt, köztük azt, hogy a skillt semlegesebb leírásokra írják át (például „security industry news”). A szerző maga szerkesztette át a szöveget, mégsem állt helyre a korábbi munkamenet: a korábbi session innentől kezdve csak a hibaüzenetet ismételte, nem hajtotta végre a skillt, és nem tudta a módosítást GitHub-repozitóriójába rögzíteni. Ugyanakkor Sonnet képes volt ugyanazt a skillt új Claude Code munkamenetben végrehajtani.
A Sonnet döntése kontextus alapján — és a vesztes kontextus problémája
A Sonnet magyarázata szerint a védelmi döntést nem kizárólag a hívott skill tartalma, hanem a teljes beszélgetés alapján hozza meg: ha a modell úgy ítéli meg, hogy egy hívás problémás lehet, maga a hívás a beszélgetés részévé válik, és ezzel az egész kontextus „elvész” — vagyis a teljes munkamenet innentől használhatatlan lesz.
Ez két szempontból is problémás:
- Stabilitás: egy működő program attól áll le, hogy a környezeti korlátok (amelyek felett a felhasználónak nincs irányítása) megváltoznak. Az iparágban ismerős a „ne változtass semmit, mert a régi kód csak így működik” hozzáállás, és a folyamatosan megbízhatatlan AI‑környezet ronthatja a termelékenységet.
- Kontextusvesztés: a teljes beszélgetés értéke elvész, ha egy apró, téves riasztás miatt az egész session blokkolódik. Ennélfogva a guardrail-ok ahelyett, hogy megakadályoznák a kártevő cselekményeket, ártatlan dolgozókat és kutatókat gátolhatnak a mindennapi munkában.
Az elvárható biztonság vs. használhatóság közti kompromisszum
Loukides emlékeztet a jellegzetes, bináris osztályozást leíró receiver operating characteristic (ROC) koncepciójára: tökéletes osztályozás nem létezik. Ha a cél az, hogy semmilyen valódi veszélyes esetet ne engedjünk át, akkor minden jelölést el kell utasítani — azaz semmi sem működhet. Az ellenkező véglet is igaz: ha nullára akarjuk csökkenteni a téves riasztásokat, akkor mindent át kell engedni, így valódi veszélyek is bejutnak.
A gyakorlatban a megoldás mérnöki egyensúlyt kíván: a kockázatcsökkentés és a gyakorlati hasznosság közti kompromisszumot kell megtalálni. Jelenleg az iparág hajlamos túlértékelni a „biztonság” okán bevezetett széles lefedésű tiltásokat, amelyek azonban nem egyértelmű határvonalakat adnak a felhasználóknak.
Végkövetkeztetések
A szerző nem vitatja, hogy a rosszindulatú felhasználás lehetősége valós; például egy cikk, amely leírja a Morris worm működését, kockázatot jelenthet, illetve prompt injection és egyéb hibák is előfordulhatnak. Ugyanakkor problémásnak tartja, hogy a nyilvános, széles körben használt források olvasása automatikusan kockázati jelzésként jelenik meg, különösen akkor, ha maga a kockázati leírás hibásan, modell által generált szövegen alapul.
A tanulság: a védőkorlátoknak nem szabad túlzottan megfojtaniuk a hasznos alkalmazásokat. A csapatoknak világosabb, átláthatóbb határokat kell meghatározniuk, és törekedniük kell arra, hogy a guardrail‑ok kompromisszumos, de stabil és előre jelezhető működést biztosítsanak. A túl szigorú, bizonytalan határok inkább gyengítik az AI hasznosságát, semmint védelmet nyújtanának.
Rövid megjegyzés a forrásról
A cikk alapját Mike Loukides tapasztalata képezi egy Claude‑skill leállásáról és a Sonnet valós idejű védelmi mechanizmusának erről kialakult reakciójáról.
