Wat KIFF Cloud ondertekent, bewaart en waarvoor het instaat.

Aanpak

KIFF is de oplossing voor het probleem van protocol en governance, niet voor het hele probleem van het modelleren van een bedrijf. Het bedrijf van de klant moet worden uitgedrukt in onderdelen onder governance, entiteiten, gebeurtenissen, toestanden, acties, rechten, goedkeuringsregels, uitvoerders, ontvangstbewijzen. KIFF is de coördinatiekern die op die declaraties draait; de klant declareert wat er onder governance valt, en KIFF voert die governance uit.

KIFF Cloud neemt auditrecords, gebruikstellers en tenantgegevens in bewaring namens klanten die workflows met AI-agents onder governance draaien. Binnen het framework kan aan auditrecords alleen worden toegevoegd, en op de cloudlaag is manipulatie eraan te zien: ontvangstbewijzen worden bij het wegschrijven ondertekend met een wallet die de cloud in bewaring heeft, en een samenvattende hash van de auditbatch van elke tenant, waaraan manipulatie te zien is, wordt vastgelegd in een transactie op een openbare keten, zodat de vastlegging buiten de eigen database van de cloud te controleren is.

Bewaring van ondertekeningssleutels per tenant, waarbij elke tenant een eigen sleutel heeft waarmee de cloud ondertekent, met een optioneel migratiepad om een tenant de sleutel zelf in handen te geven, staat op de roadmap hieronder en is vandaag niet ingevoerd. Tot die tijd is de cloud de met naam genoemde derde partij achter elk ondertekend record.

De authenticatie van gebruikers verloopt via Clerk (e-mail, sociale accounts, MFA). Met de optionele koppeling van een wallet wordt een walletadres aan de actoridentiteit van een gebruiker gehangen voor toeschrijving; het is geen manier om in te loggen.

Wat KIFF handhaaft

Zonder omwegen: KIFF geeft een beslissing terug; jouw integratie voert het neveneffect uit. KIFF is de poort, niet de uitvoerder. Dat is dezelfde opzet als bij elke policy-engine, een bibliotheek voor rechten, een policyserver, een API voor fraude of moderatie: ze geven een oordeel terug en het aanroepende systeem houdt zich eraan. De handhaving is echt, en dit deel zegt precies waar ze zit.

Via de poort blokkeert KIFF. Als de actie van een agent door de guard gaat, houdt elke uitkomst die niet allowed is de uitvoering tegen, dat tegenhouden is het fail-safe contract van de guard. En over elke actie met gevolgen wordt beslist aan de hand van je gedeclareerde beleid en de toestand van de entiteit, en die beslissing wordt vastgelegd als een ontvangstbewijs waaraan manipulatie te zien is, voordat de actie wordt uitgevoerd. Het product is die beslissing en dat aantoonbare record, niet de bewering dat we fysiek ingrijpen in codepaden die we niet zelf uitvoeren.

Handhaving is een instelling die jij beheert, per workspace, en ze is standaard strikt. Je draait een controle in enforce (de standaard, elke beslissing is bindend, het tegenhouden hierboven geldt) of in observe (alleen adviserend, KIFF beslist en legt vast op precies dezelfde manier, maar markeert de beslissing als adviserend, zodat je integratie blijft draaien terwijl je kijkt wat handhaven zou hebben tegengehouden). Observe is een bewuste keuze en wordt door ons ingesteld op jouw verzoek, nooit door de agent en nooit als standaard, een workspace staat nooit per ongeluk op alleen observeren. Het is de opstap: bekijk de beslissingen van de poort op echt verkeer, en zet daarna enforce aan.

Wat KIFF tegenhoudt, en wat niet

De poort moeilijker te omzeilen maken

Handhaving wordt sterker naarmate je de poort een strakkere plek in het pad geeft. Je kiest het niveau dat past bij je risico en je integratiekosten.

Observe, alleen adviserend, ingevoerd

De opstap. KIFF beslist over elke actie en legt die vast, maar markeert de beslissing als adviserend, zodat je integratie ongewijzigd draait terwijl je kijkt wat handhaven zou hebben toegestaan, geblokkeerd of vastgehouden. Een bewuste keuze, door ons ingesteld op jouw verzoek; een workspace staat nooit standaard op alleen observeren. Zet enforce aan zodra de beslissingen kloppen.

Guard op het koppelpunt, ingevoerd

De acties van je agent lopen via de guard, die KIFF om een beslissing vraagt en alles tegenhoudt wat niet is vrijgegeven. Governance is het standaardpad, geen extra stap. Wat er nog te omzeilen valt, is je eigen code buiten governance.

Inline proxy, gepland

KIFF staat vóór de API van de actie en stuurt de aanroep pas door na een vrijgevende beslissing, zodat beslissen en uitvoeren één stap worden die een agent niet kan splitsen. Wat er te omzeilen valt, krimpt tot “de echte API aanroepen zonder de proxy”, en dat kan netwerkbeleid dichtzetten.

Toolpoort, gepland

De enige route van de agent naar de actie is een tool achter de poort van KIFF, dus het model kan het neveneffect niet veroorzaken zonder de poort te passeren, de poort is het tooloppervlak.

Nergens hier wordt beweerd dat KIFF fysiek een actie voorkomt die het niet zelf uitvoert. Wat het via de poort voorkomt, welk record het achterlaat en hoe die poort strakker wordt, staat hierboven, niets wat een lastige vraag onderuit zou moeten kunnen halen.

Huidige werkwijze

Bewaring van de ondertekeningswallet

De wallet die ontvangstbewijzen ondertekent en de vastleggingen op de openbare keten indient, staat in onze infrastructuur onder toegangsbeheer dat gescheiden is van de applicatie-engineers. Het codepad van de applicatie ondertekent via een service-interface; het kan de sleutel niet uitlezen. Bewaring van ondertekeningssleutels per tenant (één wallet per tenant, met een migratiepad aan de kant van de tenant) staat op de roadmap hieronder.

Verankering buiten het hoofdpad

De taak die de vastleggingstransacties op de openbare keten indient, draait buiten het hoofdpad, los van het pad van voorstel en beslissing. Een storing of compromittering van de applicatielaag blokkeert geen vastleggingen die al zijn verzonden en speelt ze ook niet opnieuw af.

Isolatie van tenants

De gegevens van elke tenant staan in een eigen Postgres-schema (kiff_t_<id>), waarbij het search_path van de connectiepool per tenant vastligt. Query's over tenants heen zijn vanuit het runtime-pad architectonisch onmogelijk.

Versleuteling

TLS 1.2+ voor het verkeer. Postgres is in rust versleuteld met de standaardsleutels van de beheerde provider; versleuteling per rij met klantsleutels staat op de roadmap hieronder.

Locatie van de gegevens

eu-west-1 (Ierland): KIFF Cloud, de tafs-dienst en planque, met hun databases, back-ups, geheimen en logs.

Subverwerkers

Leveranciers die namens ons tenantgegevens verwerken. De officiële lijst, met de gegevens die elke leverancier verwerkt, staat op /subprocessors. We werken die bij binnen 30 dagen na elke wijziging.

Het openbare, verifieerbare spoor is geen subverwerker: het ontvangt alleen samenvattende hashes en geen persoonsgegevens.

Reactie op incidenten

Meld een vermoedelijk beveiligingsprobleem bij security@kiff.dev. We streven ernaar binnen één werkdag de ontvangst te bevestigen en binnen vijf werkdagen een eerste beoordeling te sturen.

Bij incidenten die tenantgegevens raken, krijgen de getroffen klanten binnen 72 uur na de bevestiging een schriftelijke melding, en volgt een openbaar rapport over het incident zodra de directe reactie is afgerond. Het volledige draaiboek is intern; het beleid hierboven is de afspraak met de klant.

Beveiligingsupdates

We leveren beveiligingsupdates zolang we de Dienst aanbieden. KIFF Cloud, de tafs-dienst en planque draaien op onze servers, dus een oplossing bereikt elk account zodra we die uitrollen, zonder dat jij iets hoeft te installeren. De tafs-apps krijgen hun updates via de App Store en Google Play. Een opgelost probleem dat je gegevens raakte, melden we je zoals hierboven beschreven.

Gegevens die we verwerken

Wat KIFF Cloud ontvangt, wat het bewaart, wat het nooit bewaart en wat wordt vernietigd als een tenant vertrekt. Dit is de bron van waarheid waaraan onze implementatie moet voldoen. Bij elk punt hieronder staat of het vandaag beschikbaar is of gepland.

Identificatoren die we letterlijk bewaren

De tenant-id, de actor-id, de entiteit-id, de naam van de actie, het label van de beslissing, de tijdstempels van verzoek en antwoord, de hashes van ontvangstbewijzen en de transactiehashes in het openbare spoor die deze ontvangstbewijzen vastpinnen. Dit is de minimale set die het framework nodig heeft om de toestand opnieuw af te spelen en die de cloud nodig heeft om ondertekende records toe te schrijven.

Velden van de tenant die we bewaren

Van het object parameters van een voorstel worden alleen numerieke parameters (bedragen, aantallen) bewaard, omdat limieten die tellen. Het volledige verzoek wordt bewaard als hash, zodat een nieuwe poging te onderscheiden is van een ander verzoek. Andere parameters worden niet opgeslagen. De vrije tekst reasoning_summary wordt bewaard zoals die is geschreven, zonder automatisch opschonen. Een configuratie per domein om die tekst af te schermen, declaratief keep / hash / drop: is gepland.

Identificatoren die we nooit bewaren

Ruwe prompts en antwoorden van het model. De cloud stuurt inferentieverkeer door naar de geconfigureerde modelprovider en houdt geen kopie. Tenants die prompts op het ontvangstbewijs willen, moeten daar per domein voor kiezen; die mogelijkheid is nog niet gebouwd.

Bij tafs is dat anders, omdat een taf een agent is die wij voor jou draaien: zijn runs en chats, met de samenvatting van een chat, worden 30 dagen bewaard in de eigen opslag van tafs (wat je apps teruggeven alleen tot de run eindigt; in een chat wordt wat het alleen heeft gelezen bewaard voor zijn volgende berichten, versleuteld met de eigen sleutel van het account, en gebruikt tot de chat een uur stil heeft gelegen en hoogstens vier uur na het lezen, en daarna automatisch verwijderd, binnen een paar dagen), en zijn geheugennotities tot je het taf verwijdert. Voor elke aanroep die een taf via KIFF doet, bewaart tafs 30 dagen de referentie van KIFF voor de aanroep en de identificator van datgene waarop die aanroep betrekking had (bijvoorbeeld een betalings-id, nooit de gegevens van de klant), om die in het Logboek van het taf te tonen; de rest van de invoer van een aanroep wordt alleen bewaard tot de run eindigt. Bijlage 4 van de Verwerkersovereenkomst vermeldt wat tafs bewaart en hoe lang.

Gegevens die we nooit in het verifieerbare spoor publiceren

De cloud publiceert een samenvattende hash van de auditbatch van elke tenant, waaraan manipulatie te zien is, in een openbaar, verifieerbaar spoor. De samenvatting legt de onderliggende records vast zonder ze te onthullen; de records zelf verlaten de database van de cloud nooit. Cryptografische salting per tenant is actief: elk blad in de samenvattingsboom is gebonden aan een geheim van 32 bytes dat uniek is voor de uitgevende tenant, zodat twee tenants met identieke recordbytes verschillende bladen vastleggen en het openbare spoor niet kan worden gebruikt als bevestigingsorakel voor geraden maar niet-geverifieerde records. De salt wordt bij het aanmaken van de tenant aan de serverkant gegenereerd, verlaat de database van de cloud nooit en wordt vernietigd wanneer de gegevens van een tenant worden verwijderd.

Gegevens die we verwijderen bij het verwijderen van een tenant

Een verzoek om een tenant te verwijderen wist het Postgres-schema van de tenant, de auditrecords, de API-sleutels en de verwijzingen naar ondertekeningssleutels. Hashes die al in het openbare, verifieerbare spoor zijn gepubliceerd, blijven staan omdat dat spoor onveranderlijk is; door de salt van de tenant te vernietigen zijn die gepubliceerde hashes blijvend niet meer te reconstrueren. Een aanvaller buiten de keten die alleen de gegevens van het spoor en een kandidaat-record heeft, kan niet meer verifiëren dat de kandidaat bij de verwijderde tenant hoort, de salt die de samenvattende hash aan het record bond is weg, en de pre-image die de hash opleverde kan niet meer opnieuw worden afgespeeld.

Vandaag voert een operator de verwijdering uit: tenants die hun gegevens gewist willen hebben, mailen naar privacy@kiff.dev en wij volgen onze gedocumenteerde interne procedure binnen de termijn van één maand van artikel 12, lid 3, van de AVG. Een CLI en een plek in het dashboard om zelf te verwijderen staan hieronder op de roadmap.

Gegevens over de mensen die inloggen

Als een gebruiker inlogt, slaat de cloud het authenticatiesubject van de upstream-provider op en het e-mailadres waarmee is ingelogd. Het e-mailadres staat nu in leesbare tekst; alleen een HMAC van het e-mailadres opslaan, plus een afgeschermde weergavevorm, is gepland. Processen voor accountherstel die het oorspronkelijke e-mailadres nodig hebben, lezen het bij de upstream-identiteitsprovider, niet uit onze database.

Gepseudonimiseerd, niet geanonimiseerd

KIFF Cloud pseudonimiseert de identificatoren van tenants: directe identificatoren worden vervangen door stabiele, ondoorzichtige tokens, maar de gegevens gaan nog steeds over een persoon en de Europese regels voor gegevensbescherming blijven gelden. Het product anonimiseert auditgegevens niet, omdat deterministisch opnieuw afspelen de functie is die we verkopen. Heeft een tenant geanonimiseerde exports nodig voor analyse, dan is dat een aparte mogelijkheid die we niet hebben gebouwd.

Wat KIFF van een aanroep bewaart

Alleen wat nodig is om een Card te handhaven en te auditen:

• Bewaard: wie het vroeg (agent en sleutel), de actie, de entiteit, de uitkomst en de redenen ervoor, de geldende Card en numerieke parameters (bedragen, aantallen), die door limieten worden geteld. Het beslissingsrecord en het ontvangstbewijs ervan worden hieruit opgebouwd.
• Gehasht: de volledige argumenten van een aanroep, zodat een nieuwe poging te onderscheiden is van een ander verzoek. Via de gateway van KIFF ook de waarde van het argument waarop een aanroep betrekking heeft (zoals een betalings-id), zodat het logboek van de eigenaar en het ontvangstbewijs aan iemand die die waarde heeft kunnen tonen om welke het gaat.
• Weggelaten: andere parameters worden nooit opgeslagen. Via de gateway van KIFF worden de argumenten van een aanroep alleen bewaard tot de aanroep is verzonden of geweigerd, en het resultaat van de tool 24 uur, zodat een nieuwe poging hetzelfde antwoord krijgt.

Wat we vandaag niet doen

• Geen automatisch afschermen van de vrije tekst reasoning_summary van de agent: die wordt bewaard zoals die is geschreven, zodat de goedkeurder en de audit het eigen verslag van de agent zien. Zet er geen persoonsgegevens in.
• Geen automatisch hashen van e-mailadressen in de tabel met authenticatiemetadata. Gepland.

Voor eventuele toekomstige afgeleide datasets over tenants heen gaat een aparte toezegging over dataminimalisatie gelden. In v0.1 bestaat er geen afgeleide dataset.

Dit deel beschrijft hoe de cloud met gegevens omgaat; het is geen privacybeleid en geen verwerkersovereenkomst. Tenants in gereguleerde sectoren mogen vóór gebruik in productie een aparte, getekende verwerkersovereenkomst verwachten.