What KIFF is

KIFF lets your business decide what each AI agent may do, and change it without redeploying the agent.

Today the rules for an agent usually live in its prompt, its config or its code, so every change is a release. With KIFF they live on a KIFF Card the business controls: which actions the agent may take, in which states, how much, and until when. Before the agent acts, it asks KIFF. KIFF answers against the card and the current state, and your own system does the work.

What that gives the company:

Change a limit without a release. The owner raises, lowers or revokes the card; the next request uses the new terms.
Stop one agent, not all of them. Each agent holds its own cards. A card is shared with another agent only when an owner shares it on purpose, and then both draw on the same totals. Revoking a card withdraws only the authority that card granted: the agent’s next request that needed it is refused, unless another active card of that agent also covers the action. Other agents keep theirs.
Start a new model small. Give it its own card with a low limit and raise it when its statement looks right.
Keep every change on record. Each card has a statement: its limit, what was used, what is left, and every change with who made it.

Only an owner or admin can issue, change or revoke a card. The agent’s own key can only ask.

How a decision is made

KIFF puts an agent on the consequential actions you’ve kept it away from, refunds, payouts, payments, role changes, by deciding the action before it runs: whether this specific action, on this specific entity, is allowed right now. 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 before the action, 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, 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’s direct API decision path does not hold provider credentials or proxy your action. Its separate MCP gateway stores connected remote MCP bearer credentials encrypted and forwards those tool calls only after an allowed decision, unless the tool checks a permit KIFF signs instead and KIFF holds no key (Tools that check KIFF).
KIFF does not run your agent or manage your workflow.

In direct API integrations, your system stays the executor: it runs the action after allowed and withholds it otherwise. With the MCP gateway, KIFF forwards a connected tool call after allowed, and that remote tool performs the business operation. KIFF does not run your agent. In either path, only actions routed through KIFF are checked.

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 kiff-guard in observe mode, it learns which tools your agent actually calls and hands you a starter domain from real traffic (see Connect an agent). But the policy, state model, and approval rules in that domain are yours to set. KIFF never invents authority you didn’t declare.

Limits to know

What KIFF does today has edges. Know them before you build on it:

A card constrains; it never confers. It narrows what the domain and its permissions already allow and caps how much of it happens. It cannot grant an action the domain does not have, or allow one in a state the domain forbids.
A card is required only where the action says so. An action that declares requires_authority is refused with no_mandate_issued when the agent holds no card for it. Other actions on the decision API are decided without a card. Through the MCP gateway, a call that no card of the agent covers is refused.
A draw is recorded when the action is authorized, not when it runs. KIFF records the tool’s reported outcome beside the decision, but an error or a timeout does not give the draw back. Only a trusted executor’s proof that the operation had no effect releases it. See KIFF Cards.
Only calls routed through KIFF are checked. If the agent can reach the same tool directly, through a shell or a browser, that path is outside its card.
KIFF does not run the agent or the business operation. Your code, or the connected tool, performs the action after allowed.
Receipts are evidence, not a certification. They are signed, tamper-evident and verifiable. They are useful in a compliance conversation, but KIFF does not certify compliance or claim legal sufficiency for any regime.

If a page in these docs promises more than this, the page is wrong. Tell us.

The shortest path through the product

Give one agent a Card: connect a tool, issue the Card, and answer its first held call. See the quickstart.
Connect the agents you already run: through the MCP gateway, with kiff-guard in your own code, or with one call to the decision API. See Connect an agent.
Decide how you’re asked: what is held, for how long, and where you hear about it. See Held calls and approvals.
Build the domain underneath when you need it: the state and rules that let a Card say refund, only on a paid order. See Domains.

If you only read one more page, read KIFF Cards. For examples, read Cards in practice.