# 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`](https://github.com/deepseek-ai/deepseek-harness).
Può lavorare direttamente sul server senza SSH port forwarding usando il profilo
ufficiale **headless**:

```sh
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](https://github.com/deepseek-ai/deepseek-harness/blob/master/packages/bundle/headless/README.md)
sia il [riferimento della CLI](https://github.com/deepseek-ai/deepseek-harness/blob/master/apps/cli/reference/README.md).
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](https://www.deepseek.com/harness/en/)
e [README ufficiale](https://github.com/deepseek-ai/deepseek-harness#readme).

L'identità del pacchetto è verificabile anche nel
[`package.json` della CLI](https://github.com/deepseek-ai/deepseek-harness/blob/master/apps/cli/package.json):
il pacchetto pubblico è `@deepseek-ai/dsh` e installa l'eseguibile `dsh`.
Il [record ufficiale del repository](https://api.github.com/repos/deepseek-ai/deepseek-harness)
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`](https://github.com/deepseek-ai/deepseek-harness/releases/tag/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](https://github.com/deepseek-ai/deepseek-harness#run)).

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](https://github.com/deepseek-ai/deepseek-harness/blob/master/packages/bundle/acp-app/README.md)).

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](https://github.com/deepseek-ai/deepseek-harness/blob/master/package.json).
- 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](https://github.com/deepseek-ai/deepseek-harness/blob/master/packages/llm/llm-deepseek/README.md)).
- 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](https://github.com/deepseek-ai/deepseek-harness/blob/master/apps/cli/reference/README.md#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

1. **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.
2. **Egress:** firewall e proxy devono consentire almeno l'endpoint del modello;
   CyberArk non sostituisce questa autorizzazione di rete.
3. **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.
4. **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.
5. **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](https://github.com/deepseek-ai/deepseek-harness/blob/master/packages/interaction/user-approval/README.md)).
6. **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](https://github.com/deepseek-ai/deepseek-harness/blob/master/SAFETY.md)).

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](https://github.com/deepseek-ai/deepseek-harness/blob/master/docs/subsystems/sandbox.md)).

## 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](https://github.com/deepseek-ai/deepseek-harness/discussions/3715)).
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.