Dare a un assistente IA l'accesso a Proxmox: dove deve stare il confine

Qui c'è un'asimmetria reale e un po' fastidiosa. Leggere duemila righe di registro e trovare la riga in cui qualcosa si è rotto è esattamente ciò che un modello linguistico sa fare bene. Ed è anche esattamente il lavoro che la maggior parte delle persone non può lasciargli fare, per come viene concesso l'accesso.

La domanda non è se un modello debba toccare un server. È dove sta il confine, e oggi di solito sta nel posto sbagliato.

Perché la configurazione abituale mette a disagio

Ci sono due modi comuni per collegare un assistente a Proxmox: dargli una sessione SSH oppure un token API con pieni privilegi. Entrambi portano allo stesso punto. Da quel momento nulla si frappone tra il modello e l'hardware, e tutte le protezioni vivono nel modo in cui è scritta un'istruzione.

Un'istruzione non è un confine. È una richiesta rivolta a un sistema progettato per essere utile, in una lingua priva di forza esecutiva.

Il rischio è il contesto mancante, non la cattiva intenzione

È questa la parte che viene diagnosticata male. La forma di guasto raramente è un modello che decide di fare danno. È un modello che agisce correttamente su un quadro incompleto.

Un disco che sembra vuoto. Il modello legge un dispositivo senza filesystem montato e lo considera libero. Il dispositivo appartiene a una macchina semplicemente spenta.

Un pool degradato. Il modello legge lo stato degradato e propone di ricostruire l'insieme. Il passo giusto era sostituire un disco, e la ricostruzione è il modo in cui i dati rimasti si perdono.

Un servizio "non in esecuzione". Non è in esecuzione perché gira su pianificazione e ha finito. Riavviarlo è innocuo; disabilitarlo perché "si ferma di continuo" no.

In tutti e tre il comando è scritto correttamente. È la premessa a essere sbagliata, e un comando corretto su una premessa sbagliata è indistinguibile da un sabotaggio a cose fatte.

La sola lettura aiuta e non è tutta la risposta

La risposta ovvia è concedere accesso in sola lettura, e toglie davvero gli esiti peggiori. Restano due cose.

Leggere non è gratis. Configurazione, registri e tracce di controllo contengono nomi host, indirizzi, nomi utente e a volte token incollati dove non dovevano. Un assistente in sola lettura con portata di lettura completa è un'esportazione della vostra infrastruttura.

La diagnosi senza azione si ferma a metà. Se la risposta utile è "riavvia questo singolo servizio", una configurazione in sola lettura restituisce il risultato a una persona perché lo riscriva. Va bene, ed è anche il motivo per cui i permessi vengono allargati in silenzio più avanti.

Quindi la sola lettura è un buon inizio e una cattiva destinazione. La destinazione è accesso in scrittura stretto, attraverso le stesse porte che attraversa una persona.

Dove appartiene davvero il confine

Non all'istruzione e non al modello. Allo strato che esegue, perché è l'unico posto che può rifiutare.

Tre proprietà rendono affidabile un tale strato, e tutte e tre sono verificabili anziché promesse.

I permessi vengono dal sistema che già li ha. Se l'assistente si collega con un account esistente, ciò che quell'account può toccare è esattamente ciò che l'assistente può toccare. Non si inventa un secondo modello di permessi, quindi non c'è nulla da tenere sincronizzato e nessun modo perché i due si contraddicano.

Le operazioni distruttive passano dalla stessa porta di una persona. Se cancellare un disco chiede conferma a un essere umano, deve chiederla anche quando lo richiede un modello. Un percorso sicuro per le persone e aperto per l'automazione non è un confine, è una scorciatoia con un bel nome.

Ogni passo finisce nel registro di controllo. Chi, cosa, quando, su cosa e con quale esito. Senza questo la vera domanda dopo un incidente, "è stato l'assistente", non ha risposta, e l'assenza di risposta è di per sé un motivo per non concedere accesso.

La domanda da porre su uno strumento del genere

Non "è sicuro" ma "cosa rifiuta, e dove vive?"

Se la risposta è "al modello è stato detto di non farlo", non c'è confine. Se la risposta è "lo strato che esegue controlla i permessi dell'account e fa passare i passi distruttivi da una porta", c'è, e potete provarlo: collegatevi con un account limitato e verificate che il rifiuto sia reale.

Cosa fa Atlas

⚠️ Questo strato è pianificato, non rilasciato. Quello che segue è il progetto verso cui viene costruito, scritto qui perché la domanda sopra merita una risposta onesta e non pubblicitaria.

L'intento è che l'assistente si colleghi ad Atlas e non a Proxmox. Proxmox sta sotto e il modello non lo raggiunge mai direttamente; può usare solo ciò che Atlas stesso sa fare, il che lascia ogni porta esistente sul percorso.

Il confine è tracciato dai permessi di Proxmox, cioè la prima proprietà qui sopra: ciò che l'account collegato può toccare è tutto ciò che l'assistente tocca, e non compare alcun nuovo concetto di permesso. Le operazioni distruttive mantengono la conferma che hanno già, e il registro di controllo annota già chi, cosa, quando, su cosa e con quale esito per ogni azione privilegiata, rifiuti inclusi.

È pensato anche come componente separato invece che parte dell'installazione: su una macchina che non lo vuole non è mai presente. Questo conta per lo stesso motivo di tutto il resto dell'articolo. Il confine più sicuro per una capacità che non avete scelto è la sua assenza.