Lo que KIFF Cloud firma, almacena y respalda.

Postura

KIFF es la solución al problema del protocolo y la gobernanza, no a todo el problema de modelar el negocio. El negocio del cliente tiene que expresarse como artefactos gobernados: entidades, eventos, estados, acciones, permisos, reglas de aprobación, ejecutores, recibos. KIFF es el núcleo de coordinación que se ejecuta sobre esas declaraciones; el cliente declara qué gobernar, y KIFF lo gobierna.

KIFF Cloud custodia los registros de auditoría, los contadores de uso y los datos de los inquilinos en nombre de los clientes que ejecutan flujos de trabajo gobernados de agentes de IA. Los registros de auditoría son de solo adición dentro del framework y tienen evidencia de manipulación en la capa de la nube: los recibos se firman en el momento de escribirse con una billetera que la nube custodia, y un hash de resumen con evidencia de manipulación del lote de auditoría de cada inquilino se consigna en una transacción de una cadena pública, de modo que ese compromiso puede comprobarse fuera de la propia base de datos de la nube.

La custodia de claves de firma por inquilino (en la que cada inquilino tiene su propia clave dedicada con la que firma la nube, con una vía de migración opcional para entregarle la clave al propio inquilino) está en la hoja de ruta de abajo, no en vigor hoy. Hasta entonces, la nube es el tercero identificado que está detrás de cada registro firmado.

La autenticación de usuarios la gestiona Clerk (correo, cuentas sociales, MFA). La vinculación opcional de una billetera asocia una dirección de billetera a la identidad de actor de un usuario para la atribución; no es un método de inicio de sesión.

Lo que KIFF hace cumplir

Dicho claramente: KIFF devuelve una decisión; tu integración ejecuta el efecto secundario. KIFF es el punto de control, no quien ejecuta. Es la misma postura que la de cualquier motor de políticas (una biblioteca de permisos, un servidor de políticas, una API antifraude o de moderación): devuelven un veredicto y el sistema que llama lo respeta. La fuerza es real, y esta sección dice exactamente dónde está.

A través del punto de control, KIFF impide la acción. Cuando la acción de un agente pasa por el guard, cualquier resultado que no sea allowed impide la ejecución: ese impedimento es el contrato a prueba de fallos del guard. Y cada acción con consecuencias se decide según tu política declarada y el estado de la entidad, y se registra como un recibo con evidencia de manipulación, antes de ejecutarse. El producto es esa decisión y ese registro demostrable, no la pretensión de interceptar físicamente rutas de código que no ejecutamos.

El carácter vinculante de las decisiones es un ajuste que tú controlas, por espacio de trabajo, y es estricto por defecto. Ejecutas un control en modo enforce (el predeterminado: cada decisión es vinculante y se aplica el impedimento de arriba) o en modo observe (solo consultivo: KIFF decide y registra exactamente igual, pero marca la decisión como consultiva para que tu integración siga funcionando mientras ves qué habría detenido el modo enforce). El modo observe es opcional y lo activamos nosotros a petición tuya, nunca el agente y nunca por defecto: un espacio de trabajo nunca está en solo observación por accidente. Es la rampa de entrada: ve las decisiones del punto de control frente al tráfico real y después activa enforce.

Lo que KIFF detiene y lo que no

Hacer que el punto de control sea más difícil de esquivar

El control se refuerza cuanto más ceñido al recorrido colocas el punto de control. Tú eliges el nivel que justifican tu riesgo y tu coste de integración.

Observe, solo consultivo, en vigor

La rampa de entrada. KIFF decide y registra cada acción, pero la marca como consultiva, así que tu integración funciona sin cambios mientras ves qué habría permitido, denegado o retenido el modo enforce. Es opcional y lo activamos nosotros a petición tuya; un espacio de trabajo nunca está en solo observación por defecto. Activa enforce cuando las decisiones te parezcan correctas.

El guard en el punto de unión, en vigor

Las acciones de tu agente pasan por el guard, que pide a KIFF que decida e impide todo lo que no esté autorizado. La gobernanza es el camino por defecto, no un paso extra. La superficie de evasión que queda es tu propio código no gobernado.

Proxy en línea, previsto

KIFF se sitúa delante de la API de la acción y reenvía la llamada solo después de una decisión que la autoriza, de modo que decidir y ejecutar se convierten en un único salto que un agente no puede separar. La superficie de evasión se reduce a «llamar a la API real sin el proxy», algo que la política de red puede cerrar.

Punto de control en la herramienta, previsto

La única vía del agente hacia la acción es una herramienta que pasa por el control de KIFF, así que el modelo no puede producir el efecto secundario sin pasar por el punto de control: el punto de control es la propia superficie de herramientas.

Nada de lo que hay aquí afirma que KIFF impida físicamente una acción que no ejecuta él mismo. Lo que impide a través del punto de control, el registro que deja y cómo se ajusta ese punto de control están dichos arriba: nada que una pregunta difícil debiera poder romper.

Prácticas operativas actuales

Custodia de la billetera de firma

La billetera que firma los recibos y envía los compromisos a la cadena pública se guarda en nuestra infraestructura bajo controles de acceso separados de los ingenieros de la aplicación. La ruta de código de la aplicación firma a través de una interfaz de servicio; no puede extraer la clave. La custodia de claves de firma por inquilino (una billetera por inquilino, con una vía de migración del lado del inquilino) está en la hoja de ruta de abajo.

Anclaje fuera de banda

El trabajo que envía las transacciones de compromiso a la cadena pública se ejecuta fuera de banda respecto de la ruta que decide las propuestas. Un fallo o una vulneración del plano de la aplicación no bloquea ni repite los compromisos que ya se han difundido.

Aislamiento entre inquilinos

Los datos de cada inquilino viven en un esquema de Postgres dedicado (kiff_t_<id>), con el search_path del grupo de conexiones fijado por inquilino. Las consultas entre inquilinos son imposibles por arquitectura desde la ruta de ejecución.

Cifrado

TLS 1.2+ para el tráfico. Postgres está cifrado en reposo con las claves por defecto del proveedor gestionado; el cifrado por fila con claves del cliente está en la hoja de ruta de abajo.

Ubicación de los datos

eu-west-1 (Irlanda): KIFF Cloud, el servicio de tafs y planque, con sus bases de datos, copias de seguridad, secretos y logs.

Subencargados del tratamiento

Proveedores que tratan datos de los inquilinos en nuestro nombre. La lista oficial, con los datos que toca cada uno, está en /es/subprocessors. La actualizamos en un plazo de 30 días desde cualquier cambio.

El rastro público verificable no es un subencargado del tratamiento: solo recibe hashes de resumen y ningún dato personal.

Respuesta a incidentes

Informa de un posible problema de seguridad a security@kiff.dev. Nuestro objetivo es acusar recibo en un día hábil y dar seguimiento con una evaluación inicial en cinco.

Los incidentes que afectan a datos de los inquilinos dan lugar a una notificación por escrito a los clientes afectados en un plazo de 72 horas desde su confirmación, con un informe público posterior al incidente una vez cerrada la respuesta inmediata. El procedimiento completo es interno; la política de respuesta de arriba es el compromiso de cara al cliente.

Actualizaciones de seguridad

Ofrecemos actualizaciones de seguridad mientras ofrezcamos el Servicio. KIFF Cloud, el servicio de tafs y planque se ejecutan en nuestros servidores, así que una corrección llega a todas las cuentas cuando la desplegamos, sin que tengas que instalar nada. Las apps de tafs reciben las suyas a través del App Store y de Google Play. Un problema corregido que haya afectado a tus datos se te comunica como se indica arriba.

Datos que tratamos

Qué recibe KIFF Cloud, qué guarda, qué nunca guarda y qué se destruye cuando un inquilino se va. Esta es la referencia única a la que nuestra implementación está obligada a ajustarse. Cada punto de abajo indica si está disponible hoy o previsto.

Identificadores que guardamos tal cual

El identificador del inquilino, el del actor, el de la entidad, el nombre de la acción, la etiqueta de la decisión, las marcas de tiempo de la solicitud y de la respuesta, los hashes de los recibos y los hashes de las transacciones del rastro público que fijan esos recibos. Son el conjunto mínimo que el framework necesita para reproducir el estado y que la nube necesita para atribuir los registros firmados.

Campos controlados por el inquilino que guardamos

Del objeto parameters de una propuesta solo se guardan los parámetros numéricos (importes, recuentos), porque los límites los cuentan. La solicitud completa se guarda como un hash, para poder distinguir un reintento de una solicitud distinta. Los demás parámetros no se almacenan. El texto libre de reasoning_summary se guarda tal como se escribió, sin limpieza automática. Está prevista una configuración de ocultación por dominio para ese campo, declarativa: keep / hash / drop.

Identificadores que nunca guardamos

Los prompts y las respuestas del modelo en bruto. La nube reenvía el tráfico de inferencia al proveedor de modelos configurado y no guarda ninguna copia. Los inquilinos que quieran los prompts en el recibo deben activarlo expresamente por dominio; esa función aún no está construida.

tafs es distinto, porque un taf es un agente que ejecutamos para ti: sus ejecuciones y sus chats, con el resumen de cada chat, se guardan en el almacén propio de tafs durante 30 días (lo que devuelven tus apps, solo hasta que termina la ejecución; en un chat, lo que solo leyó se guarda para sus siguientes mensajes, cifrado con la clave propia de la cuenta, y se usa hasta que el chat lleva una hora inactivo y como máximo cuatro horas después de la lectura, y luego se borra automáticamente, en unos pocos días), y sus notas de memoria hasta que eliminas el taf. Por cada llamada que un taf hace a través de KIFF, tafs guarda la referencia de KIFF de la llamada y el identificador de aquello sobre lo que actuó (por ejemplo, el identificador de un pago, nunca los datos del cliente) durante 30 días, para mostrarlo en el Registro del taf; el resto de los datos de entrada de una llamada se guarda solo hasta que termina la ejecución. El anexo 4 del DPA enumera qué guarda tafs y durante cuánto tiempo.

Datos que nunca publicamos en el rastro verificable

La nube publica un hash de resumen con evidencia de manipulación del lote de auditoría de cada inquilino en un rastro público verificable. El resumen se compromete con los registros subyacentes sin revelarlos; los registros en sí nunca salen de la base de datos de la nube. El salado criptográfico por inquilino está activo: cada hoja del árbol de resumen está ligada a un secreto de 32 bytes único del inquilino emisor, de modo que dos inquilinos con registros idénticos byte a byte se comprometen con hojas distintas, y el rastro público no puede usarse como oráculo de confirmación para registros adivinados pero no verificados. La sal se genera en el servidor al crear el inquilino, nunca sale de la base de datos de la nube y se destruye cuando se eliminan los datos de un inquilino.

Datos que borramos al eliminar un inquilino

Una solicitud de eliminación de un inquilino borra su esquema de Postgres, sus registros de auditoría, sus claves de API y las referencias a sus claves de firma. Los hashes ya publicados en el rastro público verificable permanecen porque ese rastro es inmutable; al destruir la sal del inquilino, esos hashes publicados quedan permanentemente imposibles de reconstruir. Un atacante fuera de la cadena que solo tenga los datos del rastro y un registro candidato ya no puede verificar que el candidato pertenece al inquilino eliminado: la sal que ligaba el hash de resumen al registro ya no existe, y la preimagen que produjo el hash ya no puede reproducirse.

Hoy, la eliminación la hace un operador: los inquilinos que quieren que se borren sus datos escriben a privacy@kiff.dev y seguimos nuestro procedimiento interno documentado dentro del plazo de un mes del artículo 12, apartado 3, del RGPD. Una CLI de eliminación en autoservicio y una pantalla de autoservicio en el panel son puntos de la hoja de ruta de abajo.

Datos sobre las personas que inician sesión

Cuando un usuario inicia sesión, la nube almacena el sujeto de autenticación del proveedor de origen y la dirección de correo usada para iniciar sesión. El correo se guarda actualmente en texto claro; está previsto almacenar solo un HMAC del correo más una forma de visualización parcialmente oculta. Los flujos de recuperación de cuenta que necesitan el correo original lo leen del proveedor de identidad de origen, no de nuestra base de datos.

Seudonimizados, no anonimizados

KIFF Cloud seudonimiza los identificadores de los inquilinos: los identificadores directos se sustituyen por tokens opacos estables, pero los datos siguen refiriéndose a una persona y las normas de protección de datos de la UE siguen aplicándose. El producto no anonimiza los datos de auditoría, porque la reproducción determinista es la función que vendemos. Si un inquilino necesita exportaciones anonimizadas para analítica, esa es una capacidad aparte que no hemos construido.

Lo que KIFF guarda de una llamada

Solo lo que hace falta para hacer cumplir una Card y auditarla:

• Se guarda: quién lo pidió (agente y clave), la acción, la entidad, el resultado y sus motivos, la Card vigente y los parámetros numéricos (importes, recuentos), que los límites cuentan. El registro de la decisión y su recibo se construyen a partir de esto.
• Se guarda como hash: los argumentos completos de una llamada, para poder distinguir un reintento de una solicitud distinta. A través de la pasarela de KIFF, también el valor del argumento sobre el que actúa una llamada (como el identificador de un pago), para que el registro del propietario y el recibo puedan indicar de cuál se trata a quien ya conozca ese valor.
• Se descarta: los demás parámetros nunca se almacenan. A través de la pasarela de KIFF, los argumentos de una llamada se guardan solo hasta que se envía o se rechaza, y el resultado de la herramienta durante 24 horas, para que un reintento reciba la misma respuesta.

Lo que no hacemos hoy

• No hay ocultación automática del texto libre reasoning_summary del agente: se guarda tal como se escribió, para que quien aprueba y la auditoría vean el relato del propio agente. No pongas datos personales en él.
• No hay hash automático del correo en la tabla de metadatos de autenticación. Previsto.

Cualquier futuro conjunto de datos derivado entre inquilinos se regirá por un compromiso de minimización de datos aparte. En la v0.1 no existe ningún conjunto de datos derivado.

Esta sección describe la postura de la nube en el manejo de datos; no es una política de privacidad ni un acuerdo de tratamiento de datos (DPA). Los inquilinos de sectores regulados deberían contar con un DPA firmado aparte antes del uso en producción.