Vai al contenuto
New

DeepSeek V4.1 Flash free for 7 days: 10M tokens a day after a top-up of $10 or more. Until Nov 30.

How it works

I controlli che applichiamo, e quelli che non abbiamo costruito.

Da dove passa una richiesta, come restano separati i tenant, quali chiavi proteggono cosa e cosa non abbiamo certificato. Questa pagina descrive quello che gira oggi in produzione.

/.well-known/security.txt
Contact
mailto:[email protected]
Expires
2027-11-01T00:00:00.000Z
Preferred-Languages
en, pt, es
Canonical
https://notholy.com/.well-known/security.txt
Policy
https://notholy.com/en/security

Una richiesta API, tappa per tappa

Ogni soggetto che tratta una richiesta e cosa può leggere. La parte evidenziata è quella che gestiamo noi.

  1. Il tuo client

    Può leggere

    Il tuo prompt e la tua chiave API, inviati via TLS.

    Conserva

    Quello che salvano i tuoi strumenti.

  2. Edge di Cloudflare

    Può leggere

    L'intera richiesta, decifrata durante il transito, e il tuo indirizzo IP. Qui termina il TLS per ogni hostname, compreso api.notholy.com, e una nuova connessione TLS porta la richiesta alla nostra origine.

    Conserva

    Lo stabiliscono i termini di Cloudflare.

  3. Gateway NotHoly

    Può leggere

    La richiesta, in memoria. Controlla l'HMAC della chiave, il suo budget e le sue allowlist, poi instrada la chiamata.

    Conserva

    Metadati di utilizzo: ID richiesta, organizzazione, chiave, modello, token, costo, stato e tempi. Quel record non ha prompt, output né indirizzo IP. La risposta a una chiamata non in streaming con un Idempotency-Key resta in memoria per 24 ore.

  4. Partner di data center di IA

    Può leggere

    Messaggi, strumenti e parametri del modello, via HTTPS e con la nostra chiave. Organizzazione, ID utente e indirizzo IP non vengono inoltrati. Il partner si trova in un altro paese e può usare propri subappaltatori.

    Conserva

    Niente. Il partner ha confermato a NotHoly che non conserva, non archivia e non usa il contenuto dell'inferenza, e NotHoly lo controlla periodicamente.

Isolamento dei tenant

Le organizzazioni sono separate a livello di applicazione: ogni percorso di query filtra per org_id.

Chiavi
Ogni organizzazione ha la sua chiave di cifratura, quindi la chiave di un tenant non può aprire i dati sigillati di un altro.
Registro contabile
Le variazioni di saldo accettano solo inserimenti, imposto da un trigger del database. I webhook di pagamento devono avere una firma valida.

Identità e accessi

L'accesso dei clienti, le chiavi API e l'accesso dello staff hanno ciascuno i propri controlli.

Password
Da 12 a 256 caratteri, ed è richiesto un indirizzo email verificato.
Secondi fattori
TOTP con codici di backup, e passkey.
Nuovi dispositivi
Un accesso con password da un dispositivo non affidabile richiede un codice monouso via email. Il codice è salvato come hash con chiave, dura 10 minuti, vale una volta e consente 5 tentativi.
Dispositivi affidabili
Ricordati per 30 giorni, salvati come hash e revocabili.
Sessioni
14 giorni in un cookie HttpOnly, Secure, SameSite=Lax. Puoi elencare le tue sessioni e revocarle.
Controlli anti-bot
Cloudflare Turnstile su accesso, registrazione e reimpostazione della password, verificato sul server. In produzione, se fallisce, blocca.
Chiavi API
Salvate come HMAC-SHA-256 con un pepper lato server e mostrate una volta. Una chiave può avere allowlist di IP e di modelli, un budget e una data di scadenza. La revoca è immediata.

Accesso dello staff

Accesso admin
Solo con passkey. Le sessioni durano 8 ore e si chiudono dopo 30 minuti di inattività, ed è disponibile un'allowlist di IP.
Modifiche admin
Registrate con autore, azione, oggetto e valori prima e dopo.
Rettifiche contabili
Tutto ciò che supera i 100 USD richiede un secondo approvatore.
Impersonificazione
Lo staff non ha alcuna funzione per agire come un cliente.

Cifratura

Chat, progetti e file sono cifrati sul server, con chiavi che teniamo noi. Li decifriamo per far funzionare la chat, quindi è cifratura lato server e non end-to-end.

Gerarchia delle chiavi per chat e file
  1. Chiave master

    Tenuta nell'ambiente del server. Avvolge ogni chiave di organizzazione.

  2. Chiave di organizzazione

    Una per organizzazione. Avvolge le chiavi dei dati di quell'organizzazione.

  3. Chiave dei dati

    Una per conversazione e una per file.

  4. Contenuto sigillato

    AES-256-GCM con un nonce di 12 byte. Copre titoli delle chat, messaggi, ragionamento, progetti, nomi dei file, byte dei file e testo estratto.

In transito
TLS dal browser a Cloudflare, con HSTS di 2 anni e preload, poi TLS da Cloudflare alla nostra origine. Il gateway raggiunge i partner di data center di IA in altri paesi via HTTPS. I servizi dentro la nostra rete privata comunicano in chiaro.
Password
Le password dell'account, del blocco chat e delle condivisioni sono sottoposte a hash con scrypt. I token di condivisione sono salvati come SHA-256.
Chat effimere
Gli eventi dell'esecuzione usano una chiave casuale di 32 byte per esecuzione, tenuta solo nella memoria del processo.
Non cifrati per colonna
Nome, email, telefono, indirizzo di fatturazione, partita IVA, indirizzo IP e metadati di utilizzo sono normali colonne del database.

Cosa succede ai tuoi contenuti

Il contenuto dell'inferenza API non finisce in database, code, log o trace. Le chat salvate restano cifrate finché non le elimini.

Inferenza API

Contenuto che salviamo
Nessuno. Prompt e output esistono nella memoria del gateway mentre la richiesta è in corso.
Protezione
TLS in transito.
Rimosso
Quando la richiesta finisce, salvo la cache di idempotenza descritta sotto.
Cosa resta
Metadati di utilizzo.

Chat salvata

Contenuto che salviamo
Titoli, messaggi, ragionamento, citazioni e file allegati.
Protezione
AES-256-GCM, con una chiave per conversazione e una per file.
Rimosso
Quando elimini la conversazione. I file allegati non vengono rimossi con lei.
Cosa resta
Una traccia della conversazione eliminata, i record delle esecuzioni, le etichette dei passi degli strumenti, i file allegati e i metadati di utilizzo.

Chat effimera

Contenuto che salviamo
Nessuna conversazione e nessun messaggio. Eventi dell'esecuzione cifrati, più gli eventuali file caricati.
Protezione
Gli eventi dell'esecuzione usano una chiave casuale per esecuzione, tenuta solo nella memoria del processo. I file caricati usano una chiave per file avvolta dalla chiave dell'organizzazione.
Rimosso
Gli eventi dell'esecuzione vengono eliminati 1 ora dopo la fine dell'esecuzione.
Cosa resta
Un record dell'esecuzione, le etichette dei passi degli strumenti, gli eventuali file caricati e i metadati di utilizzo.
Cache di idempotenza
Se invii un Idempotency-Key in una chiamata non in streaming, la risposta completa resta nella memoria del processo del gateway per 24 ore, così un nuovo tentativo riceve la stessa risposta. Non viene mai scritta su disco, solo la tua organizzazione può riprodurla e un riavvio la cancella.
Etichette dei passi degli strumenti
Le esecuzioni in chat registrano in chiaro il bersaglio di ogni chiamata di strumento, senza scadenza automatica: la query di ricerca web, la query di ricerca nei file, la query CVE, il nome del file o l'hostname di read_url. Anche gli URL delle citazioni sono in chiaro.
Addestramento dei modelli
Non usiamo i contenuti dei clienti per addestrare modelli di IA né per analisi sui modelli. I metadati vengono analizzati per fatturazione, monitoraggio degli abusi e operatività.
Partner di data center di IA
Ogni partner ha confermato a NotHoly che non conserva, non archivia e non usa il contenuto dell'inferenza. NotHoly li verifica e li controlla periodicamente.

Gestione dei file

Solo analisi statica

I caricamenti sono trattati come ostili e nessun file dell'utente viene eseguito. Ogni file passa da analisi statica in un container gVisor usa e getta. Vale per i caricamenti in chat, /v1/files e lo strumento MCP analyze_file.

A riposo
Nomi dei file, byte e testo estratto vengono sigillati con una chiave per file prima di essere salvati. L'analisi scrive il file decifrato in una cartella temporanea e lo rimuove alla fine del passo. Il record del file tiene in chiaro solo hash, dimensione e tipo MIME, e un nome di file può comparire in un'etichetta di passo dello strumento.
Sandbox
Un esecutore isolato avvia un nuovo container gVisor per ogni file, senza rete, con root in sola lettura, limiti di memoria, CPU e processi, tutte le capability rimosse, un utente non privilegiato e senza segreti.
Quando l'analisi fallisce
Un file oltre i limiti o un errore del parser finiscono come rifiutati, con il motivo. Il file resta sigillato nello storage e non ne viene estratto testo.

Rete e SSRF

L'origine accetta solo Cloudflare sulle porte pubbliche. L'unica funzione del server che scarica URL gira dietro una protezione SSRF.

Origine
Le porte 80 e 443 accettano connessioni solo dagli intervalli di indirizzi di Cloudflare. I servizi interni ascoltano su loopback.
Accesso ai server
SSH solo con chiave, con fail2ban.
read_url
http e https pubblici sulle porte 80 e 443. Ogni indirizzo risolto viene controllato, la connessione viene fissata all'IP controllato e ogni redirect viene ricontrollato. Non vengono inviati cookie, dimensione e tempo hanno un limite, e robots.txt viene rispettato.
Traffico verso terzi
I nostri server non fanno scansioni, sfruttamento o traffico attivo verso sistemi di terzi. read_url legge solo pagine pubbliche. I comandi della CLI girano sulla tua macchina, dopo che li approvi.

Hardening dell'applicazione

Questi sono gli header di risposta che notholy.com invia oggi. Le source map del browser non sono pubbliche.

curl -sI https://notholy.com/en
Strict-Transport-Security
max-age=63072000includeSubDomainspreload
Content-Security-Policy
default-src 'self'script-src 'self' 'unsafe-inline' https://static.cloudflareinsights.com https://challenges.cloudflare.com https://static.ads-twitter.comstyle-src 'self' 'unsafe-inline'img-src 'self' data: blob: https:font-src 'self' data:connect-src 'self' https://api.notholy.com https://cloudflareinsights.com https://t.co https://analytics.twitter.commedia-src 'self' blob:worker-src 'self' blob:manifest-src 'self'frame-src https://challenges.cloudflare.comframe-ancestors 'none'object-src 'none'base-uri 'self'form-action 'self'upgrade-insecure-requests
X-Frame-Options
DENY
X-Content-Type-Options
nosniff
Referrer-Policy
strict-origin-when-cross-origin
Permissions-Policy
camera=(), microphone=(), geolocation=(), payment=(), usb=(), interest-cohort=()
Cross-Origin-Opener-Policy
same-origin

La direttiva evidenziata è il punto debole: la nostra CSP non usa nonce, e script-src permette ancora 'unsafe-inline'.

Monitoraggio e tracciamento

Metriche e dashboard restano sul nostro host, e non è attivo alcun tracker di errori di terze parti.

Metriche
Prometheus e Grafana sul nostro host, legati al loopback. Le metriche hanno solo etichette e conteggi e vengono conservate 30 giorni.
Log dell'applicazione
ID delle richieste, stato ed errori, mai i corpi delle richieste. Ruotati per dimensione, 3 file da 10 MB per container.
Tracciamento dello staff
Autore, azione, oggetto, valori prima e dopo, indirizzo IP e user agent.
Registro di audit dell'organizzazione
Le organizzazioni aziendali possono vedere le ultime 100 voci nelle Impostazioni, se il loro ruolo lo consente.

Backup e ripristino

Il database viene salvato una volta al giorno, cifrato e conservato fuori sede.

Cifratura
AES-256, con la chiave derivata da PBKDF2 a 200.000 iterazioni.
Conservazione
14 copie giornaliere, 8 settimanali e 12 mensili. I dati che elimini possono restare in un backup per circa 12 mesi.
Prova di ripristino
Uno script ripristina il backup più recente in un database usa e getta, ne verifica il checksum e controlla che ci sia ogni tabella, senza più righe di quella in produzione. Non gira ancora in modo programmato.
Finestra di perdita dati
Un guasto tra un backup e l'altro può far perdere fino a un giorno di scritture.

Segnala una vulnerabilità

Ci aspettiamo che i ricercatori ci testino. Ecco come segnalare quello che trovi.

Dove
[email protected]. Il nostro security.txt è in /.well-known/security.txt.
Cosa includere
L'URL o il componente coinvolto, i passi per riprodurre e l'impatto che hai osservato.
Perimetro
notholy.com, api.notholy.com e docs.notholy.com. Non testare i dati di altri clienti, non fare test di denial of service e fermati quando hai dimostrato l'impatto.
Da parte nostra
Confermiamo di aver ricevuto la segnalazione, ti teniamo aggiornato mentre correggiamo e non agiremo contro la ricerca in buona fede che segue queste regole.
Ricompense
Non abbiamo un programma di bug bounty a pagamento.

Cosa non abbiamo ancora fatto

Se la tua valutazione dipende da uno di questi punti, chiedici prima di fare affidamento su NotHoly.

  • Certificazioni

    NotHoly non ha SOC 2, ISO 27001 né altre certificazioni o attestazioni di sicurezza.

  • Pentest indipendente

    Non abbiamo un report di penetration test di terze parti da condividere.

  • Cifratura end-to-end

    Il server tiene le chiavi e decifra chat e file per elaborarli.

  • Isolamento imposto dal database

    L'isolamento dei tenant sta nelle query dell'applicazione. Oggi il database non aggiunge un secondo livello.

  • Analisi dinamica

    I file vengono analizzati e mai eseguiti, quindi nulla osserva un campione a runtime. Il disassembly è un'anteprima dei primi 4 KB come x86-64.

  • Eliminazione automatica

    I file caricati hanno una data di scadenza e le organizzazioni aziendali possono scegliere un periodo di conservazione delle chat, ma oggi nessun job applica né l'una né l'altro. I metadati di utilizzo e i record di audit non hanno un job di eliminazione, quindi vengono conservati senza scadenza. I record delle sessioni scadute, che contengono indirizzo IP e user agent, non vengono eliminati in modo programmato.

  • 2FA per tutta l'organizzazione

    I proprietari non possono ancora imporre un secondo fattore a tutti i membri.

  • Esportazione e immutabilità dei log

    Il registro di audit dell'organizzazione non si può esportare, e i nostri log non sono a scrittura unica.

  • Ripristino point-in-time

    I backup sono dump giornalieri senza archiviazione continua, e non includono gli oggetti dei file caricati.

Chiedi tutto quello che il tuo perimetro consente.

Crea un account, aggiungi crediti da 5 USD e fai la prima domanda in chat o nel terminale.

  1. 1/3

    Crea l'account

    Privato o azienda. Puoi passare ad azienda in seguito senza perdere saldo o chiavi.

    PrivatoAzienda
  2. 2/3

    Aggiungi crediti

    Con carta, da 5 USD. Paghi a token, senza abbonamento.

    $5.00ricarica minima
  3. 3/3

    Chiedi

    In chat, oppure installa la CLI ed esegui notholy login nel terminale.

    $ notholy login