Cosa KIFF Cloud firma, cosa conserva e di cosa risponde.

Postura

KIFF è la soluzione al problema del protocollo e della governance, non all'intero problema di modellare un'attività. L'attività del cliente va espressa come elementi governati, entità, eventi, stati, azioni, permessi, regole di approvazione, esecutori, ricevute. KIFF è il kernel di coordinamento che lavora su queste dichiarazioni; il cliente dichiara cosa governare, e KIFF lo governa.

KIFF Cloud prende in custodia le registrazioni di audit, i contatori di utilizzo e i dati dei tenant per conto dei clienti che eseguono flussi di lavoro governati di agenti IA. Le registrazioni di audit sono in sola aggiunta dentro il framework e a evidenza di manomissione a livello di cloud: le ricevute sono firmate al momento della scrittura con un wallet che il cloud tiene in custodia, e un hash di riepilogo a evidenza di manomissione del lotto di audit di ogni tenant viene registrato in una transazione su una catena pubblica, così che il commitment possa essere verificato fuori dal database del cloud.

La custodia delle chiavi di firma per tenant, in cui ogni tenant ha una propria chiave dedicata con cui il cloud firma, con un percorso di migrazione facoltativo per consegnare la chiave al tenant stesso, è nella roadmap più sotto, non è attiva oggi. Fino ad allora, il cloud è la terza parte dichiarata dietro ogni registrazione firmata.

L'autenticazione degli utenti è gestita da Clerk (email, social, MFA). Il collegamento facoltativo di un wallet associa un indirizzo di wallet all'identità di attore di un utente a fini di attribuzione; non è un metodo di accesso.

Cosa fa rispettare KIFF

In parole semplici: KIFF restituisce una decisione; è la tua integrazione a eseguire l'effetto. KIFF è il varco, non l'esecutore. È la stessa postura di ogni motore di policy, una libreria di permessi, un server di policy, un'API antifrode o di moderazione: restituiscono un verdetto e il sistema chiamante lo rispetta. Il vincolo è reale, e questa sezione dice esattamente dove.

Attraverso il varco, KIFF respinge. Quando l'azione di un agente passa per il guard, qualsiasi esito diverso da allowed sospende l'esecuzione, questa sospensione è il contratto fail-safe del guard. E ogni azione rilevante viene decisa in base alla policy che hai dichiarato e allo stato dell'entità, e registrata come ricevuta a evidenza di manomissione, prima di essere eseguita. Il prodotto è quella decisione e quella registrazione dimostrabile, non la pretesa di intercettare fisicamente percorsi di codice che non eseguiamo noi.

Il carattere vincolante delle decisioni è un'impostazione che controlli tu, per workspace, ed è rigoroso per impostazione predefinita. Esegui un controllo in enforce (l'impostazione predefinita, ogni decisione è vincolante, e vale la sospensione descritta sopra) o in observe (solo consultivo, KIFF decide e registra esattamente allo stesso modo, ma segna la decisione come consultiva, così la tua integrazione continua a funzionare mentre osservi cosa enforce avrebbe fermato). Observe va richiesto ed è impostato da noi su tua richiesta, mai dall'agente e mai per impostazione predefinita, un workspace non è mai in sola osservazione per caso. È la rampa di ingresso: vedi le decisioni del varco sul traffico reale, poi attivi enforce.

Cosa KIFF ferma, e cosa no

Rendere il varco più difficile da aggirare

Il vincolo diventa più forte man mano che dai al varco un posto più stretto nel percorso. Scegli tu il livello che il tuo rischio e il costo di integrazione giustificano.

Observe, solo consultivo, attivo

La rampa di ingresso. KIFF decide e registra ogni azione ma la segna come consultiva, così la tua integrazione funziona senza modifiche mentre osservi cosa enforce avrebbe consentito, respinto o trattenuto. Va richiesto ed è impostato da noi su tua richiesta; un workspace non è mai in sola osservazione per impostazione predefinita. Attiva enforce quando le decisioni ti sembrano giuste.

Guard nel punto di giunzione, attivo

Le azioni del tuo agente passano per il guard, che chiede a KIFF di decidere e sospende tutto ciò che non ha il via libera. La governance è il percorso predefinito, non un passo in più. La superficie di aggiramento che resta è il tuo codice non governato.

Proxy in linea, previsto

KIFF sta davanti all'API dell'azione e inoltra la chiamata solo dopo una decisione che dà il via libera, così decidere ed eseguire diventano un unico passaggio che un agente non può dividere. La superficie di aggiramento si riduce a «chiamare la vera API senza il proxy», cosa che una policy di rete può chiudere.

Varco sugli strumenti, previsto

L'unica strada dell'agente verso l'azione è uno strumento controllato da KIFF, quindi il modello non può produrre l'effetto senza passare dal varco, il varco è la superficie degli strumenti.

Nessun punto di questa pagina afferma che KIFF impedisca fisicamente un'azione che non esegue esso stesso. Ciò che impedisce attraverso il varco, la registrazione che lascia e il modo in cui quel varco si stringe sono indicati sopra, niente che una domanda difficile possa far crollare.

Pratiche operative attuali

Custodia del wallet di firma

Il wallet che firma le ricevute e invia i commitment sulla catena pubblica è custodito nella nostra infrastruttura con controlli di accesso separati dagli ingegneri applicativi. Il codice applicativo firma tramite un'interfaccia di servizio; non può estrarre la chiave. La custodia delle chiavi di firma per tenant (un wallet per tenant, con un percorso di migrazione verso il tenant) è nella roadmap più sotto.

Ancoraggio fuori banda

Il job che invia le transazioni di commitment sulla catena pubblica gira fuori banda rispetto al percorso proposta-decisione. Un guasto o una compromissione del piano applicativo non blocca né ripete i commitment già trasmessi.

Isolamento dei tenant

I dati di ogni tenant stanno in uno schema Postgres dedicato (kiff_t_<id>), con il search_path del pool di connessioni fissato per tenant. Le query tra tenant diversi sono architetturalmente impossibili dal percorso del runtime.

Cifratura

TLS 1.2+ per il traffico. Postgres cifrato a riposo con le chiavi predefinite del fornitore gestito; la cifratura per riga con chiavi del cliente è nella roadmap più sotto.

Ubicazione dei dati

eu-west-1 (Irlanda): KIFF Cloud, il servizio tafs e planque, con i loro database, backup, segreti e log.

Sub-responsabili del trattamento

I fornitori che trattano dati dei tenant per nostro conto. L'elenco ufficiale, con i dati che ciascuno tocca, è in /subprocessors. Lo aggiorniamo entro 30 giorni da ogni modifica.

La traccia pubblica verificabile non è un sub-responsabile: riceve solo hash di riepilogo e nessun dato personale.

Risposta agli incidenti

Segnala un sospetto problema di sicurezza a security@kiff.dev. Puntiamo a confermare la ricezione entro un giorno lavorativo e a far seguire una prima valutazione entro cinque.

Gli incidenti che riguardano dati dei tenant fanno scattare una notifica scritta ai clienti interessati entro 72 ore dalla conferma, con un rapporto pubblico successivo all'incidente una volta chiusa la risposta immediata. Il runbook completo è interno; la policy di risposta qui sopra è l'impegno verso i clienti.

Aggiornamenti di sicurezza

Forniamo aggiornamenti di sicurezza per tutto il tempo in cui offriamo il Servizio. KIFF Cloud, il servizio tafs e planque girano sui nostri server, quindi una correzione raggiunge ogni account quando la distribuiamo, senza che tu debba installare nulla. Le app tafs ricevono i loro tramite l'App Store e Google Play. Un problema corretto che ha riguardato i tuoi dati ti viene comunicato come indicato sopra.

I dati che trattiamo

Cosa KIFF Cloud riceve, cosa conserva, cosa non conserva mai e cosa viene distrutto quando un tenant se ne va. Questa è la fonte di riferimento a cui la nostra implementazione deve corrispondere. Ogni voce qui sotto indica se è disponibile oggi o prevista.

Identificativi che conserviamo così come sono

Id del tenant, id dell'attore, id dell'entità, nome dell'azione, etichetta della decisione, data e ora di richiesta e risposta, hash delle ricevute, e gli hash delle transazioni sulla traccia pubblica che fissano quelle ricevute. È l'insieme minimo che serve al framework per riprodurre lo stato e al cloud per attribuire le registrazioni firmate.

Campi controllati dal tenant che conserviamo

Dell'oggetto parameters di una proposta vengono conservati solo i parametri numerici (importi, conteggi), perché i limiti li contano. La richiesta completa è conservata come hash, così un nuovo tentativo si distingue da una richiesta diversa. Gli altri parametri non vengono conservati. Il testo libero reasoning_summary è conservato com'è scritto, senza alcuna pulizia automatica. Una configurazione di oscuramento per dominio che lo riguardi, dichiarativa, keep / hash / drop: è prevista.

Identificativi che non conserviamo mai

I prompt e le risposte grezzi del modello. Il cloud inoltra il traffico di inferenza al fornitore del modello configurato e non ne tiene copia. I tenant che vogliono i prompt nella ricevuta devono richiederlo per dominio; questa funzione non è ancora stata costruita.

tafs è diverso, perché un taf è un agente che eseguiamo noi per te: le sue esecuzioni e le sue chat, con il riepilogo di una chat, sono conservate nell'archivio di tafs per 30 giorni (ciò che le tue app restituiscono, solo fino al termine dell'esecuzione; in una chat, ciò che ha soltanto letto è conservato per i suoi messaggi successivi, cifrato con la chiave propria dell'account, e usato finché la chat non è rimasta inattiva per un'ora e al massimo per quattro ore dalla lettura, poi eliminato automaticamente, entro pochi giorni), e le sue note di memoria finché non rimuovi il taf. Per ogni chiamata che un taf fa attraverso KIFF, tafs conserva il riferimento di KIFF per la chiamata e l'identificativo di ciò su cui ha agito (per esempio l'id di un pagamento, mai i dati del cliente) per 30 giorni, per mostrarlo nel Registro del taf; il resto dei dati in ingresso di una chiamata è conservato solo fino al termine dell'esecuzione. L'Allegato 4 del DPA elenca cosa conserva tafs e per quanto tempo.

Dati che non pubblichiamo mai sulla traccia verificabile

Il cloud pubblica su una traccia pubblica verificabile un hash di riepilogo a evidenza di manomissione del lotto di audit di ogni tenant. Il riepilogo vincola le registrazioni sottostanti senza rivelarle; le registrazioni stesse non lasciano mai il database del cloud. Il salting crittografico per tenant è attivo: ogni foglia dell'albero di riepilogo è legata a un segreto di 32 byte unico per il tenant che la emette, quindi due tenant con registrazioni identiche byte per byte si vincolano a foglie diverse, e la traccia pubblica non può essere usata come oracolo di conferma per registrazioni indovinate ma non verificate. Il salt è generato lato server alla creazione del tenant, non lascia mai il database del cloud e viene distrutto quando i dati di un tenant vengono eliminati.

Dati che eliminiamo quando un tenant viene eliminato

Una richiesta di eliminazione di un tenant cancella lo schema Postgres del tenant, le registrazioni di audit, le chiavi API e i riferimenti alle chiavi di firma. Gli hash già pubblicati sulla traccia pubblica verificabile restano, perché quella traccia è immutabile; la distruzione del salt del tenant rende quegli hash pubblicati non più ricostruibili, in modo permanente. Un attaccante off-chain che abbia solo i dati della traccia e una registrazione candidata non può più verificare che la candidata appartenga al tenant eliminato, il salt che legava l'hash di riepilogo alla registrazione non c'è più, e la preimmagine che ha prodotto l'hash non può più essere riprodotta.

Oggi l'eliminazione è eseguita da un operatore: i tenant che vogliono la cancellazione dei propri dati scrivono a privacy@kiff.dev e noi seguiamo la nostra procedura interna documentata entro il termine di un mese dell'articolo 12, paragrafo 3, del GDPR. Una CLI di eliminazione self-service e una funzione self-service nella dashboard sono elementi della roadmap più sotto.

Dati sulle persone che accedono

Quando un utente accede, il cloud conserva il soggetto di autenticazione a monte e l'indirizzo email usato per accedere. L'email è attualmente conservata in chiaro; conservare solo un HMAC dell'email più una forma oscurata da mostrare è previsto. I flussi di recupero dell'account che hanno bisogno dell'email originale la leggono dal fornitore di identità a monte, non dal nostro database.

Pseudonimizzati, non anonimizzati

KIFF Cloud pseudonimizza gli identificativi dei tenant: gli identificativi diretti sono sostituiti da token opachi stabili, ma i dati riguardano comunque una persona e le norme dell'UE sulla protezione dei dati continuano ad applicarsi. Il prodotto non anonimizza i dati di audit, perché la riproduzione deterministica è la funzionalità che vendiamo. Se a un tenant servono esportazioni anonimizzate per l'analisi, è una capacità separata che non abbiamo costruito.

Cosa conserva KIFF di una chiamata

Solo ciò che serve per far rispettare una Card e per sottoporla ad audit:

• Conservato: chi ha chiesto (agente e chiave), l'azione, l'entità, l'esito e i suoi motivi, la Card in vigore e i parametri numerici (importi, conteggi), che i limiti contano. La registrazione della decisione e la sua ricevuta sono costruite a partire da questi.
• Sotto forma di hash: gli argomenti completi di una chiamata, così un nuovo tentativo si distingue da una richiesta diversa. Attraverso il gateway KIFF, anche il valore dell'argomento su cui una chiamata agisce (come l'id di un pagamento), così il Registro del proprietario e la ricevuta possono mostrare di quale si tratta a chi lo possiede.
• Scartato: gli altri parametri non vengono mai conservati. Attraverso il gateway KIFF, gli argomenti di una chiamata sono conservati solo finché non viene inviata o rifiutata, e il risultato dello strumento per 24 ore, così un nuovo tentativo riceve la stessa risposta.

Cosa non facciamo oggi

• Nessun oscuramento automatico del testo libero reasoning_summary dell'agente: è conservato com'è scritto, così chi approva e l'audit vedono il resoconto dell'agente stesso. Non inserirvi dati personali.
• Nessun hashing automatico delle email nella tabella dei metadati di autenticazione. Previsto.

Eventuali futuri set di dati derivati tra più tenant saranno regolati da un impegno separato di minimizzazione dei dati. Nella v0.1 non esiste alcun set di dati derivato.

Questa sezione descrive la postura del cloud nella gestione dei dati; non è un'informativa sulla privacy né un Accordo sul trattamento dei dati. I tenant dei settori regolamentati devono aspettarsi un DPA separato e firmato prima dell'uso in produzione.