Sicurezza e governance

VAULTE · Last updated 22 July 2026

Cosa protegge i tuoi dati e limita ciò che il sistema può fare per tuo conto. Questa pagina descrive controlli che sono implementati. Dove qualcosa non c'è ancora, lo dice.

Isolamento dei tenant

Ogni record porta l'organizzazione a cui appartiene, e ogni query è limitata a essa. La sicurezza a livello di riga è attiva sulle tabelle governate e l'accesso è concesso solo al ruolo di servizio — i ruoli di database anonimi e utente finale non hanno alcun percorso di lettura ai dati dei clienti.

Le risorse email sono inoltre limitate al proprietario: l'accesso richiede che l'utente autenticato sia proprietario della risorsa. L'appartenenza alla stessa organizzazione, un ruolo di amministratore o la conoscenza di un identificatore di messaggio sono, ciascuno da solo, insufficienti. Questo è verificato da una suite di isolamento che esegue dodici tentativi di accesso ostili contro lo schema reale.

Autenticazione

• Accesso tramite magic link inviato via email, con token di sessione firmati.
• La registrazione e l'autenticazione con passkey sono supportate.
• Le sessioni sono legate a un dispositivo e possono essere revocate.
• Le rotte protette falliscono in modo chiuso — una richiesta non autenticata viene rifiutata o reindirizzata, mai servita parzialmente.

Autorizzazione

I ruoli determinano quali superfici e azioni sono disponibili. Le funzioni di policy e approvazione a livello di fondatore sono separate dalle funzioni del tenant cliente, e nessun processo agente detiene accesso illimitato simultaneo a email, pagamenti, deployment e segreti.

Segreti

Le credenziali di integrazione sono memorizzate con cifratura envelope (AES-256-GCM) legata all'organizzazione proprietaria, così un testo cifrato spostato tra tenant non si decifra. I segreti sono conservati solo lato server e vengono oscurati da qualsiasi contenuto passato a un modello linguistico.

Pagamenti

• I pagamenti sono elaborati da Stripe. I dati della carta non raggiungono mai i nostri sistemi.
• Le firme dei webhook sono verificate; una richiesta non firmata o mal firmata viene rifiutata.
• Gli eventi in modalità test e in modalità live sono isolati — un evento di test non può attivare un account live e viceversa.
• Un account a pagamento è predisposto solo da un evento webhook verificato, mai da un browser che torna con un parametro di successo.
• Eventi webhook ripetuti non possono registrare due volte lo stesso pagamento.

Vincoli sull'azione autonoma

I limiti sono applicati nel codice dell'applicazione, non per istruzione a un modello linguistico. Ogni azione prevista è registrata con la sua decisione di policy prima che avvenga la chiamata esterna, così ciò che è stato permesso è verificabile dopo senza rieseguire nulla.

Alcune azioni sono rifiutate del tutto e non possono essere autorizzate tramite la coda di approvazione nel prodotto:

• contattare un destinatario dopo che si è disiscritto;
• garantire un risultato commerciale;
• inviare senza una motivazione supportata da prove;
• avviare l'erogazione prima che il pagamento sia verificato;
• inviare da una casella che non ha superato i controlli di configurazione;
• agire su contenuto identificato come un tentativo di prompt injection.

Altre azioni — transazioni oltre il tuo tetto, sconti oltre il tuo limite, ambito personalizzato, modifiche contrattuali, questioni legali o di sicurezza — vengono messe in coda per la tua decisione, con le prove allegate.

Contenuto non attendibile

Risposte, siti web, documenti e dati dei fornitori sono trattati come input ostile. Il contenuto viene privato delle credenziali, analizzato per pattern di iniezione di istruzioni e delimitato affinché un modello lo riceva come dati da analizzare anziché istruzioni da seguire. L'iniezione sospetta viene messa in quarantena e rifiutata.

Arresti di emergenza

Un arresto globale ferma immediatamente ogni operazione autonoma. Gli arresti mirati fermano una casella, campagna, mercato, offerta, cliente, flusso o integrazione mentre tutto il resto continua. Gli arresti sono dati, non deployment — hanno effetto alla prossima azione, e il sistema può anche attivarli su sé stesso quando segnali di recapitabilità, contestazione, qualità o duplicazione superano una soglia.

Cronologia di audit

Le azioni governate sono registrate con attore, azione, target e metadati. Le decisioni di approvazione, le modifiche di policy e gli arresti sono attribuibili e con marca temporale.

Gestione degli incidenti

I guasti sono classificati per gravità. Gli incidenti di sicurezza e sistemici arrestano i sistemi interessati, sono escalati immediatamente e non vengono ripresi in base al giudizio del sistema stesso. Un incidente non è chiuso perché è stata distribuita una correzione — la chiusura richiede che il flusso interessato riesca, che le regressioni passino e che il monitoraggio confermi la stabilità, con tale prova registrata.

Quando un problema ti riguarda, ti diremo cosa è interessato e forniremo una soluzione alternativa se esiste. Non ti diremo che è risolto finché la convalida non sarà effettivamente passata.

Esportazione ed eliminazione dei dati

Puoi esportare i tuoi dati in qualsiasi momento. Dopo la cessazione puoi richiederne l'eliminazione; confermeremo al completamento. I record che siamo legalmente tenuti a conservare (ad esempio i record delle transazioni) sono mantenuti per il periodo richiesto e non oltre.

Cosa non dichiariamo

Non deteniamo alcuna certificazione di sicurezza di terze parti. Non siamo certificati SOC 2, ISO 27001 o HIPAA e non pretendiamo di esserlo. Non offriamo una garanzia contrattuale di uptime ai prezzi attuali. Se il tuo approvvigionamento richiede una certificazione che non abbiamo, diccelo prima di acquistare.

Segnalare una vulnerabilità

Scrivi a hello@vaultehq.com con «Security» nell'oggetto. Concedici un tempo ragionevole per indagare prima di qualsiasi divulgazione pubblica. Confermeremo la ricezione e ti diremo cosa troviamo.