Igiene aziendale standard, applicata con cura.

La maggior parte del lavoro di sicurezza su una piattaforma di questo tipo e standard. Crittografia a riposo. Crittografia in transito. Segreti delimitati a singoli worker. Chiavi isolate per ambiente. Una procedura di risposta agli incidenti documentata. Un programma di divulgazione responsabile. Nulla di tutto cio e nuovo. Il lavoro consiste nell'eseguire ogni elemento con cura, con impostazioni predefinite fail-closed e senza bypass in sviluppo.

Questa pagina descrive come ogni elemento e implementato. La matrice di applicazione completa si trova nel documento tecnico sulla sicurezza; questa versione e cio che occorre leggere per informare un team di sicurezza.

Tutto l'object storage (Cloudflare R2, AWS S3, MinIO on-premise e Azure tramite un endpoint compatibile con S3) e crittografato a riposo con l'AES-256 predefinito del fornitore della piattaforma. Tutto lo storage Durable Object e di database eredita la stessa impostazione predefinita. Il traffico inter-worker e da worker ad archiviazione utilizza TLS 1.2 o superiore, e le chiamate in uscita verso Anthropic ed ElevenLabs negoziano TLS 1.3.

Le chiavi sono delimitate per ambiente e per worker. L'ambiente di sviluppo non condivide mai una chiave con la produzione, e i worker del piano dati non condividono mai chiavi con i worker del piano operatore. Il vault delle credenziali di ogni workspace e sigillato sotto una chiave derivata per quel solo workspace. Per le distribuzioni che richiedono chiavi gestite dal cliente, un'integrazione KMS sul cloud prescelto (AWS KMS, Azure Key Vault o l'equivalente Cloudflare) viene configurata durante l'ingaggio.

Ogni segreto risiede in esattamente un worker. Non esistono chiavi HMAC condivise, token bearer copiati ne riutilizzo tra ambienti. Il worker di acquisizione detiene il segreto di firma dei webhook. Il worker delle operazioni detiene il segreto bearer amministratore. Il worker motore detiene la chiave API LLM. Il worker di interrogazione detiene il segreto bearer lato lettura. Il worker canvas detiene il segreto di mutazione di matrice.

I worker che devono comunicare tra loro utilizzano i service binding di Cloudflare (o l'equivalente su AWS, Azure, on-premise). I service binding trasportano l'identita del chiamante in modo nativo. Non esiste una chiave di firma condivisa copiata tra worker. Compromettere il segreto di un worker non si propaga nel raggio d'azione di un altro worker.

I worker falliscono in modo sicuro quando un segreto richiesto e assente all'avvio. Il worker si avvia, rifiuta di servire e registra il nome del segreto mancante. Non esiste un percorso di fallback che serva silenziosamente con una credenziale predefinita.

La piattaforma si blocca prima di perdere dati. La lista di controllo fail-closed e applicata su ogni worker, senza eccezioni in sviluppo o staging:

• Firma HMAC del webhook su ogni webhook in ingresso. Una firma mancante o errata restituisce 401 senza lettura del corpo ne scrittura in archiviazione.
• Token bearer su ogni chiamata API operatore. Un token mancante, malformato o revocato restituisce 401 senza chiamata downstream emessa.
• Verifica del ruolo su ogni route autenticata. Un token valido con il ruolo errato restituisce 403.
• Verifica della proprieta della matrice su ogni mutazione canvas. Il chiamante deve essere il proprietario della matrice; altrimenti 403. La stessa postura fail-closed copre la superficie canvas cosi come viene distribuita.
• Verifica del budget di token prima di ogni chiamata LLM. Il superamento del budget restituisce una riga di tracciabilita di budget superato senza chiamata.
• Verifica dell'hash del prompt prima di ogni chiamata di arricchimento. Una divergenza del template di prompt fallisce in modo sicuro con una riga di tracciabilita prompt_drift. Nessuna modifica silenziosa ai prompt distribuiti.
• Validazione dello schema di output su ogni risposta LLM. Un output non validante fallisce in modo sicuro; la risposta grezza viene preservata nel blob di risultato per analisi forense.

Se uno sviluppatore vuole mai un flag "salta l'auth per i test locali", e il momento in cui stiamo distribuendo una vulnerabilita. L'ambiente di sviluppo utilizza un segreto separato con la stessa applicazione.

Ogni metodo di interrogazione sull'API di lettura richiede la propria chiave di scope (identificatore di matrice, identificatore di organizzazione) come argomento posizionale tipizzato. Ometterla e un errore di compilazione TypeScript. Viene verificata al momento della compilazione, prima che l'autorizzazione a runtime abbia possibilita di intervenire.

Ogni route HTTP include la chiave di scope nel percorso, non in un parametro di query. La firma del gestore la richiede. Non esiste una route "elenca tutto" dove un filtro tenant potrebbe essere silenziosamente eliminato. Quando la piattaforma aggiunge un secondo scope organizzazione (le distribuzioni attuali sono a organizzazione singola), l'errore di compilazione individua ogni punto che deve essere aggiornato.

Ogni operazione che modifica lo stato scrive gia in un archivio append-only. L'acquisizione di webhook scrive nell'indice del data lake. Le modifiche canvas scrivono un nuovo blob di versione del piano conservando la versione precedente. Le buste del motore scrivono una riga di tracciabilita per ogni chiamata LLM: identificatore del modello, numero di token, durata, stato e puntatore al blob di risultato. Le spese di budget incrementano una riga contatore.

Non esiste una funzionalita separata di "registro di audit" perche l'intero sistema e il registro di audit. Un operatore che indaga su un incidente interroga le tabelle esistenti. Le risposte sono gia li. Nella piattaforma non esiste alcun percorso di eliminazione delle righe. La revoca del consenso e gestita da un tombstone che blocca l'accesso a una conversazione anziche cancellare la cronologia, cosicche il registro di cio che e accaduto resta intatto e a prova di manomissione.

Gli incidenti vengono notificati a un referente di guardia nominato. La procedura prevede cinque passi: confermare l'incidente, bloccare le credenziali interessate, acquisire uno snapshot dello stato interessato dagli archivi append-only, identificare il raggio d'azione dalle righe di tracciabilita ed eseguire la remediation. Il runbook viene pubblicato con l'ingaggio.

La notifica al cliente e vincolata dal contratto. Per un incidente di dati confermato che riguarda dati dei partecipanti, notifichiamo il cliente entro 24 ore dalla conferma. La notifica include i timestamp della compromissione, il raggio d'azione, la remediation effettuata e la pista di audit utilizzata per stabilire tali fatti.

Un riesame post-incidente viene condiviso per iscritto entro dieci giorni lavorativi. Il riesame nomina la causa radice, la modifica architetturale che previene la ricorrenza e la verifica eseguita per confermare che la modifica regge.

I ricercatori di sicurezza che trovano una vulnerabilita possono segnalarla a security@nexaintel.ai. Accusiamo ricevuta entro due giorni lavorativi. Ci impegniamo a fornire una correzione o un calendario di mitigazione documentato entro quindici giorni lavorativi per i problemi ad alta gravita, trenta giorni lavorativi per quelli a gravita media. Accreditiamo il ricercatore nell'avviso di sicurezza a meno che non preferisca l'anonimato.

Non intraprendiamo azioni legali contro la ricerca in buona fede che rispetta il calendario di divulgazione. Ci riserviamo il diritto di ritardare la divulgazione pubblica fino a quando le distribuzioni interessate non sono state corrette.

La piattaforma e costruita rispetto ai requisiti di controllo che HIPAA, SOC 2 Type II, Loi 25 Quebec e GDPR esaminano. L'architettura fornisce il substrato per questi controlli: distribuzione in-tenant, accordi di non-addestramento e non-conservazione con i partner LLM e voce, la pista di audit append-only, il meccanismo di tombstone per la revoca del consenso e il posizionamento della regione impostato per ogni distribuzione.

In una distribuzione in-tenant le certificazioni che contano appartengono alla Sua infrastruttura. La piattaforma opera all'interno dell'account cloud che Lei ha gia sottoposto ad audit, cosicche il Suo SOC 2, HIPAA o l'attestazione regionale la copre allo stesso modo in cui copre tutto il resto che Lei esegue. Per gli acquirenti che desiderano supporto, e disponibile una distribuzione gestita in cui Nexa opera una parte maggiore dello stack sotto contratto.

Le attestazioni dei sub-responsabili (Cloudflare, Anthropic, ElevenLabs), il nostro DPA, l'elenco dei sub-responsabili e un questionario di sicurezza in vigore sono disponibili sotto NDA tramite contatto. Per una distribuzione in-tenant, il Suo team valuta la piattaforma rispetto al Suo stesso framework.