Połączenie AI z serwerem: jak agent AI wdraża zmiany na Twoim serwerze i nim zarządza

Większość osób wciąż korzysta z AI jak z bardzo oczytanego kolegi po drugiej stronie słuchawki: opisuje problem z serwerem, dostaje propozycję polecenia, kopiuje je do konsoli, wkleja z powrotem komunikat błędu i powtarza całą zabawę, aż wszystko zadziała. Gdy tylko połączysz AI ze swoim serwerem, ta okrężna droga odpada. Agent AI, taki jak Claude Code, OpenAI Codex CLI lub Gemini CLI, sam loguje się na serwer przez SSH, czyta logi, sprawdza konfigurację, wprowadza zmiany, testuje wynik i zapisuje, co zrobił. Ty wyznaczasz zadanie i zatwierdzasz kroki, których nie da się cofnąć.

Ten artykuł to relacja z praktyki. W KernelHost agent AI od miesięcy codziennie pracuje razem z nami przy naszej własnej infrastrukturze: portal klienta, monitoring, kanały płatności, dokumentacja. Pokazujemy, jak zbudowane jest połączenie między agentem a serwerem, według jakiej procedury agent wdraża zmiany na systemach produkcyjnych, jakie zasady sprawiają, że nic przy tym nie pójdzie źle ani nie wycieknie na zewnątrz, i co musi zapewniać serwer, żeby całość działała. Podstawy dotyczące narzędzi i architektur opisuje artykuł Serwer zarządzany przez AI: bezpieczne łączenie agentów AI, a instalację na serwerze poradnik dla Claude Code i Codex CLI.

Połączenie AI z serwerem: co to oznacza

Połączenie AI z serwerem oznacza, że agent AI dostaje własny, kontrolowany dostęp do wiersza poleceń serwera, zwykle przez klucz SSH. Od tej chwili agent może nie tylko proponować polecenia, ale też sam je wykonywać, czytać wynik i wyprowadzać z niego kolejny krok. Sam model językowy nadal działa u dostawcy (Anthropic, OpenAI lub Google), a na Twoim komputerze lub serwerze działa tylko lekkie narzędzie wiersza poleceń, które wysyła polecenia.

Kluczowe jest słowo „kontrolowany”. Agent z dostępem do serwera nie jest autopilotem, tylko bardzo szybkim współpracownikiem, który pyta przed każdym działaniem ingerującym w system. O tym, ile wolno mu zrobić bez pytania, decydujesz Ty: od dostępu wyłącznie do odczytu po samodzielne instalowanie aktualizacji według stałej procedury.

Chatbot czy agent: różnica w jednej tabeli

Pół godziny przerzucania tekstu tam i z powrotem często skraca się w ten sposób do kilku minut, a źródło błędów „źle przepisane” znika całkowicie.

Co agent AI robi na serwerze: przykłady z naszej praktyki

Poniższe przykłady pochodzą z naszej codziennej pracy. Pomijamy nazwy, adresy i dane dostępowe, ale przebiegi są prawdziwe.

Wdrożenia z kopią zapasową i ścieżką wycofania

Gdy zmieniamy coś w portalu klienta albo w skrypcie serwerowym, wdrożenie przejmuje agent. Najpierw porównuje plik na serwerze z ostatnim znanym stanem, żeby nie nadpisać cudzej zmiany. Potem tworzy datowaną kopię zapasową poza katalogiem WWW, pisze skrypt wycofania, sprawdza składnię nowego pliku, wgrywa go z tymi samymi właścicielami i uprawnieniami co wcześniej, a następnie testuje funkcję, której dotyczy zmiana. Dopiero gdy wszystko świeci na zielono, melduje wykonanie zadania. Dokładny przebieg opisujemy niżej, w części o wdrażaniu.

Szukanie błędów: od objawu do przyczyny w kilka minut

„Strona jest nieosiągalna z naszego biura, a spoza biura działa”. Kiedyś oznaczałoby to dłuższe poszukiwania. Agent sprawdza reguły zapory, przeszukuje logi oprogramowania ochronnego pod kątem adresu biura, znajduje regułę, która zadziałała, i wyjaśnia, które żądanie ją wywołało. Decyzja, co zrobić, zostaje po naszej stronie, praca detektywistyczna już nie. Przy typowych błędach serwera WWW, takich jak 502 Bad Gateway czy zapełnione dyski, postępuje tak samo: czyta wpisy z journalctl i logi aplikacji, stawia hipotezę i potwierdza ją dowodami, zanim cokolwiek zmieni.

Monitoring, który agent buduje sam

Duża część naszego monitoringu powstała we współpracy z agentem: małe skrypty kontrolne, które co kilka minut, uruchamiane przez zadanie cron, testują usługę od początku do końca, a w razie błędu wysyłają wiadomość na telefon, na przykład przez bota w Telegramie. Agent pisze skrypt, testuje go na celowo wywołanym błędzie, konfiguruje zadanie cron i dokumentuje, jak wyciszyć alarm. Jak w ogóle zbudować coś takiego, opisuje artykuł Konfiguracja monitoringu serwera.

Zestawienia i porządki

Które serwery nadal działają, choć powiązana z nimi umowa została wypowiedziana? Które usługi dodatkowe są opłacane, ale już nieużywane? Na takie pytania agent odpowiada, odpytując bazy danych i interfejsy API wyłącznie w trybie odczytu i przygotowując wynik w formie tabeli. Sprzątać może dopiero po zatwierdzeniu, a wcześniej sprawdza, czy maszyna naprawdę nie jest używana, na przykład na podstawie ruchu sieciowego z ostatnich dni.

Dokumentacja, która rośnie sama

Każda zmiana kończy się wpisem w dzienniku zmian i w razie potrzeby uzupełnieniem podręcznika operacyjnego. Agenta kosztuje to kilka sekund, a nam później oszczędza godziny, bo pytanie „Dlaczego właściwie jest tak, a nie inaczej?” ma pisemną odpowiedź.

Korzyści, gdy AI pracuje bezpośrednio na serwerze

• Tempo: agent w kilka sekund czyta to, na co człowiek potrzebuje minut, i od razu sprawdza hipotezę, zamiast najpierw ją opisywać.
• Dokładność: czyta całą konfigurację razem z dołączonymi plikami oraz wiersze logu wokół błędu, a nie tylko fragment, który ktoś uznał za istotny.
• Powtarzalny przebieg: kopia zapasowa, sprawdzenie składni i kontrola odbywają się za każdym razem, także w piątek wieczorem i także przy dwudziestej drobnej zmianie.
• Dokumentacja bez dodatkowej pracy: każda zmiana jest opisana, razem z powodem, miejscem kopii zapasowej i ścieżką wycofania.
• Automatyzacja bez studiowania skryptów: skrypty kontrolne, zadania cron i raporty powstają z opisu zwykłym językiem i są testowane przed użyciem.
• Nauka przy okazji: agent wyjaśnia, co robi i dlaczego. Kto czyta na bieżąco, po kilku tygodniach znacznie lepiej rozumie swój serwer.

Trzy architektury i ta, którą stosujemy

Istnieją trzy sprawdzone sposoby połączenia agenta z serwerem. Różnią się tym, gdzie działa narzędzie i gdzie przechowywane są dane dostępowe.

Nasz wybór: agent na stacji roboczej, serwery przez SSH

Pracujemy z pierwszym wariantem. Agent działa na komputerze roboczym, każdy serwer ma wpis w konfiguracji SSH, a agent łączy się własnym kluczem. Najważniejszy powód: opiekujemy się wieloma systemami i właśnie w ten sposób jeden agent może w jednej sesji śledzić przyczynę przez kilka serwerów, na przykład od serwera WWW przez bazę danych aż po zaporę. Poza tym logowanie u dostawcy AI i klucze znajdują się w miejscu, które i tak chronimy. Kto ma tylko jeden serwer i chce dostawać automatyczne raporty w nocy, dobrze wyjdzie na drugim wariancie. Więcej o zaletach i wadach piszemy w artykule o serwerze zarządzanym przez AI.

Poradnik: jak połączyć agenta AI z serwerem przez SSH

Poniższe siedem kroków działa tak samo w Claude Code, Codex CLI i Gemini CLI. Przykłady używają adresu dokumentacyjnego 203.0.113.10 i nazwy użytkownika deploy, zastąp jedno i drugie własnymi wartościami. Warunkiem jest serwer z logowaniem kluczem SSH, jak opisano w artykule Zabezpieczenie SSH i logowanie kluczem.

Krok 1: wygenerować osobny klucz SSH tylko dla agenta

Agent nigdy nie dostaje Twojego osobistego klucza, tylko własny. Dzięki temu możesz w każdej chwili odebrać mu dostęp, nie tracąc swojego, a w logach widać, które logowanie pochodziło od agenta.

ssh-keygen -t ed25519 -C "ki-agent" -f ~/.ssh/ki_agent_ed25519

Ed25519 jest krótki, szybki i uchodzi za bezpieczny. Komentarz ki-agent pojawi się później w pliku authorized_keys na serwerze i pozwoli rozpoznać klucz na pierwszy rzut oka.

Krok 2: umieścić klucz publiczny na serwerze

ssh-copy-id -i ~/.ssh/ki_agent_ed25519.pub deploy@203.0.113.10

Kto chce dodatkowo ograniczyć dostęp, dopisuje w pliku ~/.ssh/authorized_keys na serwerze opcje przed kluczem. from= zezwala na logowanie tylko z określonego adresu, a no-agent-forwarding i no-port-forwarding nie pozwalają wykorzystać połączenia jako odskoczni:

from="198.51.100.7",no-agent-forwarding,no-port-forwarding,no-X11-forwarding ssh-ed25519 AAAA... ki-agent

Jeśli serwer zgłosi potem Permission denied (publickey), pomoże artykuł Naprawa błędu SSH Permission denied (publickey).

Krok 3: utworzyć alias hosta w konfiguracji SSH

Alias sprawia, że agent musi znać tylko krótką nazwę i zawsze używa właściwego klucza:

Host web-prod
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/ki_agent_ed25519
    IdentitiesOnly yes
    ServerAliveInterval 30

Potem wystarczy ssh web-prod "systemctl status nginx". IdentitiesOnly yes nie pozwala SSH wypróbowywać innych kluczy z Twojego pęku kluczy. Dla każdego kolejnego serwera tworzysz osobny blok, a dla systemów testowych i produkcyjnych najlepiej z różnymi nazwami, takimi jak web-test i web-prod, żeby pomyłka rzucała się w oczy już po samej nazwie.

Krok 4: zainstalować agenta i zalogować się

Claude Code, Codex CLI i Gemini CLI działają na Linuksie, macOS i Windows, a logujesz się do nich kontem u dostawcy albo kluczem API. Instalację i logowanie bez przeglądarki opisuje poradnik krok po kroku. W wariancie ze stacją roboczą instalujesz narzędzie na swoim komputerze, nie na serwerze.

Krok 5: ustalić zasady, których agent przestrzega

Wszystkie trzy narzędzia przy starcie czytają plik z zasadami w katalogu roboczym: Claude Code plik CLAUDE.md, Codex CLI plik AGENTS.md, a Gemini CLI plik GEMINI.md. Opisuje on, jak wygląda praca na Twoich serwerach. Sprawdzony początek:

# Zasady pracy na serwerach

- Przed każdą zmianą utwórz datowaną kopię zapasową, poza katalogiem WWW.
- Przed wdrożeniem sprawdź składnię (nginx -t, php -l, apachectl configtest).
- Po wdrożeniu sprawdź usługę, log i działanie funkcji, a potem zgłoś wynik.
- Nigdy nie wypisuj haseł, kluczy API ani tokenów, nigdy nie kopiuj ich do plików.
- Usuwanie, zmiany w bazie danych i wszystko, co nieodwracalne, tylko po wyraźnym zatwierdzeniu.
- Nie zmieniaj bezpośrednio plików, którymi zarządza panel sterowania.
- Po teście usuń pliki testowe.

Zasady rozwijają się z czasem. Za każdym razem, gdy agent zrobi coś inaczej, niż chcesz, poprawka trafia jako zasada do tego pliku. Po kilku tygodniach pracuje tak, jak pracujesz Ty.

Krok 6: ustawić zatwierdzenia i białą listę

Domyślnie narzędzia pytają przed każdym poleceniem, które coś zmienia. Na początku jest to właściwe. Na polecenia odczytowe, które ciągle zatwierdzasz, możesz zezwolić z góry. W Claude Code robi się to w pliku .claude/settings.json:

{
  "permissions": {
    "allow": [
      "Bash(ssh web-prod journalctl:*)",
      "Bash(ssh web-prod systemctl status:*)",
      "Bash(ssh web-prod df -h)"
    ]
  }
}

Wszystko, czego nie ma na tej liście, nadal wymaga Twojej zgody. Przełączniki, które wyłączają wszystkie pytania o zgodę, należą co najwyżej na jednorazową maszynę testową.

Krok 7: pierwsze zadanie: tylko odczyt

Zacznij od zadań, które nie mogą niczego zmienić, i obserwuj, jak agent postępuje:

Sprawdź na web-prod błędy nginx z ostatnich 24 godzin i podaj trzy
najczęstsze przyczyny, każdą z jednym dowodem z logu. Niczego nie zmieniaj.

Dopiero gdy analizy są trafne, przychodzi kolej na małe zmiany, na przykład nową rotację logów albo usługę systemd, a dopiero potem na wdrożenia na systemie produkcyjnym.

Tak agent przeprowadza wdrożenia: nasza procedura dla każdej zmiany na systemie produkcyjnym

Agent AI może wdrażać zmiany na systemie produkcyjnym tylko według stałej procedury, która obejmuje kopię zapasową, przygotowaną ścieżkę wycofania oraz kontrolę przed wdrożeniem i po nim. U nas ta procedura wygląda tak:

1. Sprawdzenie aktualnego stanu. Plik na serwerze jest porównywany z ostatnim znanym stanem. Jeśli ktoś inny w międzyczasie go zmienił, agent przerywa pracę i pyta, zamiast nadpisać cudzą zmianę.
2. Utworzenie kopii zapasowej. Pliki, których dotyczy zmiana, trafiają z datą do katalogu kopii poza katalogiem WWW. Kopia w katalogu WWW mogłaby w pewnych okolicznościach być publicznie dostępna.
3. Przygotowanie ścieżki wycofania. Mały skrypt, który jednym poleceniem przywraca poprzedni stan, powstaje przed zmianą, a nie dopiero w sytuacji awaryjnej.
4. Sprawdzenie składni. Nowy plik jest sprawdzany przed wdrożeniem, w przypadku PHP poleceniem php -l, w przypadku nginx poleceniem nginx -t. Dzięki temu błąd składni w ogóle nie trafia na system produkcyjny.
5. Wdrożenie z właściwymi uprawnieniami. Właściciel, grupa i uprawnienia pliku są przejmowane z poprzedniego stanu. Błędne uprawnienia to, zaraz po błędach składni, najczęstsza przyczyna awarii po aktualizacji.
6. Testy bez skutków ubocznych. Testuje się w trybie odczytu, na zmyślonych danych testowych albo w odizolowanym środowisku, nigdy na prawdziwych zamówieniach ani prawdziwych danych klientów.
7. Kontrola na żywo. Po wdrożeniu sprawdzane są status HTTP, log błędów i zmieniona funkcja.
8. Dokumentacja. Dziennik zmian i podręcznik operacyjny zostają uzupełnione, łącznie z miejscem kopii zapasowej i poleceniem do wycofania zmian.

Jako sekwencja poleceń, z symbolami zastępczymi zamiast prawdziwych ścieżek, wygląda to mniej więcej tak:

ZIEL=/var/www/app/config.php
SICH=/var/backups/agent/$(date +%F-%H%M)
mkdir -p "$SICH" && chmod 700 "$SICH"
cp -a "$ZIEL" "$SICH/"
echo "cp -a $SICH/config.php $ZIEL" > "$SICH/rueckweg.sh"
php -l neu/config.php
install -o www-data -g www-data -m 640 neu/config.php "$ZIEL"
curl -fsS -o /dev/null -w "%{http_code}\n" https://example.com/

Dlaczego ścieżka wycofania powstaje przed zmianą

W razie awarii nikt nie jest w najlepszej formie, żeby obmyślać czyste wycofanie zmian. Jeśli skrypt jest już gotowy, wycofanie to kwestia sekund, a agent może je wykonać także sam, gdy kontrola po wdrożeniu się nie powiedzie. To największa różnica między agentem, który „na szybko” coś zmienia, a takim, któremu powierza się system produkcyjny.

Testy, które niczego nie mogą zepsuć

Wielu funkcji nie da się przetestować tak, żeby nic się nie wydarzyło: zamówienie, płatność, e-mail. Tu pomagają trzy techniki. Po pierwsze próby na sucho, które oferuje samo narzędzie. Po drugie zmyślone identyfikatory, które na pewno nigdzie nie istnieją. Po trzecie odizolowane środowisko: proces działający we własnej przestrzeni nazw sieci bez dostępu do sieci (unshare -n) nie dotrze do zewnętrznego interfejsu API ani przypadkiem niczego nie kupi, ale nadal widzi lokalną bazę danych przez gniazdo Unix. Po teście wszystkie pliki testowe są usuwane.

Działania, które kosztują pieniądze, potrzebują blokady

Jeśli procedura coś zamawia, rozlicza albo usuwa, nie może działać dwa razy jednocześnie, także wtedy, gdy ktoś kliknie dwukrotnie albo agent powtórzy polecenie. Najprostszym rozwiązaniem w Linuksie jest flock:

flock -n /run/lock/bestellung.lock ./bestellung-ausfuehren.sh || echo "już działa"

W aplikacjach bazodanowych ten sam cel spełnia nazwana blokada (GET_LOCK w MySQL i MariaDB), a w interfejsach API nagłówek Idempotency-Key, więcej o tym w części o KernelHost API poniżej.

Bezpieczeństwo: dostęp dla agenta tak, by nic nie wyciekło

Obawa, którą słyszymy najczęściej, brzmi: „A co z moimi danymi?” Szczera odpowiedź: wszystko, co agent czyta, przekazuje do przetworzenia modelowi językowemu dostawcy. Dlatego to Ty decydujesz za pomocą poniższych zasad, co w ogóle może zobaczyć.

Sekretom nie ma miejsca w czacie

Hasła, klucze API i tokeny nigdy nie trafiają do treści zadania i agent nigdy ich nie wypisuje. Skrypty odczytują je z plików z uprawnieniami 600, których agent nie musi wyświetlać, żeby korzystać ze skryptu. Jeśli mimo to klucz trafi kiedyś do czatu, jest natychmiast blokowany u dostawcy i generowany na nowo. Do czatu nie należą też fragmenty: pierwsze znaki klucza nikomu nie pomogą w szukaniu błędu, ale skracają pracę atakującego.

Własne klucze, własne uprawnienia, odwołalne w każdej chwili

Każdy agent dostaje własny klucz SSH, a każdy klucz można rozpoznać w pliku authorized_keys po jego komentarzu. Kto chce odebrać dostęp, usuwa ten jeden wiersz. Tam, gdzie to wystarcza, agent pracuje na własnym użytkowniku z regułą sudo, która zezwala tylko na niezbędne polecenia. Interfejsy programistyczne dostają własne klucze z najmniejszymi możliwymi uprawnieniami, a do samych analiz tylko z prawem odczytu.

Zatwierdzenia: co nigdy nie dzieje się bez człowieka

Bez wyraźnej zgody agent nie może u nas niczego usuwać, zapisywać do baz danych, rozluźniać reguł zapory ani reguł ochrony, zatrzymywać maszyn ani niczego zamawiać. Narzędzia to wspierają: Claude Code wstrzymuje działania ingerujące w system i można go dodatkowo skonfigurować tak, by filtr bezpieczeństwa rozpoznawał ryzykowne polecenia i blokował je do czasu zatwierdzenia. Z naszej codziennej praktyki: ten filtr niejednokrotnie zatrzymał działanie, które merytorycznie było poprawne, ale jednak nieodwracalne. Zostało wykonane dopiero wtedy, gdy człowiek wyraźnie je zatwierdził. Dokładnie tak powinno być.

Możliwość prześledzenia: logi, lista zmian, kopie zapasowe

Każda sesja zostawia ślady, które człowiek może przeczytać: datowane kopie zapasowe, skrypt wycofania, wpis w dzienniku zmian i logowania zapisane w logu systemowym. Kto dodatkowo zarządza katalogiem /etc w Git za pomocą etckeeper, widzi każdą zmianę konfiguracji jako diff. Czego nie da się prześledzić, tego nie da się też cofnąć. Podstawą pozostaje działająca strategia kopii zapasowych, bo agent nie zastępuje kopii zapasowej.

Jaki serwer nadaje się dla agenta AI?

Serwer do zarządzania wspomaganego przez AI potrzebuje pełnego dostępu root, logowania kluczem SSH, swobodnych połączeń wychodzących, stałej ochrony DDoS i najlepiej interfejsu programistycznego, przez który można automatycznie zamawiać serwery i nimi sterować. GPU nie jest mu potrzebne, bo model językowy działa u dostawcy.

Dlaczego KernelHost dla serwerów zarządzanych przez AI

W zasadzie agent AI może pracować z każdym serwerem, na którym dostanie powłokę. W praktyce jednak to otoczenie decyduje o tym, ile pracy naprawdę możesz mu przekazać. Na serwerze root KVM lub serwerze dedykowanym KernelHost nie ma ograniczonych kont, przeszkód dla połączeń HTTPS do dostawców AI ani zobowiązań umownych, przez które testowanie robi się drogie. Stała ochrona DDoS jest aktywna na każdym serwerze bez dopłaty, a do zadań wymagających dużej mocy obliczeniowej są serwery VDS Professional z dedykowanymi rdzeniami. Rozliczenie odbywa się w modelu PrePaid: bez umowy, bez okresu minimalnego, bez opłaty instalacyjnej. Kto chce najpierw wypróbować, zaczyna od bezpłatnego serwera testowego.

KernelHost API: Twój agent sam zamawia serwery i nimi steruje

Największa dźwignia leży o poziom wyżej niż pojedynczy serwer. Przez KernelHost API agent może sprawdzać produkty i ceny, zamawiać serwery, odczytywać status swoich usług, uruchamiać, zatrzymywać i restartować serwery, a także składać i wycofywać wypowiedzenia. Dzięki temu „Skonfiguruj mi serwer testowy” staje się jednym zadaniem: agent zamawia maszynę, czeka na jej udostępnienie, łączy się przez SSH, instaluje aplikację i odsyła adres.

Z myślą o używaniu przez agentów interfejs zbudowano celowo ostrożnie. Klucze API dostają tylko te uprawnienia, których potrzebują, a klucz do analiz w ogóle nie może niczego zamówić. Nagłówek Idempotency-Key sprawia, że zamówienie, które agent powtórzy po błędzie przekroczenia czasu, nie zostanie wykonane dwa razy. Liczba zapytań jest ograniczona na klucz, na konto i na adres, więc nawet agent w nieskończonej pętli nie wywoła lawiny. Do tego każde pobranie danych dostępowych uruchamia powiadomienie e-mailem, dzięki czemu widzisz, kiedy agent odczytał dane dostępowe.

Ile kosztuje serwer zarządzany przez AI?

Koszty dzielą się na dwie pozycje. Po pierwsze sam serwer: dla agenta pracującego przez SSH nie potrzebuje on specjalnego wyposażenia, wystarczy każdy serwer root, na którym i tak działa Twoja aplikacja. Jeśli agent działa bezpośrednio na serwerze, samo narzędzie potrzebuje tylko kilkuset megabajtów pamięci operacyjnej, a serwer root z 2 vCPU i 4 GB RAM wystarczy, jeśli poza tym niewiele na nim działa. Po drugie model językowy: albo subskrypcja u dostawcy, która obejmuje korzystanie z narzędzia wiersza poleceń, albo klucz API z rozliczeniem według zużycia. Przy codziennym intensywnym użyciu subskrypcja jest zwykle tańsza, a do zautomatyzowanych zadań bez człowieka przy klawiaturze klucz API jest czystą drogą, bo można go ograniczyć miesięcznym budżetem. Aktualne ceny serwerów znajdziesz na stronie wynajmu serwerów root.

Częste błędy i jak ich unikać

• Agent pracuje na osobistym kluczu administratora. Wtedy jego dostępu nie da się odebrać osobno ani odróżnić w logach. Rozwiązanie: własny klucz z własnym komentarzem.
• Wszystkie pytania o zgodę są wyłączone. Pierwszego dnia oszczędza to kliknięcia, a prędzej czy później kosztuje serwer. Rozwiązanie: biała lista dla poleceń odczytowych, zatwierdzanie wszystkiego, co ingeruje w system.
• Brak kopii zapasowej przed zmianą. Rozwiązanie: kopia zapasowa i skrypt wycofania jako stała zasada w pliku CLAUDE.md lub AGENTS.md.
• Kopie zapasowe w katalogu WWW. Plik taki jak config.php.bak w katalogu głównym WWW może być publicznie dostępny, razem z hasłem do bazy danych. Rozwiązanie: katalog kopii zapasowych poza katalogiem WWW z uprawnieniami 700.
• Sekrety w promptcie. Rozwiązanie: dane dostępowe tylko w plikach z uprawnieniami 600, które czytają skrypty, a w razie pomyłki natychmiastowe wygenerowanie nowych.
• Podwójne wykonanie. Podwójne kliknięcie albo powtórzone zapytanie składa zamówienie dwa razy. Rozwiązanie: blokada przez flock albo Idempotency-Key.
• Bezpośrednio zmienione pliki zarządzane przez panel sterowania. Panel nadpisuje je przy następnej aktualizacji albo się przez nie psuje. Rozwiązanie: wykluczyć takie pliki w zasadach i wprowadzać zmiany przez panel lub jego interfejs API.
• Wyniki przyjęte bez sprawdzenia. Agent, który nie rozumie wyniku, zgaduje. Rozwiązanie: żądać dowodów („pokaż mi wiersz z logu”) i zlecać sprawdzanie wyników na żywo.

W skrócie

• Połączenie AI z serwerem oznacza, że agent taki jak Claude Code, Codex CLI lub Gemini CLI dostaje własny klucz SSH i jasne zasady.
• Agent czyta logi, wprowadza zmiany, sprawdza wynik i go dokumentuje, a kroki ingerujące w system wykonuje tylko po zatwierdzeniu.
• Każde wdrożenie przebiega według stałej procedury: sprawdzenie aktualnego stanu, kopia zapasowa, przygotowanie ścieżki wycofania, sprawdzenie składni, wdrożenie, testy, kontrola na żywo, dokumentacja.
• Sekrety nigdy nie trafiają do czatu, a działania, które kosztują pieniądze, potrzebują blokady przed podwójnym wykonaniem.
• Serwer potrzebuje dostępu root, kluczy SSH, swobodnych połączeń wychodzących i ochrony DDoS, ale nie potrzebuje GPU.
• Serwery KernelHost spełniają wszystkie wymagania od pierwszej chwili, w modelu PrePaid bez zobowiązań umownych, a przez KernelHost API agent może nawet sam zamawiać serwery i nimi sterować.