Az OpenAI belső MI-felügyeletét vizsgáló külső kutatók olyan hibákat találtak, amelyekkel ügynökök elkerülhették volna az ellenőrzést. Az októberben közzétett eredmények egy nyári állapotot írnak le, és megmutatják, miért kell a biztonsági ígéretek mellett az ellenőrzés feltételeit is ismernünk.
Állítsd be a mivagyunk.hu-t kedvenc forrásként a Google-benEgy másik MI figyeli, mit csinál az ügynök
Ha egy MI már fájlokat módosít és programokat futtat, a munkáját felügyelő rendszernek azt is észre kell vennie, amikor túllépi a feladatát. Egy hibás válasz kijavítható a következő üzenetben. Egy engedély nélkül továbbított adat vagy törölt állomány esetében a későbbi figyelmeztetés már kevés lehet.
Az OpenAI márciusi ismertetője szerint belső programozóügynökeit egy másik MI segítségével ellenőrizte. A felügyelő az ügynök műveleteit és szöveges gondolatmenetét is elemezte, majd gyanús viselkedésnél emberi vizsgálatot kezdeményezett. A megoldás utólagos ellenőrzésként működött; az egyes műveletek előzetes megállítása további fejlesztési cél volt.
Ez olyan különbség, amely könnyen elveszik a biztonsági funkciók felsorolásában. Egy működő riasztó sem akadályoz meg minden kárt, különösen akkor, ha csak a munka végeztével szólal meg.
A felügyelőhöz vezető út is hibás lehet
A METR és a Redwood Research egy-egy munkatársa 2026. július 21. és augusztus 11. között tesztelte a rendszert. Az október 22-én közzétett beszámoló szerint találtak olyan hibát, amellyel több száz korábbi művelet maradhatott volna ellenőrizetlenül. Azt is feltárták, hogyan lehetett volna elvileg megkerülni a Codex elkülönített futtatási környezetét és automatikus jóváhagyását.
A vizsgálat a július 21-i és korábbi állapotot értékelte. Megállapításai önmagukban nem bizonyítják a hibák tényleges kihasználását.
A tanulság túlmutat a felügyelő MI ítélőképességén. Hiába ismerne fel egy veszélyes lépést, ha annak adatai el sem jutnak hozzá. Az ellenőrzés megbízhatóságához a teljes útvonal működését bizonyítani kell, az ügynök műveletétől az emberhez érkező jelzésig.
A javítás bejelentése után is marad ellenőrizendő állítás
Az OpenAI a kutatók tájékoztatása szerint kijavította az éles védelmi rendszerét érintő feltárt hibákat. A külső tesztelők ezt nem ellenőrizték.
Közben a vállalat augusztusi közlése szigorúbb elkülönítésről és kiterjesztett felügyeletről számolt be. Leírása szerint a GPT-5.6 Sol képességszintjét elérő modelleknél az eszközhasználattal járó megerősítéses tanításhoz és értékeléshez is előírta a gondolatmenet figyelését.
A nyilvános anyagból ezért a mai rendszer biztonságáról nem lehet teljes ítéletet mondani. Egy korábban megtalált hiba és annak igazolt javítása két külön bizonyíték. A kettő közötti távolságot egy újabb, megfelelő hozzáféréssel végzett vizsgálat csökkentheti.
A külső vizsgálatnak is vannak határai
A kutatók belső kódot és dokumentációt is láthattak. A teljes, 61 oldalas jelentés azonban nem nyilvános, az OpenAI pedig korlátozhatta, milyen érzékeny részletek jelennek meg a beszámolóban.
A hozzáférés és a nyilvánosság eltérő szerepet tölt be. A részletes hozzáférés segíthet megtalálni egy hibát. A közzétehető bizonyíték alapján más szakértők is mérlegelhetik, mennyire megalapozott a következtetés.
A METR együttműködési alapelvei ezért hangsúlyozzák a vizsgálati korlátok és a közlésből kihagyott információk jelentőségének bemutatását. Ez alapján a külső tesztelés említése önmagában kevés a bizalomhoz. Az eredmények értékeléséhez tudnunk kell, mire kaptak hozzáférést a tesztelők, és mely állításokat nem tudták megvizsgálni.
Egy magyar cégnél is kipróbálható a felügyelet
Szemléltető példaként vegyünk egy magyar webshopot, ahol egy ügynök készíti elő a termékadatok frissítését. Ha a vezető csak a kész munkáról kap összefoglalót, abból még nem derül ki, mi történt a köztes lépésekben. Egy kimaradt figyelmeztetés ugyanúgy láthatatlan maradhat, mint egy valóban eseménytelen munkafolyamat.
Érdemes ezért veszélytelen próbával ellenőrizni a kontrollt. Tesztadatokon kérni egy előre meghatározott, engedélyhez kötött módosítást, és érdemes megnézni, valóban megáll-e a folyamat. A próba eredményét a naplóval is össze kell vetni. A próba megtervezéséhez az emberi jóváhagyás helyéről szóló útmutatónk ad további szempontokat.
Egy ilyen teszt a helyi hozzáférések és jóváhagyások működéséről ad tapasztalatot; a szolgáltató teljes biztonsági rendszerét nem minősíti. A céges MI felelőse akkor tud érdemben felügyelni, ha egy próba során azt is megmutathatja, melyik lépés állt meg, és ki tudott közbelépni.
