AI prowadzi serwer, a nie go psuje

Atlas może otworzyć własny serwer Model Context Protocol dla tych, którzy tego chcą, i oferuje pole poleceń wewnątrz panelu. To osobny komponent: nie przychodzi z instalacją, kto chce, dodaje go z panelu jednym przyciskiem, a na maszynie, która go nie chce, komponent nigdy nie jest obecny. Po dodaniu odczytuje się stan serwera, przechodzi przez awarię i można wykonywać pracę, pisząc, czego się chce. Granicę rysuje Proxmox: czegokolwiek użytkownik może dotknąć, tylko tyle dotyka AI. Nie pojawia się żadne nowe pojęcie uprawnień. AI jest wpięta w Atlasa, a nie w Proxmoksa. Proxmox siedzi pod spodem, ale model nigdy nie sięga do niego bezpośrednio; używa tylko tego, co potrafi Atlas.

Ile dziś kosztuje danie modelowi dostępu do serwera

Dziś jest tylko jeden sposób, by pozwolić asystentowi AI pracować z Proxmoksem: wręczyć mu sesję SSH albo w pełni uprzywilejowany token API. To znaczy oddać roota, a od tej chwili nic nie stoi między modelem a sprzętem.

Ryzyko bierze się z braku kontekstu, a nie ze złych intencji. Model może zobaczyć dysk jako pusty i potraktować go jako wymienny, podczas gdy dysk należy do maszyny, która jest po prostu wyłączona. Może odczytać pulę w degradacji i zaproponować jej odbudowę, podczas gdy właściwym krokiem jest wymiana jednego napędu. Polecenie jest napisane poprawnie, a wynikiem jest utrata danych.

Dlatego w poważnych środowiskach model trzyma się poza serwerem. Strata ujawnia się w diagnostyce: czytanie długich dzienników i znajdowanie tego, co się zepsuło, to dokładnie ta praca, w której model jest dobry, i dokładnie ta, której nie może wykonać.

O co można zapytać

Pole poleceń wewnątrz panelu to miejsce zarówno pytań, jak i poleceń, w jednej rozmowie. Poniższe przykłady to strona pytań: model czyta stan serwera i odpowiada wraz z zapisem, na którym się oparł, a nic w nich się nie zmienia.

Dlaczego dzisiejsza kopia zapasowa się nie udała, na którym kroku stanęła, czy było miejsce na magazynie docelowym?

Dlaczego ta maszyna wirtualna od wczoraj jest wolna, wąskim gardłem jest procesor czy dysk?

Dlaczego pula jest w degradacji, który napęd wypadł, czy dane są teraz zagrożone?

Która z oczekujących aktualizacji wymaga restartu i które usługi zatrzyma?

Co oznacza ten błąd w dzienniku, czy zdarzył się wcześniej, czy się powtarza?

W tym tempie kiedy skończy się pojemność, która maszyna rośnie najszybciej?

Co można zrobić

To jest to, co ludzie nazywają VibeOps: prowadzenie serwera rozmową. Vibe coding oznacza pisanie bez czytania kodu, a na Proxmoksie to nie wchodzi w grę, więc tutaj każdy krok pozostaje widoczny. Pracę wykonuje się w tym samym polu, opisując, o co chodzi. Atlas najpierw zgłasza, co zamierza zrobić i gdzie dotknie: kroki, objęte maszyny i magazyny oraz drogę powrotu. Praca jest wykonywana po zatwierdzeniu. Nie pojawia się żadne nowe pojęcie uprawnień: pole poleceń działa z uprawnieniami konta Proxmoksa, którym się łączy. Kto chce węższej AI, daje jej wąsko zakrojone konto Proxmoksa, a zakres jest zapisany w uprawnieniach tego konta. W razie potrzeby zapis można wyłączyć dla własnej sesji i zostać przy odczycie. Każdy krok trafia do dziennika audytu.

Dodaj tej maszynie dwa rdzenie i podnieś jej pamięć do ośmiu gigabajtów.

Ustaw kopię zapasową na trzecią w nocy dla każdej maszyny w tej puli.

Zainstaluj oczekujące poprawki bezpieczeństwa, te wymagające restartu zostaw na okno serwisowe.

Ustaw politykę restartu tamtego kontenera na zawsze.

Daj temu użytkownikowi tylko prawa do kopii zapasowych, nic więcej.

Przenieś tamten dysk do nowej puli, przed przeniesieniem zrób migawkę.

Model przechodzi przez tę samą bramę co człowiek

Serwer MCP nie otwiera żadnej bocznej drogi. Zabezpieczenia, które Atlas już stosuje wobec użytkownika, obowiązują też model, w tej samej kolejności.

Uprawnienia pochodzą z Proxmoksa

Model działa z uprawnieniami użytkownika, którym się łączy, a nie z własnym kontem. Cokolwiek Proxmox zamyka temu użytkownikowi, zostaje zamknięte dla modelu. Atlas nie buduje własnego systemu uprawnień.

Konto Proxmoksa wyznacza zakres

Pole poleceń działa z uprawnieniami konta Proxmoksa, którym się łączy; Atlas nie wprowadza własnego pojęcia uprawnień. Kto chce wąskiego zakresu, daje wąskie konto, a ten zakres jest zapisany w uprawnieniach konta i stamtąd odczytywany przy audycie. Wyłączenie zapisu dla własnej sesji to jedno dotknięcie.

Wpływ pokazywany najpierw

Gdy proponowana jest zmiana, kroki do zastosowania, objęte zasoby i droga powrotu są pokazywane człowiekowi. Zatwierdzenie następuje na ekranie, a nie wewnątrz rozmowy.

Twarde potwierdzenie dla pracy nieodwracalnej

Jeśli konto, którym się łączy, nie ma uprawnienia, usunięcie, sformatowanie i rozebranie puli nie może się w ogóle wydarzyć. Tam, gdzie uprawnienie istnieje, obowiązuje twarde potwierdzenie stosowane w produkcie gdzie indziej: potwierdzeniem jest wpisanie nazwy, jedno kliknięcie nie wystarczy. Kto chce jeszcze jednego kroku, włącza go: operacje zapisu proszą o kod jednorazowy, tę samą weryfikację dwuetapową, której konto już używa.

Każdy krok jest zapisywany

Wszystko, co model czyta, i każda operacja, o którą prosi, trafia do dziennika audytu: który użytkownik, który model, kiedy, z jakim wynikiem. Zapisu nie da się później zmienić.

Odpowiedzi pokazują swoje źródło

Model mówi, skąd wyciągnął wniosek: z której linii dziennika, z którego pomiaru, z której konfiguracji. Odpowiedź, której nie da się sprawdzić, nie liczy się jako odpowiedź.

Czego model nie może zrobić

Granice żyją w produkcie, a nie w rozmowie. To, jak się model prosi ani jak mocno ktoś próbuje go przegadać, nie robi różnicy. W organizacji, która podłącza własny model, obowiązują te same granice, bo reguła jest egzekwowana na serwerze, a nie w modelu.

Nie może poszerzyć własnych uprawnień ani utworzyć nowego użytkownika lub klucza dostępu.

Nie może zastosować żadnej operacji zapisu bez zatwierdzenia.

Jeśli konto, którym się łączy, nie ma uprawnienia zapisu, niczego nie zmienia i tylko czyta.

Nie może otworzyć powłoki na serwerze ani zejść do wiersza poleceń. Rzadko jest to potrzebne, bo praca wymagająca głębi też jest pokryta: od pul ZFS po Ceph, od mostków po OVS, od przypięcia jądra po przekazanie uprawnień, a to pokrycie poszerza się z każdym wydaniem. Dla rzadkiej pracy, która wypada poza, pisze polecenie i wyjaśnia ryzyko, a uruchomienie pozostaje po stronie człowieka.

Nie może skasować ani zmienić zapisu audytu.

Dokąd trafiają dane

Serwer MCP to osobny komponent i nie przychodzi z domyślną instalacją. Dodaje się go z panelu jednym przyciskiem; na maszynie, która go nie chce, nie ma nawet jego plików. Po instalacji to, na które zasoby może patrzeć i jak długo pozostaje otwarty, pozostaje decyzją klienta.

To, z którym modelem się łączy, także jest wyborem klienta. Przy modelu lokalnym działającym na samym serwerze żadne dane nie opuszczają maszyny, a produkt pozostaje bez internetu. Jeśli wybrana zostanie usługa zewnętrzna, treść do wysłania jest widoczna przed wysłaniem.

Dla organizacji pod ścisłą regulacją

Nie deklarujemy żadnej certyfikacji. Produkt zaprojektowano tak, by spełniał wymagania ram o twardych warunkach audytu, a własny audyt organizacji może wykorzystać te zachowania jako dowód.

System zarządzania AI (ISO/IEC 42001): to, co model może robić, jest zapisane, granice są egzekwowane w produkcie, każde użycie jest zapisywane.

Bezpieczeństwo informacji (ISO/IEC 27001): dostęp pochodzi z systemu tożsamości, który organizacja już prowadzi, uprawnienie podąża za zasadą minimalnych uprawnień, a zapisów nie da się zmienić.

Zarządzanie ryzykiem AI (ISO/IEC 23894 i NIST AI RMF): żadnego działania autonomicznego, zatwierdzenie człowieka jest wymaganym krokiem w przepływie.

Dane osobowe (RODO i odpowiedniki): dane zostają na maszynie klienta; jeśli mają ją opuścić, najpierw są widoczne, a decyzja należy do klienta.

Infrastruktura krytyczna (NIS2 i przepisy o przejrzystości AI): po incydencie da się odczytać, kto co zrobił, co model zaproponował i kto to zatwierdził.

Częste pytania