Why · the founder's view

The conviction behind KIFF, in plain language. For the technical rigor, read the whitepaper.

Why I’m building KIFF

Everyone understands a corporate card. A company gives an employee a card with a limit. The employee buys what the job needs without asking each time. The company sees every charge, can lower the limit, and can cancel the card the day it needs to. Nobody thinks that is strange, and it is how a company lets people spend its money without approving every coffee.

I’m building KIFF to give every AI agent the same thing: a Card. The Card says which actions the agent may take, how much per action and in total, and what happens when it asks for more. The agent does the work. The person who owns the money, the account or the customer keeps control, and can sleep at night.

Agents are about to act for all of us

Until now, most agents have suggested, drafted and summarized. That is changing quickly. Over the coming months, agents will refund orders, pay invoices, book travel, change subscriptions, move customer data and deploy code. Not as an experiment, but as the normal way work gets done.

When that happens, letting an agent act can’t be a luxury that only a team with its own engineers can build safely. It has to be ordinary, the way a card in a wallet is ordinary. Someone has to decide, in plain terms, how far each agent may go, and that decision has to hold every time the agent acts.

Today, the authority lives inside the agent

Ask where an agent’s limits are written down and the answer is usually: in its prompt, in a config file, in a function someone wrote last quarter, or nowhere, behind an API key that can do anything the connected service allows.

That has three problems.

Nobody responsible can read it. The person who owns the money can’t see a limit written in code, and every change to it is an engineering task.

It doesn’t travel. Each assistant and each framework has its own settings. If you use ChatGPT today, Claude tomorrow and Grok next week, your limits don’t follow you. You set them again in each place, or you don’t set them at all.

The agent holds the keys. When the credential that can move the money sits with the agent, every limit is a request the agent is asked to honour, not a line it can’t cross.

A Card lives outside the agent

KIFF keeps the authority outside the agent, and the keys out of its hands.

An agent doesn’t act by itself. It acts through its tools and skills: an MCP server that issues refunds, a plugin that changes a subscription, a skill that calls a payment API. Every one of them is a way to move money or change a record, so every one of them needs the same answer before it runs: is this agent allowed to do this, and how much is left? That answer can’t live in each tool, written again by each vendor. It has to live in one place the owner controls, and every tool has to ask it.

Through the KIFF gateway, the agent never holds the tool’s credential: KIFF does, and the agent’s own key can only ask. With kiff-guard or the decision API, the credential stays where your system already keeps it, and KIFF decides before it is used. Either way, every call is checked against the agent’s Card before it runs. Inside the Card, it goes through. Outside it, it waits for the owner or is refused. The owner answers from KIFF, raises the limit for a busy week, or revokes the Card tonight, and the agent keeps running the same code. One balance is held for each Card, so retries, parallel runs and extra copies of the agent can’t spend it twice. Every decision has a signed, tamper-evident receipt the agent can’t write.

The agent still has a part to play. The KIFF skill teaches it to propose a Card and to ask, and to stop and report when a call is held. But those instructions are not the security boundary. KIFF decides on its own servers, and the gateway enforces that decision before a governed call goes through. A prompt injection or an ignored instruction can’t give the agent authority its credential doesn’t have. There is one honest edge: KIFF governs only the calls that go through it. If the agent still holds a direct credential to the same tool, that path is outside the Card, so remove it.

You won’t run one agent. You’ll run several: one in your support desk, one in your finance tools, one in the assistant you happen to use that day. They can share one Card and draw on one balance, so ten agents can’t each spend the full amount. Every decision still names the agent that asked. However many agents hold it, the Card stays yours: you set it, you see every draw, and revoking it stops all of them at once.

Because the authority isn’t inside the agent, the agent becomes replaceable. Models change, assistants come and go, frameworks churn. The Card stays where it is.

Built for companies

KIFF is built for companies whose agents act on their own money and operations. A company issues Cards to the agents that work for it: the support agent that refunds, the finance agent that pays, the ops agent that deploys. Each has its own limits and its own record. Several agents doing one job can share a Card, the way a team shares a budget. The builders who deliver those agents to clients can build the agent once and let each client set its Card.

That is the offer today. Handing an agent authority should feel as familiar as handing an employee a card.

Where this is going

The part that excites me most is portability. Your authority should be one thing, held in one place you control, and every agent you use should ask that place before it acts. It shouldn’t matter whether the agent runs in ChatGPT, Claude, Grok, a framework your team wrote, or an assistant that doesn’t exist yet. The agent knows your limits because it asks the same Card. The keys never sit in the agent.

Some of this works today. Agents that use remote MCP tools connect to KIFF through one gateway; we have verified Claude Code and Codex. Agents in your own code connect with one hook, and any code can make one call to the decision API. Other assistants are where we are going, along with:

  • controls across many agents at once,
  • tools that accept only calls KIFF has authorized,
  • payments that follow the Card.

Those aren’t products yet, and the site says so wherever they come up.

I also think the idea reaches past companies. A person whose agent books travel or pays bills will want the same thing: limits they set, held in one place, that every assistant asks. That is a hypothesis about where this goes, not something we offer today.

The goal is plain. In a few years, giving an agent a Card should be as normal as giving an employee a corporate card, and KIFF should be the place that Card lives. I intend to build the company that makes that normal.

Why it has to be open

Something that sits between an agent and your money can’t be a black box, and it can’t be locked to one vendor. If authority is going to travel with you across every assistant, the way it’s checked has to be something anyone can read, run and build on.

So the core is open source. The framework that makes the decision is MIT-licensed: you can run it yourself and read every line that decides, including the attacks we wrote against our own approval checks, which run on every commit. The SDK, the scanner, the skills and the Claude Code plugin are open too. The hosted service adds what you’d rather not run yourself: Cards you issue and revoke from a dashboard, the owner answering held calls, one balance per Card across every run, and signed, retained receipts.

How we work

We say what is real. A Card is the final authority only where KIFF is on the only path to the capability. If an agent can still act through a browser or a credential of its own, KIFF doesn’t govern that path until it is closed, and we tell you that. The proof page was recorded on our production services, and it says what it does and doesn’t prove.

People keep the authority. The goal isn’t to remove people. It is to move them from approving every action to deciding what each agent may do and how much, and to answering what falls outside it.

Start

Businesses whose agents take consequential actions on their own money or operations can start with one action and its Card. The ten-minute quickstart →

People who build agents, for clients or for their own company, can build the agent once and let each owner set its Card. What building with KIFF includes →

If you have an agent that should be doing real work and isn’t allowed to yet, write to me at gabriel@kiff.dev. Bring one action and we’ll work out its Card together.