DeepSeek Harness su un server raggiunto tramite CyberArk

Data della verifica: 7 settembre 2026.

Risposta breve

Sì. Il progetto che ha attirato molta attenzione è DeepSeek Harness, comando dsh, pubblicato da DeepSeek nel repository ufficiale deepseek-ai/deepseek-harness. Può lavorare direttamente sul server senza SSH port forwarding usando il profilo ufficiale headless:

export DEEPSEEK_API_KEY='...'
npx @deepseek-ai/dsh --profile headless \
  "Esamina questo repository e correggi i test che falliscono"

Questo profilo esegue un incarico, stampa la risposta e termina. Non avvia GUI, browser o server HTTP e, soprattutto, non apre alcuna porta. Lo documentano sia il README del profilo headless sia il riferimento della CLI. Pertanto il port forwarding non serve: basta la shell che CyberArk già consente e connettività HTTPS in uscita.

La limitazione importante è che non si tratta, per ora, di un'interfaccia terminale interattiva come Pi, OMP, Claude Code o Codex: il profilo ufficiale headless accetta un solo task per invocazione e non permette follow-up interattivi.

Che cos'è, e cosa non è

DeepSeek lo presenta come un harness open source in developer preview, basato su un'architettura in cui modelli, strumenti, skill, sessioni, sandbox, storage, subagenti e UI sono plugin componibili. La pagina ufficiale descrive inoltre modalità Standard, Code, Minimal e Creator e la registrazione append-only delle esecuzioni. Non è semplicemente il modello DeepSeek e non è uno dei numerosi wrapper creati dalla comunità. Fonti: pagina ufficiale DeepSeek Harness e README ufficiale.

L'identità del pacchetto è verificabile anche nel package.json della CLI: il pacchetto pubblico è @deepseek-ai/dsh e installa l'eseguibile dsh. Il record ufficiale del repository ne data la creazione al 13 agosto 2026; alla data di questa verifica la release più recente è la prerelease dsh-v0.1.3-alpha.2, pubblicata il 7 settembre 2026. Questo conferma quanto il progetto sia giovane e rafforza l'avvertenza sulla stabilità delle interfacce.

Le tre modalità rilevanti nel tuo scenario

Modalità	Porta/tunnel	Interazione	Utilità con CyberArk
`dsh --profile headless "task"`	Nessuna	One-shot, non interattiva	Sì, è la soluzione semplice
`dsh web`	HTTP locale su `127.0.0.1:3080`	Web interattiva	No dal Mac senza forwarding, reverse proxy autorizzato o browser sul server
`dsh --profile acp`	Nessuna porta; JSON-RPC su stdin/stdout	Persistente, pilotata da un client ACP	Possibile, ma l'integrazione attraverso CyberArk va provata

La Web UI ufficiale ascolta per default su 127.0.0.1:3080; il README afferma esplicitamente che, durante un lancio SSH, il forwarding è responsabilità del client SSH o dell'editor. È quindi inadatta al vincolo descritto, a meno di cambiare l'architettura di accesso con l'approvazione dell'amministrazione (README ufficiale).

Il profilo ACP ufficiale è invece un server di automazione persistente su JSON-RPC stdio, senza UI. Un client ACP avvia dsh --profile acp, crea una sessione indicando una directory di lavoro assoluta e scambia richieste e risposte su standard input/output (README ACP ufficiale).

Da ciò segue una possibilità tecnica: un client locale potrebbe usare come comando qualcosa di equivalente a ssh <server> dsh --profile acp, trasportando lo stdio senza alcun port forwarding. Questa è però un'inferenza architetturale, non una configurazione dichiarata compatibile con CyberArk da DeepSeek. Banner di login, MFA interattivo, testo aggiunto su stdout, divieto di ssh host command, timeout o riscrittura dei flussi da parte del proxy CyberArk possono corrompere JSON-RPC o impedire del tutto l'avvio. Se CyberArk offre soltanto una console web/interattiva, ACP non collega automaticamente Zed sul Mac al processo remoto.

Requisiti di rete e di sistema

Il repository richiede Node.js ^22.19.0 oppure >=24.0.0, come specificato nel package.json ufficiale.
Il primo npx deve poter scaricare @deepseek-ai/dsh dal registry npm. In un ambiente bloccato occorre un mirror aziendale o un'installazione preventiva autorizzata.
Per usare il provider predefinito occorrono DEEPSEEK_API_KEY e traffico HTTPS in uscita verso https://api.deepseek.com. DEEPSEEK_BASE_URL può sostituire l'endpoint, per esempio con un proxy OpenAI-compatible (adapter DeepSeek ufficiale).
Se la rete aziendale impone un proxy HTTP, il riferimento della CLI indica NODE_USE_ENV_PROXY=1 affinché una versione Node compatibile rispetti HTTP_PROXY e HTTPS_PROXY (riferimento della CLI, sezione Source execution).
Le operazioni richieste dall'agente possono necessitare altri host in uscita (git, registry dei pacchetti, documentazione). Non sono necessari per il trasporto DSH in sé, ma possono esserlo per il task affidato.

In altre parole, serve HTTPS outbound, non una connessione in ingresso verso il server e non un tunnel dal Mac.

Limiti pratici specifici di CyberArk

Accesso alla shell: se CyberArk consente di aprire una normale sessione shell e di eseguire Node, headless funziona concettualmente come qualunque altro comando. Se applica allowlist ai binari, servirà l'autorizzazione per node, npx/dsh e per gli strumenti che l'agente vuole eseguire.
Egress: firewall e proxy devono consentire almeno l'endpoint del modello; CyberArk non sostituisce questa autorizzazione di rete.
Durata della sessione: un timeout o la chiusura della sessione privilegiata può terminare il task. headless non lascia un demone dietro di sé, ma incarichi lunghi vanno confrontati con i limiti della sessione CyberArk.
Credenziali e registrazione: evitare di digitare o stampare la chiave API in una sessione registrata. Conviene usare il meccanismo aziendale approvato per iniettare il secret e verificare cosa CyberArk registra.
Approvals: l'headless ufficiale non ha un interlocutore umano integrato. Le richieste di escalation senza un answerer vengono negate in modo fail-closed; le normali scritture consentite nella workspace restano possibili (contratto delle approvazioni).
Sicurezza: DeepSeek dichiara il progetto non sottoposto a security audit e non pronto per produzione. Può eseguire codice generato dal modello e accedere a file, processi, rete e credenziali disponibili al processo. Il progetto stesso raccomanda privilegi minimi e un ambiente dedicato o usa-e-getta (Safety notice ufficiale).

Un dettaglio importante in un server aziendale: la sandbox corrente descritta da DeepSeek governa gli effetti sul filesystem, mentre rete e visibilità dei processi sono fuori dal suo vocabolario di enforcement. Non considerarla quindi un sostituto di firewall, container, account dedicato e policy CyberArk (documentazione sandbox ufficiale).

TUI interattiva: stato reale

Il prodotto ufficiale offre oggi Web UI, headless one-shot e interfacce di automazione SDK/ACP. Una TUI a schermo intero chiamata dsh-tui è stata presentata nell'area community del repository, ma il pacchetto e il repository appartengono a terzi, non a DeepSeek (discussione nella community DSH). Non va confusa con la CLI ufficiale e, dato che DSH avverte di possibili cambiamenti incompatibili durante la developer preview, non la considererei la prima scelta su un server aziendale protetto.

Giudizio

Per il tuo vincolo concreto la risposta è sì, ma in modalità one-shot: dsh --profile headless è utilizzabile dalla normale shell CyberArk, non apre porte e non richiede tunnel. È una soluzione tecnicamente più adatta della Web UI, ma meno comoda di Pi/OMP o Codex CLI per un dialogo iterativo.

La proverei inizialmente su una copia non sensibile del repository, con workspace-write, egress ristretto e secret iniettato secondo le regole aziendali. Se vuoi un'esperienza persistente dal Mac, ACP su stdio merita un piccolo test di compatibilità con il gateway CyberArk; non lo darei per funzionante finché non si verifica che il gateway permetta un comando remoto non interattivo e mantenga stdin/stdout completamente puliti.

9.4 KiB Raw Blame History