What KIFF Cloud signs, stores, and stands behind.

Posture

KIFF is the solution to the protocol/governance problem, not the entire business-modeling problem. The customer's business has to be expressed as governed artifacts — entities, events, states, actions, permissions, approval rules, executors, receipts. KIFF is the coordination kernel that runs against those declarations; the customer declares what to govern, and KIFF governs it.

KIFF Cloud takes custody of audit records, usage counters, and tenant data on behalf of customers running governed AI agent workflows. Audit records are append-only inside the framework and tamper-evident at the cloud layer: receipts are signed at write time under a wallet the cloud holds in custody, and a tamper-evident summary hash of each tenant's audit batch is committed to a public chain transaction so the commitment can be checked outside the cloud's own database.

Per-tenant signing-key custody — where each tenant has their own dedicated key the cloud signs under, with an optional migration path to hand a tenant the key themselves — is on the roadmap below, not in place today. Until then, the cloud is the named third party behind every signed record.

User authentication is handled by Clerk (email, social, MFA). Optional wallet linking attaches a wallet address to a user's actor identity for attribution; it is not a sign-in method.

Current operational practices

Signing-wallet custody

The wallet that signs receipts and submits the public-chain commitments is held in our infrastructure under access controls separate from application engineers. The application code path signs through a service interface; it cannot extract the key. Per-tenant signing-key custody (one wallet per tenant, with a tenant-side migration path) is on the roadmap below.

Anchoring out-of-band

The job that submits the public-chain commitment transactions runs out-of-band from the proposal-decide path. A failure or compromise of the application plane does not block or replay commitments that have already been broadcast.

Tenant isolation

Each tenant's data lives in a dedicated Postgres schema (kiff_t_<id>) with the connection pool's search_path pinned per tenant. Cross-tenant queries are architecturally impossible from the runtime path.

Encryption

TLS 1.2+ for traffic. Postgres at rest encrypted via the managed provider's default keys; per-row customer encryption is on the roadmap below.

Data location

us-east-1 at v0.1. Multi-region and EU residency are roadmap items.

Sub-processors

Vendors that process tenant data on our behalf. We update this list within 30 days of any change.

Incident response

Report a suspected security issue to security@kiff.dev. We aim to acknowledge within one business day and follow up with an initial assessment within five.

Incidents that affect tenant data trigger a written notification to affected customers within 72 hours of confirmation, with a public post-incident report once the immediate response is closed. The full runbook is internal; the response policy above is the customer-facing contract.

Data we process

What KIFF Cloud receives, what it persists, what it never persists, and what is destroyed when a tenant leaves. This is the source of truth our implementation is required to match. Items marked planned name whether each item is available today or planned.

Identifiers we keep verbatim

Tenant id, actor id, entity id, action name, decision label, request and response timestamps, receipt hashes, and the public-trail transaction hashes that pin those receipts. These are the minimum set the framework needs to replay state and the cloud needs to attribute signed records.

Tenant-controlled fields we persist

The parameters object and free-text reason strings that arrive on every proposal. Stored as the tenant sent them. Today we apply no automatic scrubbing; the tenant is responsible for what reaches the wire. Per-domain redaction config — declarative keep / hash / drop per parameter — is planned.

Identifiers we never persist

Raw model prompts and completions. The cloud forwards inference traffic to the configured model provider and keeps no copy. Tenants who want prompts on the receipt must opt in per domain; that surface is not yet built.

Data we never publish to the verifiable trail

The cloud publishes a tamper-evident summary hash of each tenant's audit batch to a public verifiable trail. The summary commits to the underlying records without revealing them; the records themselves never leave the cloud's database. Per-tenant cryptographic salting is active: every leaf in the summary tree is bound to a 32-byte secret unique to the issuing tenant, so two tenants with identical record bytes commit to different leaves and the public trail cannot be used as a confirmation oracle for guessed-but-unverified records. The salt is generated server-side at tenant creation, never leaves the cloud's database, and is destroyed when a tenant's data is deleted.

Data we delete on tenant deletion

A tenant deletion request scrubs the tenant's Postgres schema, audit records, API keys, and signing-key references. Hashes already published to the public verifiable trail remain because that trail is immutable; destroying the per-tenant salt makes those published hashes permanently unreconstructable. An off-chain attacker holding only the trail's data and a candidate record can no longer verify the candidate belongs to the deleted tenant — the salt that bound the summary hash to the record is gone, and the pre-image that produced the hash can no longer be replayed.

Today, deletion is operator-driven: tenants who want their data scrubbed email privacy@kiff.dev and we follow our documented internal procedure within the GDPR Article 12(3) one-month window. A self-serve deletion CLI and a self-serve dashboard surface are roadmap items below.

Data about the people who sign in

When a user signs in, the cloud stores the upstream authentication subject and the email address used to sign in. Email is currently held in plaintext; storing only an HMAC of the email plus a redacted display form is planned. Account recovery flows that need the original email read it from the upstream identity provider, not from our database.

Pseudonymized, not anonymized

KIFF Cloud pseudonymizes tenant identifiers: direct identifiers are replaced with stable opaque tokens, but the data is still about a person and EU data-protection rules continue to apply. The product does not anonymize audit data, because deterministic replay is the feature we sell. If a tenant needs anonymized exports for analytics, that is a separate capability we have not built.

What we do not do today

• No automatic redaction of parameters or reason fields. Planned.
• No automatic email hashing in the auth metadata table. Planned.
• No data-residency option outside us-east-1. Listed under "What we don't yet have" below.

Any future cross-tenant derived datasets will be governed by a separate data-minimization commitment. As of v0.1 no derived dataset exists.

This section describes the cloud's data-handling posture; it is not a privacy policy or a Data Processing Agreement. Tenants in regulated industries should expect a separate signed DPA before production use.