Jak bezpiecznie skonfigurować DeepSeek Super Agent: konta, uprawnienia i izolacja

Nie rozpoczynaj eksperymentów z dsh-superagent na swoim zwykłym koncie ani w cennym repozytorium produkcyjnym. Dokumentacja wdrożeniowa informuje, że zarówno ustawienia wstępne routera, jak i workera uruchamiają się z uprawnieniami danger-full-access użytkownika systemu operacyjnego i mogą odczytywać katalog domowy tego użytkownika. Dedykowane konto i tymczasowe repozytorium należy przygotować przed instalacją i testowaniem, a nie dopiero po pierwszym nieoczekiwanym działaniu.

Publiczne repozytorium zawiera prototyp badawczy, a nie oficjalny, gotowy do użycia w środowisku produkcyjnym produkt DeepSeek. Ten przewodnik przekłada udokumentowane ustawienia domyślne na ostrożny plan konfiguracji: oddzielne tożsamości, ograniczony dostęp do repozytorium, sprawdzone reguły dopuszczania, kontrolowane wykonywanie i przetestowana procedura zatrzymywania. Dane uwierzytelniające wprowadzaj wyłącznie za pośrednictwem własnego, zatwierdzonego terminala lub systemu zarządzania sekretami, nigdy w rozmowie na czacie.

Czy dsh-superagent jest gotowy do użycia w środowisku produkcyjnym?

README wyraźnie informuje, że jest to kod badawczy, a opublikowana implementacja różni się od systemu wewnętrznego i niektórych pomysłów opisanych w powiązanym artykule projektowym. Ten status powinien być wyraźnie uwzględniony przy podejmowaniu decyzji o wdrożeniu. Publiczna dostępność daje możliwość sprawdzenia projektu, ale nie gwarantuje, że kod jest gotowy do obsługi wrażliwych operacji.

Ten przewodnik sprawdzono w odniesieniu do wersji 8c32a9dc5d72c033816c6a8110b37f40cf94fba4 z 5 listopada 2026 r. Przypnij i zapisz wersję, którą faktycznie sprawdzasz. Jeśli później zaktualizujesz kopię roboczą, przed ponownym uruchomieniem sprawdź ponownie wymagania wstępne, uprawnienia, ustawienia wstępne i migracje konfiguracji.

Dokument konfiguracji opisuje interaktywny proces planowania i potwierdzania. Przed wykonaniem sprawdź plan. Nie traktuj instrukcji, by pozwolić agentowi programistycznemu pomóc w konfiguracji, jako zgody na dostęp do niezwiązanych z nią poświadczeń ani instalację w zwykłym profilu roboczym.

Pierwszy cel akceptacyjny powinien być skromny: jedno nieszkodliwe żądanie tworzy zrozumiałe zadanie i możliwy do sprawdzenia wynik w tymczasowym repozytorium. Przetestuj też odrzucanie żądań i zatrzymywanie działania. Udana demonstracja standardowej ścieżki nie potwierdza niezawodności w środowisku produkcyjnym ani nie uzasadnia natychmiastowego rozszerzenia dostępu.

Dlaczego warto używać dedykowanego konta systemu operacyjnego?

Przewodnik wdrożeniowy wyraźnie wskazuje założenie dotyczące dostępu hosta. Oddzielne katalogi sesji i opakowania poświadczeń nie izolują procesu. Worker może uruchamiać programy i uzyskiwać dostęp do plików dostępnych dla konta, na którym działa, w tym do katalogu domowego tego konta.

Utwórz dedykowane konto zawierające tylko pliki i dane uwierzytelniające potrzebne do eksperymentu. Poza jego dostępnym środowiskiem przechowuj osobiste klucze SSH, poświadczenia administratora chmury, profile przeglądarek, konfigurację produkcyjną i niezwiązane repozytoria. Sprawdź członkostwo w grupach i zamontowane zasoby, a także katalog domowy konta.

Aby uzyskać większą separację, rozważ użycie dedykowanej, jednorazowej maszyny wirtualnej lub podobnie kontrolowanego środowiska hosta. Nie zakładaj, że sam kontener zapewnia wystarczającą ochronę tylko dlatego, że ma inny widok systemu plików; rzeczywiste granice wyznaczają montowania, uprawnienia, gniazda i sieć. Decyzja dotycząca wdrożenia powinna uwzględniać wartość hosta i wykonywanego kodu.

Nasze omówienie architektury wyjaśnia, dlaczego te mechanizmy kontrolne działają na różnych warstwach. Rozdzielenie warstw zapobiega uznaniu wąskiego zabezpieczenia, takiego jak krótka lista osób zgłaszających zadania, za kompleksową izolację.

Okładka: repozytorium prototypu dsh-superagent, karta repozytorium wygenerowana przez GitHub. Metadane repozytorium to datowana ilustracja, a nie deklaracja dotycząca adopcji ani wydajności.

Jak utworzyć tożsamość agenta GitHub?

Zamiast konta osobistego użyj dedykowanego konta użytkownika GitHub, wymaganego przez obecny prototyp. Zgodnie z przewodnikiem wdrożeniowym ta implementacja odczytuje powiadomienia z konta i nie obsługuje zastąpienia tożsamości agenta aplikacją GitHub App. To ograniczenie implementacyjne, a nie ogólne zalecenie, by nie używać GitHub Apps w innych systemach.

Początkowo przyznaj dostęp tylko do jednorazowego repozytorium testowego. Konfigurację logowania agenta trzymaj oddzielnie od własnej. Użyj udokumentowanego podejścia z wrapperem lub równoważnej zatwierdzonej konfiguracji i sprawdź, którego konta używa CLI, zanim zezwolisz procesowi na działanie. Nie wyciągaj wniosków o tożsamości na podstawie nazwy wyświetlanej na czacie.

Wytyczne GitHub dotyczące tokenów wyjaśniają dostępne opcje uprawnień i czasu wygaśnięcia. Wybierz minimalny obsługiwany zakres dostępu potrzebny do wykonania udokumentowanych operacji prototypu, sprawdź wymagania dotyczące zgodności i zachowaj możliwość unieważnienia tokena. Nie przyznawaj kontu uprawnień administracyjnych w organizacji ani możliwości wdrażania na produkcję tylko dla wygody.

Na potrzeby początkowego eksperymentu pozostaw scalanie ludziom. Agent, który może wypchnąć gałąź i otworzyć pull request, nie potrzebuje również uprawnień do zmieniania zabezpieczeń repozytorium ani akceptowania własnej pracy. Tożsamość powinna jasno wskazywać autora, a decyzja o akceptacji powinna pozostać niezależna.

Jak działają listy dozwolonych użytkowników i zasady dopuszczania?

Dokument autoryzacji rozróżnia jawne polecenia, wywnioskowane kandydatury i dane wejściowe, które nie są dopuszczane. Znaczenie mają zarówno dozwolone tożsamości, jak i ustawienia dopuszczania dotyczące konkretnego zakresu. Krótka lista dozwolonych użytkowników jest przydatna, ale należy ją przeglądać razem z zakresem odbioru i regułami, a nie traktować jako jedyny mechanizm kontroli.

Zacznij od jednego znanego zleceniodawcy i jednego repozytorium. Jeśli Feishu nie jest potrzebne do testu, nie konfiguruj go. Każde dodatkowe źródło to kolejne miejsce, w którym trzeba zweryfikować tożsamość, zakres odbioru, działanie bota i uprawnienia do inicjowania pracy. Dodawaj źródła dopiero wtedy, gdy pierwszy przepływ pracy będzie już zrozumiały.

Testuj działanie zasad na nieszkodliwych przykładach. Sprawdź, co się dzieje, gdy do agenta zwraca się dozwolona osoba, gdy ktoś publikuje niezwiązaną z tematem dyskusję oraz gdy w dalszej wiadomości prosi o pracę wykraczającą poza istniejące zadanie. Zamiast zakładać, że brak widocznej odpowiedzi oznacza brak działania, sprawdź zapis decyzji.

Treści repozytorium i cytowane wiadomości powinny pozostać materiałem dowodowym, a nie aktualizacjami zasad. Instrukcja osadzona w zgłoszeniu lub dokumencie nie powinna po cichu przyznawać dostępu ani zmieniać tego, kto może zlecać zadania. Nasze porównanie z proactive-agent wyjaśnia, dlaczego przepływy pracy połączone ze zdarzeniami sprawiają, że to rozróżnienie jest ważniejsze niż podczas pojedynczej nadzorowanej sesji czatu.

Dlaczego warto zacząć od trybu Observe?

W udokumentowanym domyślnym trybie observe system ocenia wywnioskowane kandydatury i zapisuje, które zostałyby zaakceptowane, nie akceptując ich automatycznie. To przydatne do sprawdzenia, jak działają skonfigurowane reguły. Tryb ten nie blokuje wykonywania jawnych, autoryzowanych poleceń, więc nie jest globalnym trybem tylko do odczytu ani trybem niewykonywania działań.

Zachowaj wąski zakres uprawnień technicznych eksperymentu także podczas obserwacji. Jeśli celem jest sprawdzenie routingu bez dopuszczania wartościowych zmian, użyj zasobów tymczasowych i egzekwuj to ograniczenie za pomocą konfiguracji hosta i repozytorium. Nie polegaj na etykiecie trybu, która ma chronić zasoby, do których proces i tak ma dostęp.

Sprawdzaj zarówno pozytywne, jak i negatywne decyzje. Reguła, która akceptuje zbyt wiele, może uruchomić niepożądane zadania, a reguła akceptująca zbyt mało może po cichu pomijać oczekiwane zadania. Zanim zmienisz zasady, zapisz, dlaczego oczekiwany wynik różni się od zaobserwowanego. Wielokrotne rozszerzanie reguł aż do uzyskania poprawnego wyniku demonstracji to zły sposób na ustalenie bezpiecznych ustawień domyślnych.

Nie przełączaj rutynowo trybu instalacji na auto. Ten tryb zwiększa możliwości systemu w zakresie rozpoczynania zadań wywnioskowanych na podstawie pasujących reguł. Każde późniejsze rozszerzenie wymaga wyraźnego wskazania właściciela, sprawdzonego zestawu reguł, kontrolowanego zapisu oceny oraz przetestowanego sposobu zatrzymania lub cofnięcia dostępu.

Jak chronić tokeny, sekrety i pliki lokalne?

Nie umieszczaj danych uwierzytelniających w promptach, plikach repozytorium, zrzutach ekranu ani zwykłych dziennikach. Korzystaj z zatwierdzonego logowania przez CLI lub magazynu sekretów w dedykowanym środowisku. Wytyczne OWASP dotyczące zarządzania sekretami zawierają informacje o kontroli dostępu i cyklu życia, ale najważniejszy wymóg jest prosty: środowisko agenta nie powinno zawierać danych uwierzytelniających niezwiązanych z jego zadaniem.

Sprawdź ścieżkę przetwarzania przez dostawcę modelu, a także tożsamość GitHub. Kod i prompty mogą być przetwarzane przez skonfigurowanego dostawcę, a narzędzia mogą łączyć się z dodatkowymi adresami. Lokalna kopia repozytorium nie oznacza lokalnego wnioskowania ani przetwarzania wyłącznie lokalnie. Upewnij się, że wybrany dostawca i konfiguracja rejestrowania są zatwierdzone do użycia z materiałami testowymi.

Nie kopiuj katalogu domowego ani konfiguracji powłoki do dedykowanego konta, żeby ułatwić konfigurację. Mogą się tam znajdować narzędzia do obsługi danych uwierzytelniających, zmienne środowiskowe, konfiguracja chmury i prywatna historia. Celowo odtwórz tylko minimalny zestaw zależności i prowadź wykaz dodanych elementów, który nie zawiera sekretów.

Nasza lista kontrolna dostępu agenta osobistego zawiera powiązany etap przygotowań. Przed pierwszym uruchomieniem sprawdź w rzeczywistym środowisku agenta, do których katalogów, danych uwierzytelniających, usług i adresów sieciowych ma on dostęp. Jeśli zakres jest szerszy, niż wymaga tego test, najpierw skoryguj ograniczenia.

Jak odizolować repozytorium i przeglądać zmiany?

Użyj tymczasowego repozytorium zawierającego syntetyczne przykłady i żadnych tajemnic produkcyjnych. Dokumentacja konfiguracji wymienia wymagania wstępne, w tym zgodną wersję Node.js, pnpm, Git, tmux, Python, GitHub CLI i DeepSeek Harness. Sprawdź aktualny plik package.json i przewodnik konfiguracji, aby ustalić dokładne wymagania dotyczące zgodności, zamiast instalować dowolne wersje na podstawie starej listy poleceń.

Przed uruchomieniem planu instalacji wykonaj poniższe czynności w podanej kolejności:

1. Przygotuj dedykowane konto lub tymczasowy host i potwierdź granice dostępu.
2. Utwórz dedykowane konto GitHub i repozytorium testowe z odpowiednio ograniczonymi uprawnieniami.
3. Pobierz prototyp, zapisz jego rewizję i zapoznaj się z dokumentacją konfiguracji oraz wdrożenia.
4. Sprawdź proponowany plan instalacji, dostawcę modelu, profil, lokalizację stanu i mechanizm obsługi danych uwierzytelniających.
5. Na pierwszą próbę skonfiguruj przyjmowanie zadań wyłącznie z GitHuba, krótką listę zgłaszających, tryb observe i brak automatycznego scalania.
6. Uruchom sprawdzoną konfigurację i sprawdź stan oraz wymagania konfiguracyjne.
7. Prześlij jedno niegroźne, autoryzowane zadanie i sprawdź wynikowy stan oraz proponowaną zmianę.
8. Przetestuj nieistotne dane wejściowe, rozszerzenie zakresu i procedurę zatrzymywania, zanim rozważysz szerszy dostęp.

Udokumentowane polecenie sprawdzające stan przydaje się po konfiguracji:

scripts/dsh-superagent status

Uruchom go ze sprawdzonej kopii repozytorium w dedykowanym środowisku. Interpretuj wyniki zgodnie z aktualnym przewodnikiem wdrożeniowym; działający proces nie oznacza, że źródło ani zasady są prawidłowe i poprawnie skonfigurowane.

Przestrzegaj wymagań dotyczących chronionych gałęzi i zapewnij weryfikację przez człowieka. Sprawdź różnice, początkową i końcową rewizję, testy oraz nierozstrzygnięte założenia. Ważne dane przechowuj w niezależnych kopiach; nasz przewodnik po odzyskiwaniu plików wyjaśnia, dlaczego odzyskiwanie trzeba zaplanować przed przyznaniem uprawnień do zapisu.

Jak zatrzymać agenta i odebrać mu dostęp?

Opisz procedurę zatrzymywania przed pierwszym zadaniem. Aktualny przewodnik wdrożeniowy zawiera polecenie łagodnego zatrzymania:

scripts/dsh-superagent stop
scripts/dsh-superagent status

Łagodne zatrzymanie może poczekać na zakończenie wykonywania zadania; nie oznacza to, że wszystkie skutki zewnętrzne zostały cofnięte. Sprawdź oczekujące zadania i istotną aktywność w repozytorium. Nie zastępuj ustalenia, co robi proces, wymuszonym zamykaniem niezwiązanych z nim sesji.

W przypadku incydentu związanego z dostępem lub porzuconego eksperymentu unieważnij dedykowane dane uwierzytelniające i odbierz dostęp do repozytorium za pomocą odpowiednich ustawień dostawcy. Wstrzymaj przyjmowanie zadań i sprawdź pozostałe procesy w tle lub usługi. Zachowaj niepoufny zapis dotyczący zadania, którego dotyczył problem, rewizji i istotnej aktywności, aby zespół mógł odtworzyć przebieg zdarzenia.

Usuwanie i odzyskiwanie to odrębne zadania. Usunięcie lokalnego katalogu nie unieważnia tokenu, nie zamyka zdalnego pull requesta ani nie cofa wypchniętej zmiany. Osobno zdecyduj, co ma się stać z każdym artefaktem, i przed usunięciem zachowaj potrzebne dowody. Rozszerz eksperyment dopiero wtedy, gdy zatrzymywanie, unieważnianie dostępu i odzyskiwanie stanu są równie zrozumiałe jak jego uruchamianie.

W przypadku samego wyniku zastosuj procedurę przeglądu agentic-autofix. Działający proces i przyjęte zadanie są sygnałami operacyjnymi; nie dowodzą, że proponowaną przez niego poprawkę należy scalić.

Często zadawane pytania

Czy mogę uruchomić prototyp na moim zwykłym koncie programisty?

Dzięki temu proces uzyskuje dostęp do plików i danych uwierzytelniających dostępnych dla tego konta. Pierwszy eksperyment przeprowadź w dedykowanym, ograniczonym środowisku, zwłaszcza że udokumentowane ustawienia wstępne zapewniają pełny dostęp.

Czy tryb obserwacji sprawia, że prototyp działa tylko do odczytu?

Nie. Ogranicza przyjmowanie kandydatów wywnioskowanych przez system, ale jawne, autoryzowane żądania nadal mogą być realizowane. Jeśli celem testu jest zakaz zapisu, wymuś go za pomocą uprawnień.

Czy zamiast dedykowanego konta użytkownika mogę użyć aplikacji GitHub?

Instrukcja wdrożenia sprawdzonego prototypu wymaga konta użytkownika ze względu na obsługę powiadomień. Przed założeniem, że to ograniczenie dotyczące zgodności nadal obowiązuje, sprawdź późniejsze wersje.

Czy mam wkleić tokeny konfiguracyjne na czacie agenta asystującego?

Nie. Korzystaj z zatwierdzonego uwierzytelniania CLI lub magazynu sekretów we własnym, kontrolowanym środowisku. Konfiguracja nie wymaga ujawniania wartości sekretów w rozmowie.

Co dowodzi, że można bezpiecznie rozszerzyć początkowy test?

Żaden pojedynczy test nie dowodzi ogólnego bezpieczeństwa. Sprawdź decyzje dotyczące przyjmowania zadań, granice uprawnień, proponowane zmiany, zachowanie przy zatrzymywaniu oraz dowody umożliwiające przywrócenie stanu, a następnie zatwierdź wyłącznie konkretny dodatkowy zakres.

Wnioski

Bezpieczna konfiguracja dsh-superagent zaczyna się od poznania jego rzeczywistych założeń operacyjnych: statusu projektu badawczego, wykonywania z pełnym dostępem użytkownika hosta oraz trybu obserwacji, który nadal pozwala realizować jawne zadania. Dedykowane tożsamości, zasoby tymczasowe i niezależny przegląd są niezbędne, by poznać zachowanie prototypu.

Ogranicz pierwszy test do wąskiego zakresu, celowo sprawdzaj odrzucanie zadań i zatrzymywanie tak samo dokładnie jak powodzenie oraz zachowuj dowody uzasadniające każdą zaakceptowaną zmianę. Nie przekształcaj użytecznego eksperymentu badawczego we wdrożenie produkcyjne przez stopniowe gromadzenie danych uwierzytelniających i uprawnień bez ponownego przeglądu.