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, and no two agents share one. 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 are untouched.
  • 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.
  • 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.

The shortest path through the product

  1. Give one agent a Card: connect a tool, issue the Card, and answer its first held call. See the quickstart.
  2. 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.
  3. Decide how you’re asked: what is held, for how long, and where you hear about it. See Held calls and approvals.
  4. 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.