Proxmox-hozzáférés adása MI-asszisztensnek: hol kell húzódnia a határnak

Van itt egy valós és kissé bosszantó aszimmetria. Kétezer sornyi napló elolvasása és annak a sornak a megtalálása, ahol valami elromlott, pontosan az, amiben a nyelvi modell jó. Ugyanakkor pontosan ez az a munka is, amelyet a legtöbben nem engedhetnek meg neki, a hozzáférés megadásának módja miatt.

A kérdés nem az, hogy a modell hozzányúlhat-e egy szerverhez. A kérdés az, hogy hol húzódik a határ, és ma többnyire rossz helyen húzódik.

Miért kényelmetlen a szokásos felállás

Két elterjedt módja van annak, hogy egy asszisztens a Proxmoxhoz kapcsolódjon: SSH munkamenetet kap, vagy teljes jogosultságú API tokent kap. A kettő ugyanoda vezet. Attól a pillanattól semmi nem áll a modell és a hardver között, és minden védelem egy prompt megfogalmazásában lakik.

A prompt nem határ. Kérés, amely egy segítőkészre tervezett rendszerhez szól, olyan nyelven, amelynek nincs kikényszerítő ereje.

A kockázat a hiányzó kontextus, nem a rossz szándék

Ezt a részt szokás félrediagnosztizálni. A hibamód ritkán az, hogy a modell kárt akar okozni. Az a jellemző, hogy a modell helyesen jár el egy hiányos kép alapján.

Egy lemez, amely üresnek látszik. A modell csatolt fájlrendszer nélküli eszközt olvas be, és szabadnak tekinti. Az eszköz valójában egy olyan géphez tartozik, amely csak éppen ki van kapcsolva.

Egy sérült tárolókészlet. A modell beolvassa a sérült állapotot, és a tömb újraépítését javasolja. A helyes lépés egyetlen meghajtó cseréje lett volna, az újraépítés pedig éppen az a mód, ahogy a megmaradt adat elvész.

Egy szolgáltatás, amely "nem fut". Azért nem fut, mert ütemezés szerint indul, és befejezte a dolgát. Az újraindítása ártalmatlan, a letiltása viszont azért, mert "folyton leáll", már nem az.

Mindhárom esetben a parancs helyesen van megírva. A kiindulási feltevés a hibás, és a téves feltevésen alapuló helyes parancs utólag megkülönböztethetetlen a szabotázstól.

A csak olvasható hozzáférés segít, de nem a teljes válasz

A kézenfekvő válasz a csak olvasható hozzáférés megadása, és ez valóban kizárja a legrosszabb kimeneteket. Két dolog azonban marad.

Az olvasás nem ingyenes. A beállítások, a naplók és az auditnaplók gazdagépneveket, címeket, felhasználóneveket, néha pedig olyan tokeneket tartalmaznak, amelyeket nem oda kellett volna bemásolni. A teljes olvasási hatókörrel rendelkező, csak olvasó asszisztens az infrastruktúra exportja.

A beavatkozás nélküli diagnózis félúton megáll. Ha a hasznos válasz az, hogy "ezt az egy szolgáltatást újra kell indítani", a csak olvasható felállás a megállapítást visszaadja egy embernek, hogy újra begépelje. Ez így rendben van, és pontosan ezért szokták később csendben kitágítani a jogosultságokat.

A csak olvasható hozzáférés tehát jó kiindulópont és rossz végállomás. A végállomás a szűk írási hozzáférés, ugyanazokkal a kapukkal, amelyeken egy embernek is át kell mennie.

Hol a helye valójában a határnak

Nem a promptban és nem a modell belsejében. A végrehajtó rétegben, mert egyedül az tud nemet mondani.

Három tulajdonság teszi az ilyen réteget megbízhatóvá, és mindhárom ellenőrizhető, nem pedig ígéret.

A jogosultságok onnan jönnek, ahol már megvannak. Ha az asszisztens meglévő fiókként kapcsolódik, akkor pontosan ahhoz nyúlhat, amihez az a fiók nyúlhat. Nem születik második jogosultsági modell, így nincs mit szinkronban tartani, és nincs mód arra, hogy a kettő ellentmondjon egymásnak.

A romboló műveletek ugyanazon a kapun mennek át, mint amelyen egy ember. Ha a lemez törléséhez megerősítést kérnek egy embertől, akkor kérni kell akkor is, amikor a modell kezdeményezi. Az az út, amely az emberek felé biztonságos, az automatizálás felé viszont nyitva áll, nem határ, hanem szép nevű kiskapu.

Minden lépés bekerül az auditnaplóba. Ki, mit, mikor, min, és milyen eredménnyel. Enélkül az üzemzavar utáni hasznos kérdésre, hogy "ezt az asszisztens tette-e", nincs válasz, és a válasz hiánya önmagában is ok arra, hogy a hozzáférés ne kerüljön megadásra.

A kérdés, amelyet minden ilyen eszközről fel kell tenni

Nem az, hogy "biztonságos-e", hanem az, hogy "mi mond nemet, és hol lakik?"

Ha a válasz az, hogy "a modell utasítást kapott rá, hogy ne tegye", akkor nincs határ. Ha a válasz az, hogy "a végrehajtó réteg ellenőrzi a fiók jogosultságait, és kapuhoz köti a romboló lépéseket", akkor van, és ez tesztelhető: korlátozott fiókkal kell csatlakozni, és meg kell nézni, valódi-e az elutasítás.

Mit tesz az Atlas

⚠️ Ez a réteg tervezett, még nem kiadott. Az alábbiakban az a terv olvasható, amely alapján készül, azért itt, mert a fenti kérdés őszinte választ érdemel, nem marketinget.

A szándék az, hogy az asszisztens az Atlashoz csatlakozzon, ne a Proxmoxhoz. A Proxmox alatta helyezkedik el, és a modell soha nem éri el közvetlenül: csak azt használhatja, amit maga az Atlas tud, tehát minden meglévő kapu az útvonalon marad.

A határt a Proxmox jogosultságai húzzák meg, ez a fenti első tulajdonság: amihez a csatlakozó fiók hozzányúlhat, az asszisztens pontosan annyihoz nyúl hozzá, és nem jelenik meg új jogosultsági fogalom. A romboló műveletek megtartják a meglévő megerősítésüket, az auditnapló pedig már most rögzíti minden emelt jogú művelethez, hogy ki, mit, mikor, min és milyen eredménnyel, az elutasítottakat is beleértve.

Ezen felül külön összetevőnek készül, nem a telepítés részének: azon a gépen, amelyik nem kéri, jelen sincs. Ez ugyanazért fontos, amiért a cikk többi része is. A nem választott képesség legbiztonságosabb határa a hiánya.