NVIDIA bemutatta az OpenShell 0.1.0-t, egy nyílt forráskódú futásidejű réteget, amely definiálja és érvényesíti, hogy egy AI-ügynök milyen rendszerekhez, adatokhoz és szolgáltatásokhoz férhet hozzá. A cél, hogy az ügynökök megőrizzék autonómiájukat (célok követése, kódírás, eszközhasználat, hosszú távú munkavégzés), miközben a tényleges jogosultságok kívülről, a munkaterhelten kívül vannak korlátozva és auditálva.
Miért fontos
Hosszú futamidejű AI-ügynökök képesek szoftverhibákat vizsgálni, kísérleteket futtatni, illetve üzletileg kritikus műveleteket vagy kutatást végezni több napig vagy hétig. Ehhez hozzáférés kell munkaterületekhez, számítási erőforrásokhoz, adatokhoz, hitelesítőkhöz és külső szolgáltatásokhoz. A szélesebb hozzáférés viszont nagyobb következményekkel járó hibamódokat is hozhat (pl. termelési adatok módosítása, titkos információk kiszivárgása vagy az ügynök feladatán túli cselekvés).
Mit nyújt az OpenShell 0.1.0
OpenShell ötvözi a sandboxolt végrehajtást, a szolgáltatáshozzáférés szabályozását, a hitelesítőkezelést és a formális policy-analízist. A cél, hogy a csapatok csak az adott feladathoz szükséges képességeket adják meg az ügynököknek, míg az OpenShell a jogosultságokat kívülről érvényesíti és naplózza.
OpenShell része a szélesebb NVIDIA Open Agent Safety Platformnak, amely a védelem kiterjesztését célozza az alkalmazás-, futtatási és infrastruktúra-rétegekre.
Támogatott keretrendszerek és alkalmazások
A 0.1.0 támogatja többek között a Codex-et, Claude Code-ot, Pi-t és Hermes-t, és célja a további keretrendszerek támogatása vállalati alkalmazásokban, frontier kutatásban és fizikai AI területeken (belső ügynökflották, hosszú távú kutatások, robotika, edge rendszerek).
Hogyan épül fel a vezérlés
OpenShell három fő komponense biztosítja a jogosultságok futásidejű érvényesítését:
- OpenShell Gateway: több sandbox életciklusát és policy-ját kezeli.
- OpenShell Supervisor: minden sandbox mellett fut, a munkaterhelten kívül hagyja jóvá és ellenőrzi a kimenő kéréseket a policy szerint.
- OpenShell Sandbox: maga a munkaterhelés kernel-szintű kontrollokkal a fájlrendszer és folyamatok felett, hálózati út kizárólag a supervisoron keresztül.
A sandbox runtime operációs rendszer szintű kontrollokat használ, így korlátozza, milyen fájlokat tud olvasni vagy módosítani a munkaterhelés, valamint megakadályozza a további rendszerjogosultságok megszerzését. A supervisor képes HTTP, GraphQL és Model Context Protocol (MCP) forgalom inspectálására: például engedhet egy lekérdezést ugyanazon API esetén, miközben blokkolja az írást. Ezek a kontrollok akkor is érvényben maradnak, amikor az ügynök shellt indít, generált kódot futtat, gyermekfolyamatokat indít, vagy al-ügynököknek delegál.
Minden policy-döntés OCSF (Open Cybersecurity Schema Framework) audit nyomvonalba kerül; ha egy ellenőrzött kérést blokkol a rendszer, az részletes hibát ad vissza, amely segíti az ügynököt a továbblépés eldöntésében.
Gyakorlati példa: hálózati policy-k és GitHub
A dokumentált demóban a telepítés után két YAML policy fájlt használnak (no-network.yaml és github-readonly.yaml). Például sandbox létrehozása hálózat nélkül:
openshell sandbox create --name policy-demo \
--no-auto-providers \
--policy examples/no-network.yaml
A sandboxból egy publikus végpont olvasása (curl https://api.github.com/zen) sikertelen lesz, mert nincs kimenő hálózati jogosultság. A host gépen a naplókból látszik, melyik program próbálkozott és miért blokkolták:
openshell logs policy-demo --since 5m
Majd a policy-t kicserélve egy GitHub olvasási szabályra (github-readonly.yaml), amely például engedélyezi a /usr/bin/curl-nek, hogy a api.github.com port 443-án REST kéréseket küldjön, a rendszer HTTP-kéréseket inspectálva engedélyezi az olvasást és blokkolja az írást. A policy alkalmazása újraindítás nélkül történik:
openshell policy set policy-demo \
--policy examples/github-readonly.yaml --wait
A sandboxon belül a read (GET) kérés megengedett, a write (POST) kérés blokkolt lesz; a host naplóiban az OpenShell blokkolásai ellenőrizhetők.
Hitelesítők védelme és szolgáltatáshoz kötés
Az OpenShell lehetővé teszi, hogy az ügynökök hitelesített szolgáltatásokat használjanak anélkül, hogy a valódi hitelesítő a munkaterhelésben lenne. Egy szolgáltató profil (provider profile) definiálja a hitelesítőket, végpontokat és az engedélyezett programokat. A rendszer helyettesítő (placeholder) hitelesítőt ad át az ügynöknek, és a valódi hitelesítőt csak a jogosult végpontoknál köti be; ha az ügynök a placeholdert nem engedett végponthoz küldené, a kérés megtagadásra kerül.
Fontos, hogy az OpenShell külön kontrollt ad arra, hogyan használhatja az ügynök a hitelesítőt (például egy politikában read-only inspectálás blokkolhatja az írást még akkor is, ha maga a hitelesítő írási joggal rendelkezik). Példa parancs sandbox indítására egy már konfigurált GitHub providerral és Codex indítására:
openshell sandbox create \
--provider github \
-- codex
Dinamikus jogosultság-kérések és policy advisor
Ha egy ügynöknek futás közben ismeretlen szolgáltatásra vagy adatra van szüksége, és a policy blokkolja a kérést, az OpenShell naplózza a megtagadást. Ha a sandboxban engedélyezik a policy advisor funkciót, az ügynök javasolhat egy szűkített hálózati vagy fájlrendszer policy-változtatást. Ezek a javaslatok alapértelmezés szerint emberi felülvizsgálatra várnak; az ügynök nem hagyhatja jóvá saját kéréseit. Jóváhagyás után a rendszer betölti az új szabályt a futó sandboxba, így az ügynök újra megpróbálhatja a műveletet újraindítás nélkül.
A fájlrendszer- és folyamatkorlátozások a sandbox indításakor rögzülnek; megváltoztatásuk új sandboxot igényel.
A policy advisor bekapcsolása példa:
openshell settings set <sandbox-name> \
--key agent_policy_proposals_enabled \
--value true
Formális policy-ellenőrzés (policy prover)
Az OpenShell policy prover formális logikai ellenőrzéseket futtat a policy-kről, beleértve a providerek által hozzájáruló hozzáféréseket is. Képes bizonyítani, hogy a modellált jogosultságok egy operátori által definiált határon belül maradnak, vagy konkrét műveletet mutatni, amely átlépi azt. Mivel a bizonyítás a policy modellből származik, egy ügynök által készített magyarázat nem módosítja az eredményt.
A dokumentáció szerint hosszú távú adversariális kísérletekben frontier ügynökök megkíséreltek engedélyeket szerezni védett GitHub repository-k módosításához; OpenShell formális policy-analízise bizonyítékot adott a felülvizsgálóknak arról, mit tennének lehetővé az engedélyek, és a kombinált felülvizsgálat és futásidejű controls mellett nem történt védett repository-írás ezen tesztekben. Folyamatban van a policy-analízis kiterjesztése több ügynökre, hogy ellenőrizhető legyen, miként kombinálódnak a hozzáférések.
Vállalati bevezetés, integrációk és közösség
OpenShell nyílt forráskódú, vállalati adoptálásra és partner-ökoszisztémára épít. Már látható alkalmazások: Cadence használja chiptervezésben a ChipStack Autonomous RTL Design Engineerhez; Slack egy on-demand ügynökplatformot épít OpenShellre; Gecko Robotics OpenShellt használ fizikai robotok döntéshozatalának szabályozására.
A rendszer csatlakoztatható harmadik fél biztonsági és kormányzási szolgáltatásokhoz, valamint identity middleware-hez. Számítási driverek révén Docker, Podman, MicroVM és Kubernetes környezetekhez kapcsolódik; a támogatottsági mátrix a részleteket tartalmazza.
Csatlakozás fejlesztői csatornákhoz és kód:
- #openshell-dev a CNCF Slack-en kérdésekhez és visszajelzéshez.
- A kód és hozzájárulás GitHubon érhető el.
- OpenShell dev notes és 0.1.0 migration notes elérhetők a frissítési útmutatáshoz.
Hol kezdje el
A gyorsstarttal helyben indítható saját ügynök OpenShell-lel, és konzultálható az installation guide, workspaces and access guide, valamint a support matrix a telepítés és skálázás részleteiért.
