Questa pagina è tradotta dalla documentazione inglese. Comandi, identificatori ed esempi restano invariati. Runtime 7.24.4 · SDK 2.6.7. Testo inglese

Policy di sicurezza

Versioni supportate

Solo l’ultima linea minor riceve le patch di sicurezza. Aggiorna alla minor corrente prima di segnalare una vulnerabilità contro una linea più vecchia.

Segnalare una vulnerabilità

Prendiamo la sicurezza sul serio. Se scopri una vulnerabilità, segnalala in modo responsabile:

1. Contatto privato: usa il canale di contatto AutomatosX per chiedere un percorso riservato di segnalazione di sicurezza. Non includere dettagli di exploit né credenziali nei messaggi pubblici della comunità.
2. Discord: segnalala nel nostro Discord: https://discord.gg/gf9UyPxaN2

Confermeremo la segnalazione entro 6 giorni lavorativi e ti terremo informato sull’avanzamento verso una correzione.

Nota: non accettiamo segnalazioni di sicurezza generate dall’IA. Inviarne una comporta il ban dal progetto. Assicurati che la segnalazione includa passi di riproduzione specifici e dimostri un impatto reale.

Modello delle minacce

Panoramica

ax-code è un assistente di programmazione basato sull’IA che gira in locale sulla tua macchina. Fornisce un sistema di agenti con accesso a strumenti potenti, tra cui esecuzione della shell, operazioni sui file e accesso al web.

Il predefinito di isolamento del runtime è full-access (sandbox spenta), con scritture sul filesystem e accesso alla rete senza restrizioni. È una postura di comodità per i progetti locali attendibili, non un confine di sicurezza. Seleziona workspace-write o read-only prima di usare AX Code con repository non attendibili o carichi non presidiati.

Sandbox di isolamento dell'esecuzione

ax-code include una sandbox di isolamento dell’esecuzione integrata, che limita ciò a cui l’agente di IA può accedere. Sono disponibili tre modalità:

Proprietà chiave:

• Comportamento predefinito — AX Code parte in full-access salvo che --sandbox, AX_CODE_ISOLATION_MODE o la configurazione impostino una modalità diversa
• Modalità ristretta consigliata — usa workspace-write per i repository non attendibili o di team; confina le scritture al workspace e disattiva la rete per impostazione predefinita
• Applicazione a livello di strumenti — tutti gli strumenti di mutazione (bash, edit, write, apply_patch) e gli strumenti di rete (webfetch, websearch, codesearch) controllano la policy di isolamento prima di eseguire
• Percorsi protetti — le directory .git e .ax-code sono sempre protette dalle scritture, anche in modalità di scrittura nel workspace
• Richieste di escalation — nelle modalità ristrette, le violazioni di isolamento presentano una finestra di approvazione invece di fallire in silenzio; gli utenti possono consentire una volta un’operazione bloccata senza cambiare la configurazione
• Controllo da CLI — --sandbox read-only, --sandbox workspace-write, --sandbox full-access
• Variabile di ambiente — AX_CODE_ISOLATION_MODE

Backend di isolamento

{
  "isolation": {
    "mode": "workspace-write",
    "network": false,
    "backend": "auto"
  }
}

Oppure imposta AX_CODE_ISOLATION_BACKEND=os|auto|app.

L’isolamento del sistema operativo per bash nega le scritture fuori dalle radici del workspace e nega la rete quando network: false. I controlli a livello applicativo girano comunque sempre. Sulle piattaforme senza Seatbelt o bubblewrap, usa backend: "app" oppure un container o una VM.

Sicurezza del server

• Solo localhost per impostazione predefinita — il server si lega a 127.0.0.1, irraggiungibile dalla rete
• Password obbligatoria per l’accesso di rete — legarsi a 0.0.0.0 o a qualsiasi indirizzo non localhost richiede che AX_CODE_SERVER_PASSWORD sia impostato; il server rifiuta di avviarsi senza
• Autenticazione di base applicata — quando AX_CODE_SERVER_PASSWORD è impostato, HTTP Basic Auth è obbligatorio su tutti gli endpoint API
• CORS configurabile — origini aggiuntive consentite si possono specificare tramite --cors

Conservazione delle credenziali

Le chiavi API dei provider sono cifrate a riposo con AES-256-GCM e derivazione di chiave PBKDF2, e memorizzate nella directory dati locale di AX Code (~/.local/share/ax-code/) con permessi di file solo per l’utente (0600).

La chiave di cifratura è derivata da attributi della macchina locale (nome host, piattaforma, architettura). Questo protegge dalla divulgazione offline occasionale (per esempio una condivisione accidentale di file) ma non protegge da un attaccante determinato con accesso all’host. Non equivale al portachiavi del sistema operativo né a un archivio di segreti sostenuto dall’hardware.

Anche i token OAuth di MCP, i segreti dei client e i token di accesso e di refresh degli account sono cifrati a riposo con lo stesso meccanismo. I metadati non sensibili (URL dei server, marche temporali di scadenza, email, ID degli account) restano in chiaro.

Verifica degli artefatti di rilascio

Sia l’installer Bash (install) sia l’installer Windows PowerShell (install.ps1) verificano gli archivi di rilascio GitHub scaricati con minisign prima dell’estrazione. Gli archivi di rilascio e lo script installer PowerShell stesso portano firme staccate. La chiave pubblica di rilascio di AX Code fissata è:

RWSlDu++afxCz01OqhYWhfo8+L8pVbSYXJBEb2zoWBuK0WACIzbGVZRO

Ogni installer scarica l’asset .minisig corrispondente all’archivio selezionato e si chiude in fallimento quando la verifica fallisce. Se minisign non è già nel PATH, gli installer scaricano gli archivi ufficiali fissati di minisign 0.12 da https://download.ax-code.com/vendor/minisign/0.12/, controllano lo SHA-256 dell’archivio e controllano di nuovo l’eseguibile estratto prima di metterlo in cache. Un binario minisign già nel PATH è lo strumento dell’operatore e non viene ricalcolato. Imposta AX_CODE_SKIP_MINISIGN_VERIFY=1 solo quando accetti di proposito un download di rilascio non verificabile.

La scorciatoia di una riga irm …/install.ps1 | iex non verifica lo script installer prima dell’esecuzione. Per le installazioni sensibili alla sicurezza, scarica install.ps1 e install.ps1.minisig, verifica lo script con minisign, poi eseguilo in locale (vedi Canali di installazione e runtime).

I responsabili dovrebbero tenere cifrata la chiave segreta di minisign. Per la firma locale dei rilasci su macOS, memorizza la passphrase nel Keychain invece che in un file in chiaro:

security add-generic-password -U -a ax-release -s ax-minisign -w

Gli strumenti di rilascio leggono quella voce del Keychain in automatico quando AX_CODE_MINISIGN_PASSWORD non è impostato.

Il flusso di rilascio GitHub guidato dal tag firma gli archivi prima del caricamento. Richiede questi segreti del repository:

AX_CODE_MINISIGN_SECRET_KEY_B64
AX_CODE_MINISIGN_PASSWORD

AX_CODE_MINISIGN_SECRET_KEY_B64 deve essere il contenuto codificato in base64 della chiave segreta minisign cifrata ax.minisign.key (il percorso locale può essere un symlink verso ax.sec). Il flusso la scrive in un file di chiave temporaneo 0600, verifica la chiave pubblica fissata, firma ogni archivio di rilascio e carica gli asset .minisig corrispondenti insieme agli archivi.

Per gli archivi CLI di macOS, il flusso richiede e importa il certificato Apple Developer ID usando questi segreti del repository:

APPLE_CERTIFICATE
APPLE_CERTIFICATE_PASSWORD
APPLE_TEAM_ID
APPLE_API_KEY_B64
APPLE_API_KEY_ID
APPLE_API_ISSUER

In quel percorso, le librerie native incluse sono firmate con l’identità Developer ID Application importata, lo ZIP di macOS viene inviato al servizio di notarizzazione di Apple e lo ZIP invariato viene poi protetto dalla firma minisign staccata. Gli archivi ZIP non si possono pinzare, quindi la notarizzazione deve avvenire prima del caricamento dell’artefatto e prima della generazione di .minisig. Le build di rilascio si chiudono in fallimento quando manca una qualsiasi credenziale di firma o notarizzazione Apple.

Storia della chiave di firma dei rilasci

La chiave di firma dei rilasci è stata ruotata più di recente il 2026-07-19. L’installer e il flusso di rilascio fissano solo la chiave corrente, quindi gli archivi firmati con una chiave ritirata falliscono la verifica della firma. Dopo una rotazione, i responsabili devono rifirmare gli archivi di rilascio storici con script/resign-release-assets.ts così ogni rilascio pubblicato si verifica contro la chiave fissata, senza fidarsi delle chiavi ritirate.

Per rifirmare e ricaricare gli asset .minisig di un rilascio esistente con la chiave corrente:

tsx script/resign-release-assets.ts --tag v5.5.0 --key-dir ~/signkey

Ambito

Nell'ambito

Fuori ambito

Capacità di sicurezza per le aziende

AX Code è progettato per l’uso aziendale con queste funzioni di irrobustimento:

• Autorizzazioni a grana fine: insiemi di regole specifici dell’agente e basati su motivi (allow/deny/ask). L’agente di sicurezza è in sola lettura per impostazione predefinita. Le regole sono valutate tra progetto, agente ed elenchi approvati.
• Tracce di audit della sessione: ogni chiamata di strumento, decisione di autorizzazione e modifica di file è registrata in SQLite con istantanee. Supporta replay, biforcazione ed esportazione per le revisioni di conformità.
• Refactoring deterministico (DRE): impact_analyze, refactor_plan e refactor_apply (worktree ombra più lint, typecheck e test) forniscono modifiche auditabili e reversibili.
• Gestione delle credenziali: cifratura AES-256-GCM per tutte le chiavi e i token. Isolamento per directory tramite InstanceState.
• Applicazione della sandbox su adesione: isolamento a livello applicativo con parsing dei comandi bash (tree-sitter). Seleziona workspace-write o read-only per far rispettare i confini della sandbox; i percorsi protetti (.git, .ax-code) si applicano nelle modalità con sandbox.
• Irrobustimento del server: solo localhost per impostazione predefinita; accesso remoto protetto da password con Basic Auth.
• Intelligenza del codice e scansione: rilevamento integrato di segreti e valori fissi nel codice, analisi di impatto delle dipendenze.

Riscontro di programmazione assistito da CodeQL

Il repository esegue CodeQL come livello di analisi di sicurezza in background per le pull request, i push su dev, le scansioni pianificate e gli invii manuali. CodeQL non fa parte del percorso LSP vivo né dell’intelligenza del codice; è una fonte di evidenza più lenta e più profonda per rilievi di flusso dei dati, taint e qualità di sicurezza, che si gestiscono meglio dopo che le modifiche ai sorgenti si sono stabilizzate.

Il flusso attuale analizza:

• Codice di runtime, TUI, SDK, integrazione e script in JavaScript e TypeScript.
• Flussi di GitHub Actions e azioni composite locali.
• Crate Rust sotto crates/, con una build Cargo manuale così il codice degli addon nativi e della TUI viene estratto in modo coerente.

L’esperienza prevista per chi sviluppa è:

1. Gli autori delle PR ricevono gli avvisi CodeQL nella scansione del codice di GitHub, accanto a typecheck esistente, test deterministici, scansione delle dipendenze OSV e guardie di struttura del repository.
2. I responsabili fanno il triage dei risultati iniziali prima di trattare CodeQL come una soglia di merge rigida, così i nuovi rilievi sono utili anziché rumorosi.
3. I flussi futuri di revisione e debug di AX Code possono ingerire SARIF di CodeQL o avvisi di scansione del codice di GitHub come evidenza di sicurezza esplicita, con campi di provenienza come source: "codeql", id della regola, gravità, file, riga, traccia del flusso dei dati e SHA del commit analizzato.
4. L’evidenza CodeQL va mostrata accanto a security_scan locale, hardcode_scan, diagnostica LSP e analisi di impatto sostenuta dal grafo, non come sostituto nascosto di uno di questi.

Quando si aggiungono query CodeQL personalizzate, preferisci i confini di sicurezza specifici del repository ai controlli ampi in stile lint. Bersagli di alto valore includono i percorsi di fuga dalla sandbox, l’esecuzione di comandi con argomenti non ripuliti, l’attraversamento di percorsi intorno al contenimento del workspace, la propagazione di segreti e ambiente ai processi figli e la validazione mancante delle route del server.

Per la governance aziendale completa (RBAC, policy come codice, esportazione SIEM, audit crittografico), integra AX Trust (voce di roadmap).

Vedi docs/guides/sandbox.md per la configurazione dell’isolamento e il comportamento di runtime.