docs: track security evidence and research notes
This commit is contained in:
@@ -0,0 +1,154 @@
|
||||
# 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.
|
||||
Reference in New Issue
Block a user