Come configurare DeepSeek Super Agent in sicurezza: account, autorizzazioni e isolamento

Non avviare un esperimento con dsh-superagent usando il tuo account abituale o un repository di produzione di valore. La documentazione di distribuzione afferma che le configurazioni predefinite di router e worker vengono eseguite con danger-full-access come utente del sistema operativo e possono leggere la directory home di quell'utente. Un account dedicato e un repository usa e getta dovrebbero precedere l'installazione e i test, non arrivare dopo la prima azione inaspettata.

Il repository pubblico è un prototipo di ricerca, non un prodotto DeepSeek ufficiale e pronto per la produzione. Questa guida traduce le impostazioni predefinite documentate in un piano di configurazione prudente: identità separate, accesso limitato al repository, regole di ammissione verificate, esecuzione controllata e una procedura di arresto collaudata. Inserisci le credenziali solo tramite il tuo terminale approvato o il flusso di gestione dei segreti, mai in una conversazione in chat.

dsh-superagent è pronto per la produzione?

Il README afferma esplicitamente che si tratta di codice di ricerca e che l'implementazione pubblicata differisce dal sistema interno e da alcune idee presentate nell'articolo di progettazione associato. Questo aspetto dovrebbe essere messo in evidenza quando si decide se distribuirlo. La disponibilità pubblica offre l'opportunità di esaminare il progetto, ma non garantisce che il codice sia pronto per operazioni sensibili.

Questa guida è stata verificata rispetto alla revisione 8c32a9dc5d72c033816c6a8110b37f40cf94fba4 del 5 novembre 2026. Fissa e annota la revisione che esamini effettivamente. Se in seguito aggiorni il checkout, ricontrolla i prerequisiti, le autorizzazioni, le configurazioni predefinite e le migrazioni della configurazione prima di eseguirlo di nuovo.

Il documento di configurazione descrive un flusso interattivo di pianificazione e conferma. Esamina il piano prima dell'esecuzione. Non considerare l'istruzione di farti aiutare nella configurazione da un agente di programmazione come un'autorizzazione ad accedere a credenziali non pertinenti o a installarlo nel tuo normale profilo di lavoro.

Il primo obiettivo di accettazione dovrebbe essere modesto: una richiesta innocua produce un'attività comprensibile e un risultato verificabile in un repository usa e getta. Verifica anche il rifiuto delle richieste e il comportamento di arresto. Una dimostrazione riuscita del solo percorso ideale non prova l'affidabilità in produzione né giustifica un ampliamento immediato degli accessi.

Perché usare un account dedicato del sistema operativo?

La guida alla distribuzione esplicita l'assunzione relativa all'accesso dell'host. Directory di sessione separate e wrapper per le credenziali non isolano il processo. Un worker può eseguire programmi e accedere ai file consentiti all'account che lo esegue, inclusa la directory home di quell'account.

Crea un account dedicato che contenga solo i file e le credenziali necessari per l'esperimento. Tieni fuori dal suo ambiente accessibile le chiavi SSH personali, le credenziali di amministratore cloud, i profili del browser, le configurazioni di produzione e i repository non pertinenti. Esamina anche l'appartenenza ai gruppi e le unità di archiviazione montate, oltre alla directory home dell'account.

Per una separazione più rigorosa, valuta l'uso di una macchina virtuale dedicata e usa e getta o di un ambiente host controllato in modo analogo. Non dare per scontato che un container sia sufficiente solo perché presenta una visualizzazione diversa del filesystem: i mount, i privilegi, i socket e la rete determinano i confini effettivi. La decisione di distribuzione dovrebbe tenere conto del valore dell'host e del codice eseguito.

La nostra panoramica dell'architettura spiega perché questi controlli si trovano su livelli diversi. Mantenere separati i livelli evita di scambiare una protezione limitata, come un breve elenco di utenti che possono inviare richieste, per un isolamento completo.

Copertina: repository del prototipo dsh-superagent, scheda del repository generata da GitHub. I metadati del repository sono un'illustrazione datata, non un'affermazione di adozione o di prestazioni.

Come creare un'identità GitHub per un agente?

Usa l'approccio con un account utente GitHub dedicato, richiesto dal prototipo attuale, invece del tuo account personale. La guida alla distribuzione specifica che questa implementazione legge le notifiche dell'account e non supporta la sostituzione dell'identità dell'agente con una GitHub App. Si tratta di un vincolo di implementazione, non di una raccomandazione generale contro le GitHub App in altri sistemi.

Concedi inizialmente l'accesso solo al repository di test usa e getta. Mantieni la configurazione di accesso dell'agente separata dalla tua. Usa l'approccio documentato con wrapper o una configurazione equivalente approvata e verifica quale account sta usando la CLI prima di autorizzare l'agente a operare. Non dedurre l'identità dal nome visualizzato in una chat.

Le indicazioni di GitHub sui token spiegano le opzioni relative alle autorizzazioni e alla scadenza. Seleziona il livello minimo di accesso supportato necessario per le operazioni documentate del prototipo, verifica eventuali requisiti di compatibilità e mantieni una procedura per revocare l'accesso. Evita di concedere all'account privilegi di amministrazione dell'organizzazione o capacità di distribuzione in produzione solo per comodità.

Per un esperimento iniziale, lascia che siano le persone a occuparsi dell'integrazione delle modifiche. Un agente in grado di eseguire il push di un branch e aprire una pull request non ha anche bisogno dell'autorità per modificare le protezioni del repository o accettare il proprio lavoro. L'identità dovrebbe rendere chiara la paternità del lavoro, mantenendo al contempo indipendente la decisione di accettarlo.

Come funzionano le liste di utenti autorizzati e le policy di ammissione?

Il documento di autorizzazione distingue tra richieste esplicite, candidati dedotti e input non ammessi. Sono importanti sia le identità autorizzate sia le impostazioni di ammissione specifiche per ambito. Una breve lista di autorizzazione è utile, ma va esaminata insieme all'ambito di ricezione e alle regole, anziché essere considerata l'unico controllo.

Inizia con un richiedente noto e un repository. Se Feishu non è necessario per il test, non configurarlo. Ogni fonte aggiuntiva crea un altro punto in cui verificare l'identità, l'ambito di ricezione, il comportamento del bot e l'autorizzazione ad avviare attività. Aggiungi altre fonti solo dopo aver compreso il primo flusso di lavoro.

Verifica il comportamento delle policy con esempi innocui. Controlla cosa succede quando una persona autorizzata si rivolge all'agente, quando qualcuno pubblica una discussione non pertinente e quando una richiesta successiva chiede un'attività che esula da quella già in corso. Esamina il registro delle decisioni invece di presumere che l'assenza di una risposta visibile significhi che non è stata eseguita alcuna azione.

I contenuti dei repository e i messaggi citati dovrebbero restare elementi di prova, non aggiornamenti delle policy. Un'istruzione incorporata in una segnalazione o in un documento non deve concedere silenziosamente l'accesso né modificare chi può richiedere un'attività. Il nostro confronto tra agenti proattivi spiega perché i flussi di lavoro collegati agli eventi rendono questa distinzione più importante rispetto a una singola sessione di chat supervisionata.

Perché iniziare con la modalità Observe?

Nella modalità predefinita documentata observe, il sistema valuta i candidati dedotti e registra quali verrebbero accettati senza accettarli automaticamente. È utile per capire come funzionano le regole configurate. Non impedisce l'esecuzione di richieste esplicite autorizzate, quindi non è una modalità globale di sola lettura o di nessuna azione.

Mantieni ristrette le autorizzazioni tecniche dell'esperimento anche durante l'osservazione. Se l'obiettivo è esaminare l'instradamento senza consentire modifiche importanti, usa risorse sacrificabili e imponi questo limite tramite la configurazione dell'host e del repository. Non affidarti all'etichetta di una modalità per proteggere risorse a cui il processo può già accedere.

Esamina sia le decisioni positive sia quelle negative. Una regola troppo permissiva può avviare attività indesiderate, mentre una troppo restrittiva può far perdere silenziosamente quelle previste. Registra le ragioni per cui il risultato atteso differisce da quello osservato prima di modificare i criteri. Ampliare ripetutamente le regole finché una dimostrazione non funziona è un modo inadeguato per definire un'impostazione predefinita sicura.

Non passare ad auto come normale passaggio d'installazione. Questa modalità aumenta la capacità del sistema di avviare attività dedotte in base a regole corrispondenti. Ogni espansione successiva dovrebbe avere un responsabile esplicito, un insieme di regole verificato, una registrazione di valutazione controllata e una modalità collaudata per interrompere o revocare l'accesso.

Come proteggere token, segreti e file locali?

Tieni le credenziali fuori dai prompt, dai file del repository, dagli screenshot e dai log ordinari. Usa l'accesso tramite CLI approvato o l'archiviazione dei segreti nell'ambiente dedicato. Le indicazioni OWASP sulla gestione dei segreti forniscono informazioni di base sul controllo degli accessi e sul ciclo di vita, ma il requisito immediato è semplice: l'ambiente dell'agente non deve contenere credenziali non pertinenti alla sua attività.

Esamina il percorso verso il provider del modello, oltre all'identità GitHub. Il codice e i prompt potrebbero essere elaborati dal provider configurato e gli strumenti potrebbero introdurre ulteriori destinazioni. Un checkout locale non implica un'inferenza locale né una gestione esclusivamente locale. Verifica che il provider selezionato e la configurazione dei log siano approvati per i materiali del test.

Evita di copiare una directory home personale o la configurazione della shell nell'account dedicato per semplificare la configurazione. Potrebbe contenere gestori di credenziali, variabili d'ambiente, configurazioni cloud e cronologia privata. Ricrea deliberatamente le dipendenze minime e tieni un inventario non riservato di ciò che hai aggiunto.

La nostra lista di controllo degli accessi dell'agente personale offre una fase di preparazione correlata. Prima della prima esecuzione, verifica dall'ambiente effettivo dell'agente quali directory, credenziali, servizi e destinazioni di rete sono raggiungibili. Se l'accesso è più ampio di quanto richieda il test, correggi i limiti prima di procedere.

Come isolare il repository e rivedere le modifiche?

Usa un repository temporaneo contenente esempi sintetici e privo di segreti di produzione. La documentazione di configurazione indica tra i prerequisiti una versione compatibile di Node.js, pnpm, Git, tmux, Python, GitHub CLI e DeepSeek Harness. Verifica le versioni esatte compatibili nel package.json attuale e nella guida di configurazione, invece di installare versioni a caso da un vecchio elenco di comandi.

Segui questa sequenza di preparazione prima di eseguire il piano di installazione:

1. Predisponi l'account dedicato o l'host temporaneo e verifica i limiti del suo accesso.
2. Crea l'identità GitHub dedicata e il repository di prova con autorizzazioni limitate adeguate.
3. Scarica il prototipo, annotane la revisione ed esamina i documenti di configurazione e distribuzione.
4. Esamina il piano di installazione proposto, il provider del modello, il profilo, la posizione dello stato e il meccanismo delle credenziali.
5. Per la prima prova, configura l'acquisizione esclusivamente da GitHub, un breve elenco di richiedenti, observe e nessuna unione automatica.
6. Avvia la configurazione revisionata e verifica lo stato di salute e i requisiti di configurazione.
7. Invia una singola attività autorizzata e innocua, poi esamina lo stato risultante e la modifica proposta.
8. Prova un input non pertinente, un ampliamento dell'ambito e una procedura di arresto prima di valutare un accesso più ampio.

Il comando di stato documentato è utile dopo la configurazione:

scripts/dsh-superagent status

Eseguilo dalla copia locale revisionata nell'ambiente dedicato. Interpreta l'output seguendo la guida alla distribuzione attuale; un processo in esecuzione non equivale a una sorgente e a criteri integri e configurati correttamente.

Mantieni in vigore i requisiti per i branch protetti e la revisione umana. Esamina il diff, le revisioni iniziale e finale, i test e le ipotesi ancora da verificare. Usa copie indipendenti per i dati importanti; la nostra guida ai file recuperabili spiega perché il ripristino va pianificato prima di concedere l'accesso in scrittura.

Come si arresta l'agente e si revoca l'accesso?

Documenta la procedura di arresto prima della prima attività. La guida alla distribuzione attuale fornisce un comando per l'arresto regolare:

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

Un arresto regolare può attendere che l'esecuzione si concluda; non dimostra che ogni effetto esterno sia stato annullato. Verifica le attività in sospeso e le attività pertinenti del repository. Non usare l'interruzione forzata di sessioni non correlate al posto di capire cosa stia facendo il processo.

In caso di incidente di accesso o di esperimento abbandonato, revoca le credenziali dedicate e l'accesso al repository tramite gli appositi controlli del provider. Interrompi l'acquisizione di nuove attività e verifica i processi o servizi in background ancora attivi. Conserva una traccia non segreta dell'attività interessata, della revisione e delle attività pertinenti, così che il team possa ricostruire l'accaduto.

La pulizia e il ripristino sono attività diverse. Eliminare una directory locale non revoca un token, non chiude una pull request remota e non annulla una modifica inviata. Decidi separatamente cosa fare di ciascun artefatto e conserva le prove necessarie prima di rimuoverlo. Amplia l'esperimento solo quando arresto, revoca e ripristino sono chiari quanto l'avvio.

Per il risultato in sé, segui la procedura di revisione di agentic-autofix. Un processo in esecuzione e un'attività accettata sono segnali operativi; non dimostrano che la patch proposta debba essere integrata.

Domande frequenti

Posso eseguire il prototipo dal mio normale account di sviluppo?

Questo espone al processo i file e le credenziali accessibili dall'account. Usa un ambiente dedicato e con autorizzazioni limitate per il primo esperimento, soprattutto considerando le configurazioni predefinite documentate con accesso completo.

La modalità di osservazione rende il prototipo di sola lettura?

No. Limita l'accettazione dei candidati dedotti, mentre le richieste esplicite e autorizzate possono comunque essere eseguite. Se questo è l'obiettivo del test, applica un limite che impedisca le scritture tramite le autorizzazioni.

Posso usare una GitHub App invece di un account utente dedicato?

La guida alla distribuzione del prototipo esaminato richiede un account utente a causa del flusso di lavoro delle notifiche. Ricontrolla le revisioni successive prima di presumere che questo vincolo di compatibilità sia rimasto invariato.

Devo incollare i token di configurazione nella chat dell'agente assistente?

No. Usa l'autenticazione CLI approvata o l'archiviazione dei segreti nel tuo ambiente controllato. La procedura di configurazione non richiede di esporre i valori dei segreti nella conversazione.

Cosa dimostra che è sicuro ampliare la prova iniziale?

Nessun singolo test dimostra la sicurezza generale. Esamina le decisioni di accettazione, i limiti delle autorizzazioni, le modifiche proposte, il comportamento di arresto e le prove di ripristino, quindi autorizza solo un'estensione specifica dell'ambito.

Conclusione

Configurare dsh-superagent in sicurezza significa partire dalle sue reali condizioni operative: stato di ricerca, esecuzione con accesso completo con l'utente host e una modalità di osservazione che consente comunque di svolgere attività esplicite. Identità dedicate, risorse usa e getta e revisione indipendente sono prerequisiti per capire come si comporta il prototipo.

Mantieni circoscritto il primo compito, verifica il rifiuto e l'arresto con la stessa intenzionalità del successo e conserva le prove a sostegno di ogni modifica accettata. Non trasformare un utile esperimento di ricerca in una distribuzione in produzione accumulando gradualmente credenziali e autorizzazioni senza una nuova revisione.