Begin geen experiment met dsh-superagent onder je dagelijkse account of met een waardevolle productierepository. De implementatiedocumentatie vermeldt dat zowel de router- als de worker-preset met danger-full-access draait als de gebruiker van het besturingssysteem en mogelijk de thuismap van die gebruiker kan lezen. Stel een afzonderlijk account en een wegwerprepository in vóór de installatie en het testen, niet pas na de eerste onverwachte actie.
De openbare repository is een onderzoeksprototype, geen officieel DeepSeek-product dat klaar is voor productie. Deze handleiding vertaalt de gedocumenteerde standaardinstellingen naar een voorzichtig installatieplan: afzonderlijke identiteiten, beperkte toegang tot repositories, gecontroleerde toelatingsregels, beheerste uitvoering en een geteste stopprocedure. Voer inloggegevens alleen in via je eigen goedgekeurde terminal- of geheimenbeheerprocedure, nooit in een chatgesprek.
Is dsh-superagent klaar voor productie?
De README vermeldt expliciet dat dit onderzoekscode is en dat de gepubliceerde implementatie verschilt van het interne systeem en van sommige ideeën in het bijbehorende ontwerpartikel. Die status moet zwaar meewegen bij de beslissing om het systeem te implementeren. De openbare beschikbaarheid biedt de mogelijkheid om het ontwerp te bekijken, maar garandeert niet dat de code klaar is voor gevoelige werkzaamheden.
Deze handleiding is gecontroleerd aan de hand van revisie 8c32a9dc5d72c033816c6a8110b37f40cf94fba4 van 5 november 2026. Leg de revisie die je daadwerkelijk controleert vast en pin die. Werk je de checkout later bij, controleer dan de vereisten, machtigingen, presets en configuratiemigraties opnieuw voordat je het systeem weer uitvoert.
Het installatiedocument beschrijft een interactieve workflow waarin eerst een plan wordt opgesteld en bevestigd. Controleer het plan voordat je het uitvoert. Beschouw de instructie om een codeeragent te laten helpen bij de installatie niet als toestemming om toegang te krijgen tot niet-gerelateerde inloggegevens of om iets te installeren in je gewone werkomgeving.
De eerste acceptatiedoelstelling moet bescheiden zijn: één onschadelijk verzoek levert een begrijpelijke taak en een controleerbaar resultaat op in een wegwerprepository. Test ook het afwijzen en stoppen. Een geslaagde demonstratie van het ideale scenario bewijst niet dat het systeem betrouwbaar genoeg is voor productie en rechtvaardigt niet dat de toegang meteen wordt uitgebreid.
Waarom een afzonderlijk besturingssysteemaccount gebruiken?
De implementatiehandleiding maakt de aanname over toegang tot de host expliciet. Afzonderlijke sessiemappen en wrappers voor inloggegevens isoleren het proces niet. Een worker kan programma's uitvoeren en bestanden openen waartoe het account waaronder hij draait toegang heeft, waaronder de thuismap van dat account.
Maak een speciaal account aan met alleen de bestanden en inloggegevens die nodig zijn voor het experiment. Houd persoonlijke SSH-sleutels, beheerdersgegevens voor de cloud, browserprofielen, productieconfiguratie en niet-gerelateerde repositories buiten de toegankelijke omgeving. Controleer ook het groepslidmaatschap en gekoppelde opslag, niet alleen de thuismap van het account.
Overweeg voor een betere scheiding een speciale, wegwerpbare virtuele machine of een vergelijkbare gecontroleerde hostomgeving. Ga er niet van uit dat een container volstaat alleen omdat deze een andere weergave van het bestandssysteem heeft; koppelingen, bevoegdheden, sockets en netwerkverbindingen bepalen de daadwerkelijke grens. De keuze voor de implementatie moet rekening houden met de waarde van de host en de code die wordt uitgevoerd.
| Maatregel | Wat dit regelt | Wat dit niet vervangt |
|---|---|---|
| Speciale OS-identiteit | Bestands- en procesmachtigingen op de host | Controle aan de repositoryzijde en API-machtigingen |
| Speciale GitHub-identiteit | Toeschrijving en repositorytoegang | Hostisolatie of taaktoelatingsbeleid |
| Beleid voor toegestane gebruikers en toelating | Wie en wat werk kunnen starten | Handhaving van bestandssysteem- of netwerktoegang |
| Taakomvang en controlepoort | Welk resultaat mag worden geaccepteerd | Een veilige runtime of veilige opslag van inloggegevens |
| Procedure voor stoppen en intrekken | Uitvoering beëindigen en toegang intrekken | Herstel van wijzigingen die al zijn aangebracht |
In ons architectuuroverzicht wordt uitgelegd waarom deze maatregelen op verschillende lagen zitten. Door de lagen gescheiden te houden, voorkom je dat een beperkte beveiligingsmaatregel, zoals een korte lijst met aanvragers, wordt aangezien voor volledige isolatie.

Omslag: dsh-superagent-prototyperepository, door GitHub gegenereerde repositorykaart. De metadata van de repository is een gedateerde illustratie en geen claim over gebruik of prestaties.
Hoe maak je een GitHub-agentidentiteit aan?
Gebruik de speciale GitHub-gebruikersaccountmethode die het huidige prototype vereist, in plaats van je persoonlijke account. In de implementatie worden volgens de implementatiehandleiding de meldingen van het account gelezen en is het niet mogelijk om een GitHub App te gebruiken als agentidentiteit. Dit is een beperking van de implementatie, geen algemeen advies tegen GitHub Apps in andere systemen.
Verleen in eerste instantie alleen toegang tot de tijdelijke testrepository. Houd de inlogconfiguratie van de agent gescheiden van die van jezelf. Gebruik de gedocumenteerde wrappermethode of een gelijkwaardige goedgekeurde configuratie en controleer welk account de CLI gebruikt voordat je het proces toestemming geeft om acties uit te voeren. Leid de identiteit niet af uit een weergavenaam in een chat.
De richtlijnen voor GitHub-tokens van GitHub leggen de opties voor machtigingen en vervaldatums uit. Kies de minimale ondersteunde toegang die nodig is voor de gedocumenteerde bewerkingen van het prototype, controleer eventuele compatibiliteitsvereisten en zorg dat intrekking mogelijk blijft. Geef het account niet voor het gemak beheerdersrechten voor de organisatie of mogelijkheden om naar productie uit te rollen.
Laat mensen tijdens een eerste experiment zelf samenvoegen. Een agent die een branch kan pushen en een pull request kan openen, hoeft niet ook bevoegd te zijn om repositorybeveiligingen te wijzigen of eigen werk te accepteren. De identiteit moet duidelijk maken wie het werk heeft gemaakt, terwijl de acceptatiebeslissing onafhankelijk blijft.
Hoe werken lijsten met toegestane gebruikers en toelatingsbeleidsregels?
Het autorisatiedocument maakt onderscheid tussen expliciete verzoeken, afgeleide kandidaten en niet-toegelaten invoer. Zowel toegestane identiteiten als toelatingsinstellingen per scope zijn van belang. Een korte lijst met toegestane gebruikers is nuttig, maar moet samen met de ontvangende scope en regels worden gecontroleerd en niet als enige beveiligingsmaatregel worden beschouwd.
Begin met één bekende aanvrager en één repository. Als Feishu niet nodig is voor de test, configureer het dan niet. Elke extra bron creëert een nieuwe plek waar je identiteit, ontvangende scope, botgedrag en toestemming om werk te starten moet controleren. Voeg pas bronnen toe wanneer de eerste workflow duidelijk is.
Test het beleid met onschuldige voorbeelden. Controleer wat er gebeurt wanneer een toegestane persoon de agent aanspreekt, wanneer iemand een niet-gerelateerd gesprek voert en wanneer een vervolgverzoek om werk buiten de bestaande taak vraagt. Bekijk de beslisregistratie in plaats van aan te nemen dat er niets is gebeurd omdat er geen zichtbaar antwoord is.
Inhoud van repositories en geciteerde berichten moeten bewijsmateriaal blijven, geen beleidsupdates. Een instructie in een issue of document mag niet stilzwijgend toegang verlenen of veranderen wie werk kan aanvragen. Onze vergelijking van proactive-agent legt uit waarom workflows die aan gebeurtenissen zijn gekoppeld dat onderscheid belangrijker maken dan in één begeleide chatsessie.
Waarom beginnen met de observatiemodus?
In de gedocumenteerde standaardmodus observe beoordeelt het systeem afgeleide kandidaten en legt het vast welke zouden worden geaccepteerd, zonder ze automatisch te accepteren. Dit is nuttig om te leren hoe geconfigureerde regels werken. Het voorkomt niet dat geautoriseerde expliciete verzoeken worden uitgevoerd, dus het is geen algemene alleen-lezenmodus of modus waarin niets wordt gedaan.
Houd de technische machtigingen van het experiment beperkt, ook tijdens observatie. Als het doel is de routering te inspecteren zonder waardevolle wijzigingen toe te staan, gebruik dan wegwerpbare resources en handhaaf die grens via de host- en repositoryconfiguratie. Vertrouw niet op een moduslabel om assets te beschermen waartoe het proces al toegang heeft.
Beoordeel zowel positieve als negatieve beslissingen. Een regel die te veel accepteert, kan ongewenst werk veroorzaken, terwijl een regel die te weinig accepteert verwachte taken ongemerkt kan missen. Leg vast waarom de verwachte uitkomst afwijkt van de waargenomen uitkomst voordat je het beleid aanpast. De regels herhaaldelijk verruimen totdat een demonstratie werkt, is geen goede manier om een veilige standaard in te stellen.
Schakel auto niet in als standaardstap bij de installatie. Die modus vergroot de mogelijkheid van het systeem om op basis van overeenkomende regels afgeleid werk te starten. Elke latere uitbreiding moet een expliciete eigenaar, een beoordeelde set regels, een gecontroleerd evaluatierapport en een geteste manier om toegang te stoppen of in te trekken hebben.
Hoe bescherm je tokens, geheimen en lokale bestanden?
Houd inloggegevens buiten prompts, repositorybestanden, schermafbeeldingen en gewone logboeken. Gebruik goedgekeurde CLI-aanmelding of geheimenopslag in de aparte omgeving. De OWASP-richtlijnen voor geheimenbeheer bieden achtergrondinformatie over toegangsbeheer en de levenscyclus, maar de directe vereiste is eenvoudig: de omgeving van de agent mag geen inloggegevens bevatten die niets met de taak te maken hebben.
Beoordeel ook het pad naar de modelprovider, niet alleen de GitHub-identiteit. Code en prompts kunnen door de geconfigureerde provider worden verwerkt, en tools kunnen extra bestemmingen toevoegen. Een lokale checkout betekent niet dat inferentie lokaal plaatsvindt of dat alles uitsluitend lokaal wordt verwerkt. Bevestig dat de geselecteerde provider en de logboekconfiguratie zijn goedgekeurd voor het testmateriaal.
Kopieer niet voor het gemak een persoonlijke thuismap of shellconfiguratie naar het aparte account. Zo kunnen er hulpprogramma's voor inloggegevens, omgevingsvariabelen, cloudconfiguratie en privégeschiedenis meekomen. Maak de minimale afhankelijkheden bewust opnieuw aan en houd een inventaris bij van wat is toegevoegd, zonder geheimen.
Onze toegangschecklist voor persoonlijke agents biedt een verwante voorbereidingsstap. Controleer vóór de eerste uitvoering vanuit de daadwerkelijke omgeving van de agent welke mappen, inloggegevens, services en netwerkbestemmingen bereikbaar zijn. Is het antwoord ruimer dan voor de test nodig is, stel dan eerst de grenzen bij.
Hoe isoleer je de repository en beoordeel je wijzigingen?
Gebruik een tijdelijke repository met synthetische voorbeelden en zonder productiegeheimen. In de installatiedocumentatie staan vereisten zoals een compatibele Node.js-versie, pnpm, Git, tmux, Python, GitHub CLI en DeepSeek Harness. Controleer de huidige package.json en installatiehandleiding voor de exacte compatibiliteit, in plaats van willekeurige versies uit een oude lijst met opdrachten te installeren.
Volg deze voorbereidingsstappen voordat je het installatieplan uitvoert:
- Voorzie het speciale account of de tijdelijke host en bevestig de grenzen van de toegang.
- Maak de speciale GitHub-identiteit en testrepository aan met passende, beperkte rechten.
- Haal het prototype op, noteer de revisie en controleer de installatie- en implementatiedocumentatie.
- Controleer het voorgestelde installatieplan, de modelprovider, het profiel, de locatie van de statusgegevens en de methode voor inloggegevensbeheer.
- Stel in voor de eerste test: alleen intake via GitHub, een korte lijst met aanvragers,
observeen geen automatische samenvoeging. - Start de gecontroleerde configuratie en controleer de status en installatievereisten.
- Dien één onschadelijke, geautoriseerde taak in en controleer de resulterende status en voorgestelde wijziging.
- Test irrelevante invoer, een uitbreiding van de scope en een stopprocedure voordat je ruimere toegang overweegt.
De gedocumenteerde statusopdracht is handig na het instellen:
scripts/dsh-superagent status
Voer dit uit vanuit de gecontroleerde checkout in de daarvoor bestemde omgeving. Interpreteer de uitvoer aan de hand van de huidige implementatiehandleiding; een actief proces is niet hetzelfde als een gezonde, correct geconfigureerde bron en beleidsconfiguratie.
Houd de vereisten voor beschermde branches en menselijke controle in stand. Controleer de diff, de begin- en eindrevisies, tests en onopgeloste aannames. Gebruik onafhankelijke kopieën voor waardevolle gegevens; in onze handleiding voor herstelbare bestanden staat waarom je herstel moet plannen voordat je schrijfrechten verleent.
Hoe stop je de agent en trek je de toegang in?
Leg de stopprocedure vast voordat de eerste taak wordt uitgevoerd. De huidige implementatiehandleiding bevat een opdracht voor een normale stop:
scripts/dsh-superagent stop
scripts/dsh-superagent status
Een normale stop kan wachten tot de uitvoering is afgerond; dat bewijst niet dat alle externe effecten ongedaan zijn gemaakt. Controleer openstaand werk en relevante repository-activiteit. Vervang inzicht in wat het proces doet niet door het geforceerd beëindigen van niet-gerelateerde sessies.
Trek bij een toegangsincident of een verlaten experiment de specifieke inloggegevens en toegang tot de repository in via de daarvoor bestemde instellingen van de provider. Stop met het aannemen van taken en controleer de resterende achtergrondprocessen of services. Leg de getroffen taak, revisie en relevante activiteit vast zonder geheimen te vermelden, zodat het team de gebeurtenis kan reconstrueren.
Opruimen en herstellen zijn verschillende taken. Een lokale map verwijderen trekt een token niet in, sluit geen externe pull-aanvraag en maakt een gepushte wijziging niet ongedaan. Bepaal afzonderlijk wat er met elk artefact moet gebeuren en bewaar het benodigde bewijs voordat je iets verwijdert. Breid het experiment pas uit als stoppen, intrekken en herstellen net zo begrijpelijk zijn als starten.
Gebruik voor het resultaat zelf de beoordelingsprocedure voor agentic-autofix. Een goed werkend proces en een geaccepteerde taak zijn operationele signalen; ze bewijzen niet dat de voorgestelde patch moet worden samengevoegd.
Veelgestelde vragen
Kan ik het prototype vanuit mijn normale ontwikkelaarsaccount uitvoeren?
Daardoor krijgt het proces toegang tot de bestanden en inloggegevens die voor dat account toegankelijk zijn. Gebruik voor het eerste experiment een aparte omgeving met beperkte toegang, zeker gezien de gedocumenteerde voorinstellingen met volledige toegang.
Maakt de observatiemodus het prototype alleen-lezen?
Nee. Dit beperkt de acceptatie van afgeleide kandidaten, terwijl expliciet geautoriseerde verzoeken nog steeds kunnen worden uitgevoerd. Dwing een grens zonder schrijfrechten af via machtigingen als dat het doel van de test is.
Kan ik een GitHub App gebruiken in plaats van een apart gebruikersaccount?
De geïnspecteerde implementatiehandleiding van het prototype vereist een gebruikersaccount vanwege de meldingsworkflow. Controleer latere versies voordat je ervan uitgaat dat die compatibiliteitsbeperking ongewijzigd is.
Moet ik insteltokens in de chat van de assistent plakken?
Nee. Gebruik goedgekeurde CLI-authenticatie of veilige opslag van geheimen in je eigen gecontroleerde omgeving. Voor het instellen hoef je geen geheime waarden in een gesprek bloot te leggen.
Wat bewijst dat de eerste proef veilig kan worden uitgebreid?
Geen enkele test bewijst de algemene veiligheid. Beoordeel intakebeslissingen, bevoegdheidsgrenzen, voorgestelde wijzigingen, stopgedrag en herstelbewijs, en geef vervolgens alleen toestemming voor een specifieke uitbreiding van de scope.
Conclusie
dsh-superagent veilig instellen begint met inzicht in de werkelijke aannames: onderzoeksstatus, uitvoering met volledige toegang onder de hostgebruiker en een observatiemodus waarin expliciete taken nog steeds mogen worden uitgevoerd. Aparte identiteiten, wegwerpmiddelen en onafhankelijke beoordeling zijn voorwaarden om te leren hoe het prototype zich gedraagt.
Beperk de eerste taak, test afwijzing en stoppen even bewust als succes, en bewaar het bewijs achter elke geaccepteerde wijziging. Verander een nuttig onderzoeksexperiment niet in een productie-implementatie door geleidelijk inloggegevens en bevoegdheden toe te voegen zonder een nieuwe beoordeling.
Ondersteuning en tips
Meer om te lezen

Wat je moet controleren voordat je een communitymodel in Transformers laadt
Gebruik de Transformers Jinja-sandboxupdate om de herkomst van modellen, chatsjablonen, externe code, geserialiseerde gewichten en geïsoleerde eerste uitvoeringen te controleren.

Voer Mirage lokaal uit: OCR en objectdetectie vanuit één afbeelding
Probeer het kleine lokale visiemodel van Cactus Compute, test OCR en objectextractie met echte invoer en krijg inzicht in de beperkingen op het gebied...

Een codeeragent plannen in Open WebUI op een homeserver
Stel een rapportage-only automatisering van een codeeragent in Open WebUI in, selecteer de terminal en werkruimte en controleer de machtigingen, logboeken en herstel na...



