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.

What KIFF enforces

Plainly: KIFF returns a decision; your integration runs the side effect. KIFF is the gate, not the runner. That is the same posture as every policy engine — a permissions library, a policy server, a fraud or moderation API: they return a verdict and the calling system honors it. The teeth are real, and this section says exactly where they are.

Through the gate, KIFF blocks. When an agent's action flows through the guard, any outcome that is not allowed withholds execution — that withhold is the guard's fail-safe contract. And every consequential action is decided against your declared policy and the entity's state, and recorded as a tamper-evident receipt, before it runs. The product is that decision boundary and that provable record — not a claim to physically intercept code paths we don't run.

Enforcement is a setting you control, per workspace, and it is strict by default. You run a control in enforce (the default — every decision is binding, the withhold above applies) or shadow (observe-only — KIFF decides and records exactly the same way, but marks the decision advisory so your integration keeps running while you watch what enforcing would have stopped). Shadow is opt-in and set by us at your request, never by the agent and never the default — a workspace is never observe-only by accident. It is the on-ramp: see the gate's calls against real traffic, then turn on enforce.

What KIFF stops, and what it does not

Making the gate harder to bypass

Enforcement gets stronger as you give the gate a tighter place in the path. You pick the level your risk and integration cost justify.

Shadow — observe-only, in place

The on-ramp. KIFF decides and records every action but marks it advisory, so your integration runs unchanged while you watch what enforcing would have allowed, blocked, or held. Opt-in and set by us at your request; a workspace is never observe-only by default. Turn on enforce when the calls look right.

Guard at the seam — in place

Your agent's actions call through the guard, which asks KIFF to decide and withholds anything not cleared. Governance is the default path, not an extra step. The remaining bypass surface is your own non-governed code.

Inline proxy — planned

KIFF sits in front of the action's API and forwards the call only after a clearing decision, so deciding and executing become one hop an agent can't split. Bypass surface narrows to "call the real API without the proxy," which network policy can close.

Tool gate — planned

The agent's only route to the action is a KIFF-gated tool, so the model cannot emit the side effect without passing the gate — the gate is the tool surface.

No surface here claims KIFF physically prevents an action it does not itself execute. What it prevents through the gate, the record it leaves, and how that gate tightens are stated above — nothing that a hard question should be able to break.

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.