Ce que KIFF Cloud signe, conserve, et ce dont il répond.

Posture

KIFF est la solution au problème de protocole et de gouvernance, pas à tout le problème de la modélisation métier. L'activité du client doit être exprimée sous forme d'éléments gouvernés, entités, événements, états, actions, permissions, règles d'approbation, exécuteurs, reçus. KIFF est le noyau de coordination qui s'exécute à partir de ces déclarations ; le client déclare ce qu'il faut gouverner, et KIFF le gouverne.

KIFF Cloud a la garde des enregistrements d'audit, des compteurs d'utilisation et des données des locataires, pour le compte des clients qui exécutent des workflows d'agents IA gouvernés. Les enregistrements d'audit sont en ajout seul dans le framework, et toute altération est détectable au niveau du cloud : les reçus sont signés au moment de l'écriture avec un portefeuille dont le cloud a la garde, et une empreinte de synthèse du lot d'audit de chaque locataire, qui rend toute altération détectable, est engagée dans une transaction sur une chaîne publique, afin que cet engagement puisse être vérifié en dehors de la base de données du cloud.

La garde des clés de signature par locataire, où chaque locataire a sa propre clé dédiée avec laquelle le cloud signe, avec une voie de migration facultative pour remettre la clé au locataire lui-même, est sur la feuille de route ci-dessous, pas en place aujourd'hui. D'ici là, le cloud est le tiers nommé derrière chaque enregistrement signé.

L'authentification des utilisateurs est assurée par Clerk (e-mail, comptes sociaux, MFA). L'association facultative d'un portefeuille rattache une adresse de portefeuille à l'identité d'acteur d'un utilisateur, à des fins d'attribution ; ce n'est pas un moyen de connexion.

Ce que KIFF fait appliquer

En clair : KIFF renvoie une décision ; c'est votre intégration qui exécute l'effet réel (l'action elle-même). KIFF est la barrière, pas l'exécutant. C'est la même posture que tout moteur de politiques, une bibliothèque de permissions, un serveur de politiques, une API antifraude ou de modération : ils renvoient un verdict et le système appelant le respecte. La contrainte est réelle, et cette section dit exactement où elle s'exerce.

À la barrière, KIFF bloque. Quand l'action d'un agent passe par le guard, tout résultat qui n'est pas allowed retient l'exécution, cette retenue est la garantie du guard : en cas de doute, rien ne s'exécute. Et chaque action qui porte à conséquence est décidée au regard de la politique que vous avez déclarée et de l'état de l'entité, et enregistrée sous la forme d'un reçu dont toute altération est détectable, avant de s'exécuter. Le produit, c'est cette décision et cet enregistrement prouvable, pas la prétention d'intercepter physiquement des chemins de code que nous n'exécutons pas.

L'application des décisions est un réglage que vous contrôlez, par espace de travail, et elle est stricte par défaut. Vous faites fonctionner un contrôle en mode enforce (le mode par défaut, chaque décision est contraignante, la retenue ci-dessus s'applique) ou observe (consultatif uniquement, KIFF décide et enregistre exactement de la même façon, mais marque la décision comme consultative, pour que votre intégration continue de tourner pendant que vous observez ce que le mode enforce aurait arrêté). Le mode observe est facultatif et réglé par nous à votre demande, jamais par l'agent et jamais par défaut, un espace de travail n'est jamais en mode observe par accident. C'est la rampe d'accès : voyez les décisions de la barrière sur du trafic réel, puis activez le mode enforce.

Ce que KIFF arrête, et ce qu'il n'arrête pas

Rendre la barrière plus difficile à contourner

L'application se renforce à mesure que la barrière devient un passage obligé. Vous choisissez le niveau que justifient votre risque et votre coût d'intégration.

Observe, consultatif uniquement, en place

La rampe d'accès. KIFF décide et enregistre chaque action mais la marque comme consultative : votre intégration tourne donc sans changement pendant que vous observez ce que le mode enforce aurait autorisé, bloqué ou retenu. Facultatif et réglé par nous à votre demande ; un espace de travail n'est jamais en mode observe par défaut. Activez le mode enforce quand les décisions vous paraissent justes.

Le guard au point de passage, en place

Les actions de votre agent passent par le guard, qui demande à KIFF de décider et retient tout ce qui n'est pas validé. La gouvernance est le chemin par défaut, pas une étape en plus. La surface de contournement qui reste, c'est votre propre code non gouverné.

Proxy en ligne, prévu

KIFF se place devant l'API de l'action et ne transmet l'appel qu'après une décision favorable : décider et exécuter deviennent un seul saut qu'un agent ne peut pas séparer. La surface de contournement se réduit à « appeler la vraie API sans le proxy », ce qu'une politique réseau peut fermer.

Barrière d'outil, prévu

Le seul chemin de l'agent vers l'action est un outil placé derrière la barrière de KIFF : le modèle ne peut donc pas produire l'effet sans passer la barrière, la barrière est la surface d'outils.

Rien ici ne prétend que KIFF empêche physiquement une action qu'il n'exécute pas lui-même. Ce qu'il empêche à la barrière, l'enregistrement qu'il laisse et la façon dont cette barrière se resserre sont énoncés ci-dessus, rien qu'une question difficile devrait pouvoir faire tomber.

Pratiques opérationnelles actuelles

Garde du portefeuille de signature

Le portefeuille qui signe les reçus et soumet les engagements sur la chaîne publique est détenu dans notre infrastructure, sous des contrôles d'accès séparés des ingénieurs applicatifs. Le code applicatif signe par une interface de service ; il ne peut pas extraire la clé. La garde des clés de signature par locataire (un portefeuille par locataire, avec une voie de migration côté locataire) est sur la feuille de route ci-dessous.

Ancrage hors bande

La tâche qui soumet les transactions d'engagement sur la chaîne publique s'exécute hors bande par rapport au chemin de décision des propositions. Une panne ou une compromission du plan applicatif ne bloque pas et ne rejoue pas les engagements déjà diffusés.

Isolation des locataires

Les données de chaque locataire se trouvent dans un schéma Postgres dédié (kiff_t_<id>), et le search_path du pool de connexions est fixé par locataire. Les requêtes entre locataires sont impossibles par architecture depuis le chemin d'exécution.

Chiffrement

TLS 1.2+ pour le trafic. Postgres est chiffré au repos avec les clés par défaut du service géré ; le chiffrement par ligne avec des clés client est sur la feuille de route ci-dessous.

Localisation des données

eu-west-1 (Irlande) : KIFF Cloud, le service tafs et planque, avec leurs bases de données, leurs sauvegardes, leurs secrets et leurs journaux.

Sous-traitants ultérieurs

Les prestataires qui traitent des données des locataires pour notre compte. La liste officielle, avec les données que chacun touche, se trouve sur /subprocessors. Nous la mettons à jour dans les 30 jours suivant toute modification.

La piste publique vérifiable n'est pas un sous-traitant ultérieur : elle ne reçoit que des empreintes de synthèse et aucune donnée personnelle.

Réponse aux incidents

Signalez un problème de sécurité présumé à security@kiff.dev. Nous visons à en accuser réception sous un jour ouvré, puis à donner une première évaluation sous cinq jours ouvrés.

Les incidents qui touchent des données de locataires déclenchent une notification écrite aux clients concernés dans les 72 heures suivant leur confirmation, puis un rapport public après incident une fois la réponse immédiate terminée. Le runbook complet est interne ; la politique de réponse ci-dessus est l'engagement pris envers les clients.

Mises à jour de sécurité

Nous fournissons des mises à jour de sécurité aussi longtemps que nous proposons le Service. KIFF Cloud, le service tafs et planque tournent sur nos serveurs : un correctif atteint donc chaque compte dès que nous le déployons, sans rien à installer de votre côté. Les apps tafs reçoivent les leurs par l'App Store et Google Play. Un problème corrigé qui a touché vos données vous est signalé comme indiqué ci-dessus.

Les données que nous traitons

Ce que KIFF Cloud reçoit, ce qu'il conserve, ce qu'il ne conserve jamais, et ce qui est détruit quand un locataire part. C'est la référence à laquelle notre implémentation doit se conformer. Chaque élément ci-dessous indique s'il est disponible aujourd'hui ou prévu.

Les identifiants que nous conservons tels quels

L'identifiant du locataire, de l'acteur et de l'entité, le nom de l'action, le libellé de la décision, les horodatages de la requête et de la réponse, les empreintes des reçus, et les empreintes des transactions de la piste publique qui fixent ces reçus. C'est l'ensemble minimal dont le framework a besoin pour rejouer l'état, et le cloud pour attribuer les enregistrements signés.

Les champs contrôlés par le locataire que nous conservons

De l'objet parameters d'une proposition, seuls les paramètres numériques (montants, quantités) sont conservés, parce que les limites les comptent. La requête complète est conservée sous forme d'empreinte, pour qu'une nouvelle tentative puisse être distinguée d'une requête différente. Les autres paramètres ne sont pas stockés. Le texte libre reasoning_summary est conservé tel qu'il a été écrit, sans nettoyage automatique. Une configuration de masquage par domaine pour ce champ, déclarative, keep / hash / drop: est prévue.

Les identifiants que nous ne conservons jamais

Les prompts bruts envoyés aux modèles et leurs réponses. Le cloud transmet le trafic d'inférence au fournisseur de modèle configuré et n'en garde aucune copie. Les locataires qui veulent les prompts sur le reçu doivent l'activer par domaine ; cette fonction n'est pas encore construite.

tafs est différent, car un taf est un agent que nous faisons tourner pour vous : ses exécutions et ses chats, avec le résumé d'un chat, sont conservés dans le stockage propre à tafs pendant 30 jours (ce que vos apps renvoient, seulement jusqu'à la fin de l'exécution ; dans un chat, ce qu'il a seulement lu est conservé pour ses messages suivants, chiffré avec la clé propre au compte, et utilisé jusqu'à ce que le chat soit resté inactif une heure, et au plus quatre heures après la lecture, puis supprimé automatiquement, sous quelques jours), et ses notes de mémoire jusqu'à ce que vous supprimiez le taf. Pour chaque appel qu'un taf fait via KIFF, tafs conserve la référence de KIFF pour l'appel et l'identifiant de ce sur quoi il a agi (par exemple un identifiant de paiement, jamais les données du client) pendant 30 jours, pour l'afficher dans le Registre du taf ; le reste des données d'entrée d'un appel n'est conservé que jusqu'à la fin de l'exécution. L'annexe 4 du DPA énumère ce que tafs conserve et pour combien de temps.

Les données que nous ne publions jamais sur la piste vérifiable

Le cloud publie sur une piste publique vérifiable une empreinte de synthèse du lot d'audit de chaque locataire, qui rend toute altération détectable. La synthèse engage les enregistrements sous-jacents sans les révéler ; les enregistrements eux-mêmes ne quittent jamais la base de données du cloud. Le salage cryptographique par locataire est actif : chaque feuille de l'arbre de synthèse est liée à un secret de 32 octets propre au locataire émetteur, si bien que deux locataires dont les enregistrements ont des octets identiques s'engagent sur des feuilles différentes, et que la piste publique ne peut pas servir d'oracle de confirmation pour des enregistrements devinés mais non vérifiés. Le sel est généré côté serveur à la création du locataire, ne quitte jamais la base de données du cloud, et est détruit quand les données d'un locataire sont supprimées.

Les données que nous supprimons à la suppression d'un locataire

Une demande de suppression d'un locataire efface son schéma Postgres, ses enregistrements d'audit, ses clés d'API et ses références de clés de signature. Les empreintes déjà publiées sur la piste publique vérifiable demeurent, parce que cette piste est immuable ; la destruction du sel du locataire rend ces empreintes publiées définitivement impossibles à reconstituer. Un attaquant hors chaîne qui ne détient que les données de la piste et un enregistrement candidat ne peut plus vérifier que ce candidat appartient au locataire supprimé, le sel qui liait l'empreinte de synthèse à l'enregistrement a disparu, et la préimage qui a produit l'empreinte ne peut plus être rejouée.

Aujourd'hui, la suppression est faite par un opérateur : les locataires qui veulent que leurs données soient effacées écrivent à privacy@kiff.dev et nous suivons notre procédure interne documentée dans le délai d'un mois de l'article 12, paragraphe 3, du RGPD. Un outil en ligne de commande (CLI) de suppression en libre-service et un écran du tableau de bord en libre-service sont sur la feuille de route ci-dessous.

Les données sur les personnes qui se connectent

Quand un utilisateur se connecte, le cloud stocke l'identifiant d'authentification fourni en amont et l'adresse e-mail utilisée pour se connecter. L'adresse e-mail est actuellement conservée en clair ; ne stocker qu'un HMAC de l'adresse et une forme d'affichage masquée est prévu. Les parcours de récupération de compte qui ont besoin de l'adresse d'origine la lisent chez le fournisseur d'identité en amont, pas dans notre base de données.

Pseudonymisé, pas anonymisé

KIFF Cloud pseudonymise les identifiants des locataires : les identifiants directs sont remplacés par des jetons opaques stables, mais les données concernent toujours une personne et les règles européennes de protection des données continuent de s'appliquer. Le produit n'anonymise pas les données d'audit, parce que le rejeu déterministe est la fonction que nous vendons. Si un locataire a besoin d'exports anonymisés pour de l'analyse, c'est une capacité distincte que nous n'avons pas construite.

Ce que KIFF garde d'un appel

Seulement ce qu'il faut pour faire appliquer une Card et l'auditer :

• Conservé : qui a demandé (l'agent et la clé), l'action, l'entité, le résultat et ses raisons, la Card en vigueur, et les paramètres numériques (montants, quantités), que les limites comptent. L'enregistrement de la décision et son reçu sont construits à partir de ces éléments.
• Réduit à une empreinte : tous les arguments d'un appel, pour qu'une nouvelle tentative puisse être distinguée d'une requête différente. Par la passerelle KIFF, aussi la valeur de l'argument sur lequel un appel agit (comme un identifiant de paiement), pour que le registre du propriétaire et le reçu puissent montrer de laquelle il s'agit à quelqu'un qui la détient.
• Écarté : les autres paramètres ne sont jamais stockés. Par la passerelle KIFF, les arguments d'un appel ne sont conservés que jusqu'à ce qu'il soit envoyé ou refusé, et le résultat de l'outil pendant 24 heures, pour qu'une nouvelle tentative reçoive la même réponse.

Ce que nous ne faisons pas aujourd'hui

• Pas de masquage automatique du texte libre reasoning_summary de l'agent : il est conservé tel qu'il a été écrit, pour que l'approbateur et l'audit voient le récit de l'agent lui-même. N'y mettez pas de données personnelles.
• Pas de hachage automatique des adresses e-mail dans la table des métadonnées d'authentification. Prévu.

Tout futur jeu de données dérivé de plusieurs locataires sera régi par un engagement distinct de minimisation des données. Dans la v0.1, aucun jeu de données dérivé n'existe.

Cette section décrit la posture du cloud en matière de traitement des données ; ce n'est ni une politique de confidentialité ni un accord de traitement des données. Les locataires de secteurs réglementés doivent s'attendre à un DPA distinct, signé, avant toute utilisation en production.