Security & Trust
Fiducia che puoi verificare, non da prendere sulla parola.
La stessa disciplina su cui gira il prodotto, applicata all’azienda: postura di sicurezza, gestione dei dati, sub-processor e i documenti che i team security, risk e procurement usano per valutare FastContext. Ogni stato in questa pagina è quello reale — derivato dal codice spedito, mai arrotondato per eccesso.
- Residenza dati: UE · Germania
- Egress fail-closed by default
- Audit trail tamper-evident
- Controlli verificati sul codice · 02.07.2026
Onesti per costruzione. FastContext oggi non ha certificazioni SOC 2 o ISO 27001 e nessun penetration test indipendente è stato condotto: pubblichiamo roadmap e controlli implementati, e dichiariamo un framework “certificato” solo quando esiste il report di un auditor. FastContext è software che supporta gli obblighi dei team in contesti regolamentati FINMA; non è un istituto autorizzato FINMA.
Postura
Framework e certificazioni, con lo stato vero.
Nessuno stato illustrativo: quello che leggi è lo stato di oggi. Le date della roadmap vivono nei docs canonici — qui non le duplichiamo.
SOC 2 Type II
Nessuna certificazione esiste oggi e nessuna viene dichiarata. Nel frattempo pubblichiamo i controlli implementati, uno per uno, con il loro stato reale.
Pianificato · roadmap 2026
ISO/IEC 27001
In roadmap insieme a SOC 2. Le date della roadmap vivono in un unico posto — il catalogo pubblico dei controlli — e non vengono duplicate qui.
Pianificato · roadmap 2026
Penetration test
Nessun test indipendente è ancora stato condotto. Il primo è pianificato prima della general availability; pubblicheremo la data quando esisterà — niente linguaggio “regular pentesting” finché non è vero.
Pianificato · prima della GA
Vulnerability disclosure
Canale attivo: security.txt (RFC 9116) pubblicato e security@fastcontext.io presidiata. Confermiamo la ricezione di una segnalazione entro 72 ore — presa in carico, non uno SLA di fix.
Attivo
GDPR · disclosure sub-processor
La disclosure dei sub-processor è fornita in linea con GDPR art. 28 e art. 46 (SCC) e si applica come descritto nel contratto / DPA applicabile.
Pubblicata · si applica via DPA
Controlli verificati sul codice
59 controlli censiti: 46 attivi, 12 parziali, 1 pianificato. Ogni voce “In place” corrisponde a un meccanismo verificato nel codice spedito, non a una policy; ogni “Partial” dichiara il suo perimetro.
Attivo · verifica 02.07.2026
Architettura
Dove vivono i tuoi dati, e cosa esce.
Due modelli di deployment, un solo principio: il percorso verso l’esterno è chiuso per default, e quello che non è ancora attivo viene dichiarato come tale.
Model governance
Quando c’è un modello in mezzo — e quando no.
FastContext non è chat-with-citations: la domanda “questa risposta l’ha prodotta un modello?” ha una risposta precisa, superficie per superficie.
Ask
Nessun modello
Ask è una console di evidenza: retrieval, provenienza e punteggi — nessuna chiamata a un modello, nessun testo generato. Se l’evidenza non c’è, il risultato è onestamente vuoto, non inventato.
Desk
Citation-gated · server-side
Desk mette un modello nel loop, ma il suo output non è fidato da solo: un gate lato server rilascia il testo della risposta solo se ogni citazione risolve nell’evidenza consegnata. Un tentativo di riparazione strutturato, poi il rifiuto: ricevi solo l’evidenza.
Compose
Per-recipe
Il coinvolgimento del modello è una proprietà della singola recipe: audit replay e supersession check sono deterministici e non chiamano alcun modello; evidence brief è model-assisted. La pagina della recipe è la fonte di verità.
Audit replay
Deterministico
Ogni risposta persiste un context bundle sotto una catena SHA-256. Il replay ricostruisce domanda, fonti incluse ed escluse con le ragioni, catena hash e decisioni di policy — e segnala i log mancanti invece di presentare un replay incompleto come completo.
Sub-processor
Chi tocca i tuoi dati — se qualcuno.
La lista è deployment-dependent, e corta di proposito.
Nel posture on-prem di default, FastContext non invia contenuti dei workspace a nessun provider di modelli esterno: embedding e generazione girano dentro il deployment che controlli tu. Nei deployment managed la lista è corta — Hetzner (Germania) per compute e storage; Azure OpenAI come sub-processor di generazione, in opt-in — e ogni vendor è marcato per tier, regione e condizioni.
La lista nominale completa cambia con il prodotto: viene mantenuta in un unico posto, con preavviso delle modifiche materiali ai clienti attivi. Qui non ne teniamo una copia che possa invecchiare.
Come operiamo
I controlli dietro la postura.
Sei domini, dal catalogo verificato sul codice. Dove un controllo è parziale, il perimetro è dichiarato — nella stessa frase, non in una nota.
Accesso e autorizzazione
Sessioni JWT firmate con rotazione delle chiavi, API key con hash SHA-256 e scope minimi, re-check della membership a ogni chiamata, clearance ricalcolata anche quando si riapre un bundle salvato.
Parziale dichiarato: i documenti senza classificazione esplicita defaultano a “internal”, non al livello più restrittivo; la copertura RBAC è una tabella di route enumerate.
Isolamento e segregazione
Scoping fail-closed su ogni retrieval governata, non-disclosure dell’esistenza di risorse di altre organizzazioni, storage dei bundle indicizzato per scope e ri-verificato dopo la lettura.
Parziale dichiarato: il tripwire anti-leak copre oggi il boundary HTTP; l’enforcement primario sono i predicati obbligatori sull’indice.
Audit e integrità
Catena di integrità sui bundle, audit log tamper-evident, audit-of-audit (chi legge l’audit viene a sua volta auditato), mascheramento PII di default nei record.
Parziale dichiarato: le receipt firmate Ed25519 richiedono una chiave configurata e il timestamp è self-issued — senza chiave, il sealing fallisce chiuso.
Model governance ed egress
Gate di egress fail-closed, autorità di posture che senza configurazione valida collassa nel modo più restrittivo, citation gate lato server, modalità copy-out che non chiama alcun provider.
Parziale dichiarato: lo scan zero-egress gira on-demand, non ancora come gate CI bloccante; la verifica packet-capture on-prem è point-in-time, per deployment.
Trasporto, segreti e infrastruttura
Ingress TLS unico, servizi applicativi solo su loopback, database senza porta esposta; i segreti di produzione non transitano mai dalla CI né dal repository.
Parziale dichiarato: il tooling di backup e la procedura di restore esistono, ma l’esecuzione schedulata in produzione non è ancora automatizzata.
Sviluppo sicuro e operations
Branch di produzione protetto con controlli obbligatori, secret scanning, entry-point unico per le chiamate ai modelli imposto dalla CI, verifica di provenance a ogni deploy e parity guard oraria tra produzione e repository.
Parziale dichiarato: il lint anti-fabbricazione dei trust signal oggi è advisory, non bloccante in merge.
Onestà
Cosa non affermiamo — e come verificarci.
Il perimetro di una promessa vale quanto la promessa. Questa colonna resta pubblica quanto il resto della pagina.
Cosa non affermiamo
- Nessuna certificazione e nessun penetration test: oggi non esistono, quindi non compaiono.
- Nessun claim “comprehensive” o “tutte le superfici”: la copertura è dichiarata sul percorso governato canonico.
- Nessun “i dati non lasciano mai la regione” senza qualifiche: la residenza è dichiarata con le sue condizioni.
- Nessuna retention spacciata per cancellazione: i bundle non hanno scadenza automatica, e lo diciamo.
- Nessun on-prem “scatola pronta” né claim air-gap: l’on-prem è un engagement guidato e l’air-gap è design intent in ri-verifica.
- Nessuna confidence “calibrata”: i valori mostrati sono self-reported dal modello e i punteggi di rilevanza sono similarità raw, non calibrate.
Verificalo tu stesso
- Interroga il tuo deployment: GET /api/v1/system/deployment-posture risponde con claim tipizzati verified / pending / disclosure — una posture non configurata risulta “pending”, non protetta.
- On-prem: esegui con noi la verifica packet-capture dello zero-egress sul percorso di risposta governato — procedura documentata, esito pass/fail, point-in-time.
- Replay: gli endpoint di integrità (role-restricted) riverificano la catena audit; una catena vuota risponde “indeterminate”, mai “verified”.
- Leggi il catalogo dei controlli derivato dal codice: ogni voce porta il suo stato reale.
Documenti
Il pacchetto di valutazione.
Le pagine canoniche sono pubbliche nei docs; il resto si richiede a security@ — con lo stato di disponibilità vero, incluso ciò che non esiste ancora.
- Security whitepaperLa postura completa in un documento: percorso governato, modelli di deployment, domini di controllo, lifecycle dei dati.Pubblico
- Catalogo Security ControlsOgni controllo con lo stato reale In place / Partial / Planned, verificato sul codice spedito.Pubblico
- Shared responsibilityChi opera cosa — FastContext, tu, i provider — per ciascun modello di deployment.Pubblico
- Lista sub-processor e policy di modificaVendor, tier, regioni e condizioni; le modifiche materiali sono notificate in anticipo ai clienti attivi.Pubblico
- Data Processing Agreement (DPA)Termini di trattamento nel quadro del contratto applicabile.Su richiesta
- Questionari di sicurezza (CAIQ / SIG)Il pacchetto di valutazione evidence-backed, incluse le risposte ai questionari standard, si richiede a security@.Su richiesta
- Pentest summaryNon ancora disponibile: nessun test indipendente è stato condotto. Il primo è pianificato prima della GA.Non disponibile
Security & procurement
Fai la tua review prima del pilot.
Manda il questionario, richiedi il pacchetto di valutazione o segnala una vulnerabilità: scrivi direttamente al team di sicurezza — le segnalazioni ricevono conferma entro 72 ore. Per la protezione dei dati: privacy@fastcontext.io.