An agent should carry its authority,
the way an employee carries a badge.
In most workplaces, a badge decides which doors open, and each door records who came through. Most agents have no equivalent. They run on a key that can do whatever the connected system allows. This page explains how KIFF gives an agent defined authority, why that is harder to get right than it looks, and what building with KIFF includes.
A badge explains most of it. An agent needs one more thing.
- Opens only the doors it was issued for
- Only at the times it allows
- Is issued by someone, and can be taken back at once
- Leaves a record at every door
- A limit on how much, not only where: €5,000 of refunds a day, or 40 plan changes
- One balance, drawn down by every use, wherever the agent runs
- A statement the owner can read, not only a door log
A badge with a balance is what KIFF calls a card. The card names one agent, the actions it may take, the conditions they are allowed in, and the limit over a window. KIFF checks each proposed action against it before the owner’s system runs it.
What the owner sees, one decision at a time.
Take one example: a business lets an agent refund paid orders, up to €5,000 a day. Step through five moments and watch the card and its record change.
You issue the refunds agent its card.
REFUND_ORDER, only when the order is PAID, up to €5,000 per calendar day.
REFUND_ORDERPAID- card issued · €5,000/day · by ops lead
The agent proposes a €4,000 refund on a paid order.
Within the conditions and the ceiling. KIFF authorizes and draws €4,000; your system runs the refund.
REFUND_ORDERPAID- card issued · €5,000/day · by ops lead
- REFUND_ORDER €4,000 · ord_8812 · authorized
The agent proposes a further €1,500 refund.
The order may be eligible, but €1,500 exceeds the €1,000 left today. Refused, nothing drawn.
REFUND_ORDERPAID- card issued · €5,000/day · by ops lead
- REFUND_ORDER €4,000 · ord_8812 · authorized
- REFUND_ORDER €1,500 · ord_9120 · refused, ceiling
You revoke the card.
One action from the owner. No redeploy, no call to the builder.
REFUND_ORDERPAID- card issued · €5,000/day · by ops lead
- REFUND_ORDER €4,000 · ord_8812 · authorized
- REFUND_ORDER €1,500 · ord_9120 · refused, ceiling
- card revoked · by ops lead
The agent is told to try €200 anyway.
New instructions do not restore authority. The proposal is refused.
REFUND_ORDERPAID- card issued · €5,000/day · by ops lead
- REFUND_ORDER €4,000 · ord_8812 · authorized
- REFUND_ORDER €1,500 · ord_9120 · refused, ceiling
- card revoked · by ops lead
- REFUND_ORDER €200 · ord_9377 · refused, revoked
Illustrative decisions, not a customer run. KIFF authorizes; the owner’s system executes. Confirm completed refunds in that system.
A limit is quick to write. Keeping it correct is the hard part.
This is the limit most of us would write first, or get from a coding agent. It works in a demo. Each tab below is an ordinary production event: see how this version behaves, and how KIFF behaves.
LIMIT = 5000 # per day
spent_today = load_spent()
def refund(order, amount):
if spent_today + amount <= LIMIT:
save_spent(spent_today + amount)
payments.refund(order, amount)Two runs refund €800 in the same second, with €1,000 left.
Both read €1,000 left. Both pass. €1,600 goes out.
Draws on a card are locked. The second sees €200 left and is refused.
The payment call times out and the framework retries the same refund.
The retry is counted again. The limit is reached by money that moved once.
The draw is keyed to the proposal. The retry counts once.
The agent is redeployed at noon, or scaled to three workers.
Each process keeps its own count, or starts from zero. The limit multiplies.
One balance per card, held centrally across every run, process and machine.
The store holding the balance does not answer.
The error becomes zero spent. The agent has a full limit.
An unreadable balance refuses. It shows as unknown, never zero.
The agent is told a VIP customer needs more room today.
The limit sits in config the agent’s deployment can change.
The agent’s key cannot change its card. A ceiling change takes the owner’s management key.
The owner asks what happened on Tuesday.
Application logs, written by the same system that acted.
A signed, tamper-evident record of every authorization and refusal.
The left column is a typical first version, not any particular team’s code. Each right-hand answer describes how KIFF behaves today: draws locked per card across replicas, keyed to the proposal so a retry counts once, refused when the balance cannot be read, ceilings changed only with a management key.
Four phases, from one card to a running operation.
Each phase builds on the one before. You start with a single workflow; the later phases apply once it is live and operating.
- 01 · integrate
The first card
The domain, the card and the check before the tool call, on one real workflow.
- 02 · prove
Control testing
Evaluations ask whether the agent chose well. Control testing asks whether the operation respected the owner’s authority, under concurrency, retries, restarts, outages and revocation.
- 03 · hand over
The Card Handover Package
Authority, coverage, test results, emergency procedures and the owner’s acceptance. Generated from the card and linked to its evidence, not written as a document.
- 04 · operate
Operations views
The owner sees every agent, its authority and yesterday’s decisions, and can suspend one. You see the technical health of everything you have built, in one place.
What the owner reads at handover.
- Authority actions, conditions, ceiling, expiry, owner
- Coverage the protected actions, and the bypasses you declared
- Tests limits, retries, concurrency and revocation, with receipts
- Emergency how to suspend, investigate and recover
- Acceptance the named owner acknowledges the boundaries
A passing control test shows the protected path holds under those conditions. It does not prove the whole workflow is safe, or that no other path exists.
| 08:00 | card issued · €5,000 per day | by ops lead | |
| 09:12 | ord_8812 · order PAID | authorized | −€4,000 |
| 11:40 | ord_9120 · €1,500 | refused · ceiling | €0 |
Where the check goes in your code.
Keep your stack: Agno, LangGraph, the OpenAI Agents SDK, n8n or your own code. Wrap the function that performs the action; run it only when KIFF authorizes.
A card narrows authority the domain already allows; it grants nothing on its own. Actions that bypass the check need their own controls.
Read the integration guide →# No adapter needed. Wrap the one function that moves money.
def issue_refund(order, amount):
d = kiff.decide("REFUND_ORDER", entity=order, amount=amount)
if not d.allowed:
return d # blocked or held, never execute
payments.refund(order, amount) # your code, unchangedStart with one workflow.
Choose an action you would like an agent to take on its own but cannot yet, usually because nobody has agreed its limits.
Start with a conversation, not a commitment. We look at the action, the execution path and what the owner needs to see. Any implementation scope, price and duration is agreed before work begins.
Or email Gabriel at gabriel@kiff.dev. Share only the details you are comfortable sending.
Name the action and its owner.
One real workflow, and the person who decides what the agent may do.
Integrate and prove it.
The card, the check before the call, and control tests on that path.
Hand it over, then operate.
The owner accepts the boundaries; the operations views follow once it is live.