Så konfigurerar du DeepSeek Super Agent på ett säkert sätt: konton, behörigheter och isolering

Påbörja inte ett dsh-superagent-experiment med ditt vanliga konto eller mot ett värdefullt produktionsarkiv. I driftsättningsdokumentationen står det att både router- och arbetarinställningarna körs med danger-full-access som operativsystemsanvändare och kan läsa den användarens hemkatalog. Skapa ett dedikerat konto och ett tillfälligt arkiv innan installation och testning, inte efter den första oväntade åtgärden.

Det offentliga arkivet är en forskningsprototyp, inte en officiell DeepSeek-produkt som är redo för produktion. Den här guiden omvandlar de dokumenterade standardinställningarna till en försiktig installationsplan: separata identiteter, begränsad åtkomst till arkiv, granskade regler för godkännande, kontrollerad körning och en testad stopprocedur. Ange autentiseringsuppgifter endast via en egen godkänd terminal eller ett arbetsflöde för hantering av hemligheter, aldrig i en chattkonversation.

Är dsh-superagent redo för produktion?

README-filen anger uttryckligen att det är forskningskod och att den publicerade implementeringen skiljer sig från det interna systemet och vissa idéer i den tillhörande designartikeln. Den statusen bör vara framträdande när du fattar beslut om driftsättning. Att koden är offentligt tillgänglig ger möjlighet att granska utformningen, men är ingen garanti för att koden är redo för känsliga arbetsuppgifter.

Den här guiden kontrollerades mot revisionen 8c32a9dc5d72c033816c6a8110b37f40cf94fba4 den 5 november 2026. Fäst och dokumentera den revision du faktiskt granskar. Om du senare uppdaterar arbetskopian ska du kontrollera förutsättningar, behörigheter, förinställningar och konfigurationsmigreringar igen innan du kör den.

Installationsdokumentet beskriver ett interaktivt arbetsflöde där du planerar och bekräftar. Granska planen före körning. Tolka inte uppmaningen att låta en kodningsagent hjälpa till med installationen som tillstånd för den att komma åt orelaterade autentiseringsuppgifter eller installera i din vanliga arbetsprofil.

Det första acceptanskriteriet bör vara blygsamt: en ofarlig begäran skapar en begriplig uppgift och ett granskningsbart resultat i ett tillfälligt arkiv. Testa även hur avvisning och avbrytning fungerar. En lyckad demonstration av det vanliga förloppet bevisar inte tillförlitlighet i produktion och motiverar inte att åtkomsten utökas direkt.

Varför använda ett dedikerat operativsystemskonto?

Installationsguiden gör antagandet om värdåtkomst tydligt. Separata sessionskataloger och autentiseringsuppgifter isolerar inte processen. En arbetare kan köra program och komma åt filer som är tillgängliga för kontot den körs under, inklusive kontots hemkatalog.

Skapa ett särskilt konto som bara innehåller de filer och autentiseringsuppgifter som behövs för experimentet. Håll personliga SSH-nycklar, administratörsuppgifter för molntjänster, webbläsarprofiler, produktionskonfiguration och orelaterade arkiv utanför dess åtkomstmiljö. Granska gruppmedlemskap och monterad lagring samt kontots hemkatalog.

För bättre avskiljning kan du överväga en särskild tillfällig virtuell maskin eller en liknande kontrollerad värdmiljö. Utgå inte från att en container räcker enbart för att den har en annan vy av filsystemet; monteringar, privilegier, uttag och nätverk avgör den faktiska gränsen. Beslutet om driftsättning bör återspegla värdet av värden och koden som körs.

Vår arkitekturgenomgång förklarar varför dessa kontroller ligger på olika lager. Genom att hålla lagren åtskilda undviker man att en avgränsad skyddsåtgärd, till exempel en kort lista över begärande användare, misstas för heltäckande isolering.

Omslag: dsh-superagent-prototypens arkiv, GitHub-genererat arkivkort. Arkivmetadata är en daterad illustration, inte ett påstående om användning eller prestanda.

Hur skapar du en GitHub-agentidentitet?

Använd den särskilda GitHub-användarkontometod som krävs av den aktuella prototypen i stället för ditt personliga konto. I driftsättningsguiden står det att den här implementationen läser kontots aviseringar och inte stöder att ersätta agentidentiteten med en GitHub-app. Det är en implementeringsbegränsning, inte en allmän rekommendation mot GitHub-appar i andra system.

Ge bara åtkomst till det tillfälliga testarkivet till en början. Håll agentens inloggningskonfiguration separat från din egen. Använd den dokumenterade wrapper-metoden eller en motsvarande godkänd konfiguration och kontrollera vilket konto CLI använder innan processen får utföra åtgärder. Dra inte slutsatser om identiteten utifrån ett visningsnamn i en chatt.

GitHubs vägledning om token förklarar alternativen för behörigheter och utgångstider. Välj minsta möjliga åtkomst som stöds och som krävs för prototypens dokumenterade åtgärder, granska eventuella kompatibilitetskrav och se till att det går att återkalla åtkomsten. Undvik att ge kontot administratörsbehörighet för organisationen eller möjlighet att distribuera till produktion av bekvämlighetsskäl.

Låt människor sköta sammanslagningen i det första försöket. En agent som kan skicka upp en gren och öppna en pull request behöver inte också ha behörighet att ändra arkivets skydd eller godkänna sitt eget arbete. Identiteten bör tydligt visa vem som har skapat arbetet, samtidigt som beslutet om godkännande förblir oberoende.

Hur fungerar listor över tillåtna användare och policyer för godkännande?

Auktoriseringsdokumentet skiljer mellan uttryckliga förfrågningar, härledda kandidater och indata som inte godtas. Både tillåtna identiteter och inställningar för godkännande inom ett visst omfång spelar roll. En kort lista över tillåtna användare är användbar, men den bör granskas tillsammans med mottagningsomfånget och reglerna i stället för att betraktas som den enda kontrollen.

Börja med en känd beställare och ett arkiv. Om Feishu inte behövs för testet lämnar du det okonfigurerat. Varje ytterligare källa innebär ännu ett ställe där du behöver verifiera identitet, mottagningsomfång, botbeteende och behörighet att initiera arbete. Lägg till källor först när du förstår det första arbetsflödet.

Testa hur policyerna fungerar med ofarliga exempel. Bekräfta vad som händer när en behörig person vänder sig till agenten, när någon skriver ett orelaterat inlägg och när en uppföljning begär arbete utanför den befintliga uppgiften. Granska beslutsloggen i stället för att anta att inget har hänt bara för att inget synligt svar har kommit.

Innehåll i arkiv och citerade meddelanden bör förbli underlag, inte uppdateringar av policyer. En instruktion som bäddats in i ett ärende eller dokument får inte i tysthet ge åtkomst eller ändra vem som får begära arbete. Vår jämförelse av proactive-agent förklarar varför arbetsflöden kopplade till händelser gör den skillnaden viktigare än i en enda övervakad chattsession.

Varför börja i observe-läget?

I det dokumenterade standardläget observe bedömer systemet härledda kandidater och registrerar vilka som skulle godkännas utan att godkänna dem automatiskt. Det är användbart för att lära sig hur konfigurerade regler fungerar. Det hindrar inte att uttryckliga, behöriga förfrågningar utförs, så det är inte ett globalt skrivskyddat läge eller ett läge där inga åtgärder vidtas.

Håll experimentets tekniska behörigheter begränsade även medan du observerar. Om målet är att granska dirigeringen utan att tillåta värdefulla ändringar bör du använda resurser som kan kasseras och upprätthålla den gränsen genom värdens och repots konfiguration. Förlita dig inte på en lägesetikett för att skydda tillgångar som processen redan kan komma åt.

Granska både positiva och negativa beslut. En regel som godkänner för mycket kan skapa oönskat arbete, medan en regel som godkänner för lite i tysthet kan missa förväntade uppgifter. Dokumentera varför det förväntade resultatet skiljer sig från det observerade innan du ändrar policyn. Att upprepade gånger bredda reglerna tills en demonstration fungerar är ett dåligt sätt att fastställa en säker standardinställning.

Byt inte till auto som ett rutinmässigt installationssteg. Det läget ökar systemets förmåga att starta härlett arbete när regler matchar. All senare utökning bör ha en uttryckligt ansvarig ägare, en granskad regeluppsättning, en kontrollerad utvärderingslogg och ett testat sätt att stoppa eller återkalla åtkomsten.

Hur skyddas token, hemligheter och lokala filer?

Håll inloggningsuppgifter utanför promptar, repofiler, skärmbilder och vanliga loggar. Använd godkänd CLI-inloggning eller hemlighetslagring i den dedikerade miljön. OWASP:s vägledning för hantering av hemligheter ger bakgrund om åtkomstkontroll och livscykel, men det omedelbara kravet är enkelt: agentmiljön ska inte innehålla några inloggningsuppgifter som inte behövs för dess uppgift.

Granska även sökvägen till modellprovidern, inte bara GitHub-identiteten. Kod och promptar kan behandlas av den konfigurerade providern, och verktyg kan introducera ytterligare destinationer. En lokal checkout innebär inte lokal inferens eller att hanteringen sker enbart lokalt. Kontrollera att den valda providern och loggningskonfigurationen är godkända för testmaterialet.

Undvik att kopiera en personlig hemkatalog eller skalkonfiguration till det dedikerade kontot för att förenkla installationen. Den kan innehålla hjälpprogram för inloggningsuppgifter, miljövariabler, molnkonfiguration och privat historik. Återskapa minimikraven medvetet och för en inventering utan hemligheter över det som lagts till.

Vår checklista för åtkomst för personliga agenter ger ett relaterat förberedelsesteg. Innan den körs för första gången bör du kontrollera från agentens faktiska miljö vilka kataloger, inloggningsuppgifter, tjänster och nätverksdestinationer som är åtkomliga. Om åtkomsten är mer omfattande än testet kräver bör du åtgärda gränsdragningen innan du går vidare.

Hur isolerar du repot och granskar ändringar?

Använd ett tillfälligt kodförråd med syntetiska exempel och utan produktionshemligheter. Konfigurationsdokumentationen anger förutsättningar, däribland en kompatibel Node.js-version, pnpm, Git, tmux, Python, GitHub CLI och DeepSeek Harness. Kontrollera den aktuella package.json och konfigurationsguiden för exakta kompatibilitetskrav i stället för att installera godtyckliga versioner från en gammal kommandolista.

Följ denna förberedelsesekvens innan du kör installationsplanen:

1. Tillhandahåll det dedikerade kontot eller den tillfälliga värden och bekräfta dess åtkomstgränser.
2. Skapa den dedikerade GitHub-identiteten och testkodförrådet med lämpliga begränsade behörigheter.
3. Hämta prototypen, dokumentera dess revision och granska dess dokumentation för konfiguration och driftsättning.
4. Granska den föreslagna installationsplanen, modellleverantören, profilen, lagringsplatsen för tillstånd och mekanismen för inloggningsuppgifter.
5. Konfigurera så att endast uppgifter från GitHub tas emot, begränsa listan över beställare, välj observe och stäng av automatisk sammanfogning under den första testperioden.
6. Starta den granskade konfigurationen och kontrollera hälsa och konfigurationskrav.
7. Skicka in en harmlös, auktoriserad uppgift och granska det resulterande tillståndet och den föreslagna ändringen.
8. Testa irrelevant indata, en utökning av omfattningen och en avstängningsprocedur innan du överväger bredare åtkomst.

Det dokumenterade statuskommandot är användbart efter konfigurationen:

scripts/dsh-superagent status

Kör det från den granskade arbetskopian i den dedikerade miljön. Tolka utdata med hjälp av den aktuella distributionsguiden; en process som körs innebär inte att källkoden och policyn är korrekta och hälsosamma.

Upprätthåll kraven för skyddade grenar och mänsklig granskning. Kontrollera diffen, start- och slutrevisionerna, testerna och olösta antaganden. Använd oberoende kopior av värdefulla data; vår guide för återställningsbara filer förklarar varför återställning måste planeras innan skrivåtkomst beviljas.

Hur stoppar du agenten och återkallar åtkomst?

Dokumentera avstängningsproceduren innan den första uppgiften. Den aktuella distributionsguiden innehåller ett kommando för ordnad avstängning:

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

En ordnad avstängning kan vänta tills körningen har avslutats; det bevisar inte att alla externa effekter har återställts. Kontrollera pågående arbete och relevant aktivitet i kodförrådet. Ersätt inte förståelsen av vad processen gör med att tvångsavsluta orelaterade sessioner.

Vid en åtkomstincident eller ett övergivet experiment ska du återkalla de särskilda inloggningsuppgifterna och åtkomsten till kodförrådet via lämpliga kontroller hos leverantören. Stoppa inkommande uppgifter och kontrollera kvarvarande bakgrundsprocesser eller tjänster. Spara en icke-hemlig dokumentation av den berörda uppgiften, revisionen och relevanta aktiviteter så att teamet kan rekonstruera händelsen.

Rensning och återställning är två olika uppgifter. Att ta bort en lokal katalog återkallar inte en token, stänger inte en fjärrbaserad pull request och ångrar inte en pushad ändring. Bestäm separat vad som ska hända med varje artefakt och spara nödvändiga underlag innan du tar bort något. Utöka experimentet först när det är lika tydligt hur man stoppar, återkallar åtkomst och återställer som hur man startar det.

För själva resultatet, använd granskningsförfarande för agentic-autofix. En process som fungerar och en accepterad uppgift är operativa signaler; de visar inte att den föreslagna korrigeringen bör slås samman.

Vanliga frågor

Kan jag köra prototypen från mitt vanliga utvecklarkonto?

Det ger processen åtkomst till kontots tillgängliga filer och autentiseringsuppgifter. Använd en dedikerad, begränsad miljö för det första experimentet, särskilt med tanke på de dokumenterade förinställningarna med full åtkomst.

Gör observationsläget prototypen skrivskyddad?

Nej. Det begränsar godkännandet av slutsatsdragna kandidater, medan uttryckligen auktoriserade förfrågningar fortfarande kan köras. Upprätthåll en gräns som förbjuder skrivningar med hjälp av behörigheter om det är testets syfte.

Kan jag använda en GitHub-app i stället för ett dedikerat användarkonto?

Den granskade prototypens driftsättningsguide kräver ett användarkonto på grund av dess aviseringsflöde. Kontrollera senare versioner innan du antar att den kompatibilitetsbegränsningen är oförändrad.

Ska jag klistra in konfigurationstoken i assistentagentens chatt?

Nej. Använd godkänd CLI-autentisering eller hemlighetslagring i din egen kontrollerade miljö. Konfigurationen kräver inte att du avslöjar hemliga värden i en konversation.

Vad visar att den inledande testperioden är säker att utöka?

Inget enskilt test bevisar generell säkerhet. Granska beslut om inkommande förfrågningar, behörighetsgränser, föreslagna ändringar, stoppbeteende och underlag för återställning, och godkänn sedan endast en specifik utökning av omfattningen.

Slutsats

Att konfigurera dsh-superagent på ett säkert sätt börjar med dess faktiska driftförutsättningar: forskningsstatus, körning med full åtkomst under värdanvändaren och ett observationsläge som fortfarande tillåter uttryckligt arbete. Dedikerade identiteter, resurser som kan kastas bort och oberoende granskning är förutsättningar för att lära sig hur prototypen beter sig.

Håll den första uppgiften avgränsad, testa avvisning och stopp lika medvetet som framgång, och bevara underlaget för varje godkänd ändring. Förvandla inte ett användbart forskningsexperiment till en produktionsdriftsättning genom att gradvis samla på er behörighetsuppgifter och befogenheter utan en ny granskning.