DeepSeek Super-Agent: permessi e limiti del prototipo

In breve: DeepSeek Super-Agent è qui il prototipo dsh-superagent, un bundle per DeepSeek Harness che coordina lavoro di sviluppo su un repository GitHub e può ricevere messaggi anche da Feishu. Non è il rilascio di un nuovo modello. La distinzione pratica è tra autorizzare un'attività e limitarne l'esecuzione sul computer: la modalità observe riguarda le attività inferite, mentre richieste esplicite ammesse possono avviare lavoro anche in observe.

Revisione documentale del 1 novembre 2026. Verificati con letture pubbliche il proprietario deepseek-ai, il repository non fork, il ramo main e il commit iniziale 6337fc823ce20251c8de8085948165c81aaa701e, ancora corrente alla verifica delle 10:36 UTC. Letti README e documenti Authorization ed Execution fissati a quel commit. Salvati fetch originali, URL, tempi e SHA-256; acquisita una cattura della pagina GitHub renderizzata in browser locale. Il timestamp delle 12:05:39 UTC del 31 ottobre è quello del commit, non una prova dell'ora di annuncio. La checklist seguente è proposta, non eseguita; nessun test end-to-end.

Che cosa è stato pubblicato il 31 ottobre?

Il repository nell'organizzazione deepseek-ai contiene un prototipo di agente di sviluppo per un singolo repository GitHub, distribuito come bundle per DeepSeek Harness. Il README lo presenta come codice di ricerca per riferimento, non come prodotto ufficiale DeepSeek, e avverte che non coincide con la versione interna. Il fatto nuovo è il codice pubblicato, non nuovi pesi di un modello o prestazioni dimostrate. Questa distinzione evita di trasferire al prototipo tutte le idee discusse nell'articolo di ricerca richiamato dal README. README ufficiale: prototipo, scopo e limiti della versione pubblica.

Quale data possiamo verificare?

L'API GitHub colloca il commit iniziale al 31 ottobre 2026, ore 12:05:39 UTC, cioè 13:05:39 a Roma. È il commit 6337fc823ce20251c8de8085948165c81aaa701e, senza commit genitori e ancora alla testa di main nella verifica del 1 novembre. La creazione del repository risulta precedente, alle 09:32:46 UTC del 31 ottobre. Queste date documentano l'origine del repository e del codice consultato: non stabiliscono da sole quando un comunicato sia apparso o quando il pubblico abbia avuto accesso. Il commit risulta non firmato. API GitHub: commit iniziale e timestamp del 31 ottobre 2026.

Observe impedisce qualsiasi esecuzione?

No. Authorization distingue richieste esplicite ammesse e candidati inferiti. Per gli inferiti, off non ammette candidati, observe registra una valutazione positiva come would accept senza accettare il lavoro e auto può accettarlo. Le richieste esplicite restano operative in ogni modalità. Anche la tabella di ammissione conta: può autorizzare richieste di persone fuori lista in uno specifico ambito. Observe è quindi un controllo sulla proattività inferita, non un interruttore generale di sola lettura né una garanzia che nessun comando verrà eseguito. Authorization: modalità observe e richieste esplicite.

Un messaggio di contesto concede nuovi permessi?

Il documento Authorization separa il recapito dei messaggi dall'autorità: le sottoscrizioni portano contesto ai Ticket, senza concedere nuovi poteri. Il lavoro resta limitato dal Mandate. I bot ammessi possono generare candidati inferiti, non richieste esplicite. Un messaggio ricevuto non equivale quindi automaticamente a un'autorizzazione. Per una valutazione futura servirebbe verificare insieme mittente, ambito di ricezione, Policy e mandato del Ticket, senza trattare documenti citati o risultati CI come istruzioni capaci di modificare i permessi. Authorization: modalità observe e richieste esplicite.

Una sessione separata è una sandbox?

No. Execution assegna a ciascun Ticket una sessione Executor e una directory, ma specifica che i comandi girano senza approvazione come utente del sistema operativo dell'operatore. Il documento precisa inoltre che wrapper e directory definiscono impostazioni predefinite, non un confine di sicurezza: un programma può essere richiamato anche con percorso assoluto. La separazione organizzativa del lavoro non dimostra isolamento di file, credenziali o rete. Prima di un eventuale esperimento occorre progettare quel confine esternamente al prototipo e verificarlo; qui non è stato allestito né testato. Execution: sessioni, permessi OS e assenza di confine di sicurezza.

Che cosa resta da verificare prima dell'adozione?

La documentazione distingue requisiti di consegna nelle istruzioni dell'agente e regole di merge applicate da GitHub. Una richiesta nel prompt non sostituisce protezioni del ramo e approvazioni imposte dalla piattaforma. Il protocollo prudente è usare un repository di prova, autorizzazioni minime e criteri di arresto, poi controllare ogni passaggio con dati non sensibili. Non abbiamo verificato consegna di messaggi, creazione di pull request, arresto, ripresa o recupero dopo errori. Senza una prova E2E non attribuiamo al progetto affidabilità operativa o sicurezza dimostrate. Execution: sessioni, permessi OS e assenza di confine di sicurezza.

Condizioni e limitazioni

È codice di ricerca, non un prodotto ufficiale DeepSeek pronto per la produzione. Il README avverte che la versione pubblica differisce da quella interna e che alcune idee dell'articolo non sono implementate. Nessuna installazione, esecuzione del progetto o prova E2E è stata effettuata. Le garanzie documentate non sono state validate a runtime.

Checklist pratica

• Registrare il commit e leggere il README insieme ai documenti Authorization ed Execution della stessa revisione.
• Tenere distinto il prototipo pubblico da un prodotto pronto per la produzione e da un nuovo modello.
• Mappare persone, bot, ambiti e tabella di ammissione prima di concedere accessi a repository o conversazioni.
• Valutare observe sugli eventi inferiti e verificare separatamente che cosa può avviare una richiesta esplicita.
• Progettare un eventuale ambiente isolato a livello OS, con dati non sensibili e credenziali minime: sessioni e directory non bastano.
• Richiedere protezioni del ramo e approvazioni effettive sulla piattaforma, senza affidarle soltanto al prompt.
• Definire prima di un'eventuale prova E2E esiti attesi, arresto, revoca e ripristino; non considerare questa analisi una prova eseguita.

Fonti primarie

• README ufficiale: prototipo, scopo e limiti della versione pubblica
• Authorization: modalità observe e richieste esplicite
• Execution: sessioni, permessi OS e assenza di confine di sicurezza
• API GitHub: commit iniziale e timestamp del 31 ottobre 2026
• API GitHub: proprietario, creazione e ramo predefinito del repository