What KIFF is

KIFF lets you put an agent on the consequential actions you’ve kept it away from — refunds, payouts, payments, role changes — the work that moves money or can’t be cleanly undone. It does that by putting a boundary around the action: KIFF decides whether this specific action, on this specific entity, is allowed right now — before it runs — so the useful action goes through, the out-of-policy one is refused, and the duplicate can’t fire twice.

The thing you build once is a reusable operational domain — the state, valid actions, authority, approvals, and evidence your agents share. This page is about the mechanism that makes the actions against it safe to hand over.

What this does

KIFF sits in front of an action and answers one question: is this specific action, on this specific entity, allowed right now, given the entity’s state and your policy? The answer is one of four outcomes — allowed, blocked, approval_required, or invalid — and it is produced before the action executes, not after.

The refund runs when the order is in a state that permits it. The same refund is refused once the order is already refunded. A high-value one waits for a human. You get to say yes to the agent doing real work because the cases you were afraid of are handled by the boundary, not by hoping the model behaves.

Every answer leaves a record: a signed receipt of what was decided, on what basis, at that moment — support for the claim, not the headline.

What KIFF is not

KIFF is the decision boundary, not the runner. This distinction is load-bearing, so it’s worth being blunt about it:

KIFF does not execute your action. It does not move the money, send the email, or write to your database.
KIFF does not hold your credentials or proxy your API calls.
KIFF does not run your agent or manage your workflow.

Your system stays the executor. KIFF returns a decision; your code, having asked, then runs the action when the decision is allowed and withholds it when it isn’t. This is the same cooperative model every policy engine uses — the value is that the useful action can finally run unattended, with a provable record, not physical interception.

What you own vs what KIFF decides

A clean way to hold the split:

You own:

the policy — which actions need approval, what the thresholds are, who may authorize what;
the state — what counts as the current state of an entity (an invoice is PENDING or PAID, a refund is REQUESTED);
the thresholds and approval rules;
execution — your runtime runs the action when KIFF says allowed.

KIFF decides:

whether a proposed action is permitted against that state and policy, before it runs;
and produces the receipt that proves what was decided.

KIFF derives the observed action surface for you — when you attach the guard in observe mode, it learns which tools your agent actually calls and hands you a starter domain from real traffic (see Connect an existing agent). But the policy, state model, and approval rules in that domain are yours to set. KIFF never invents authority you didn’t declare.

The shortest path through the product

Ship one governed action — scaffold a runnable refund domain and watch the boundary let the good refund run, hold the risky one, and refuse the duplicate. See the quickstart.
Connect the agent you already have — attach the guard in observe mode, learn its action surface, and derive a starter domain from real traffic. See Connect an existing agent.
Activate a domain — start with the one action you’d least like taken unsupervised. See Domains and Protected Controls.
Inspect the evidence — the receipts and the Govern view, exportable as a proof pack.

If you only read one more page, read Domains — the reusable operational domain is what everything else is built on.