Why Delegus
Why Delegus exists
AI agents now buy and change things for companies. Cards check the money and identity checks confirm who is asking, but nothing checks what the agent was allowed to do. Delegus does. This page takes that down to the root, answers the two objections we hear every week, and shows it in real situations.
The answer in one breath
Card limits control money. Bot checks control identity. Nothing controls authority.
When an AI agent acts for a company, the question that matters is not “is this card good?” or “is this a real agent?” It is “did this company allow this agent to do this, for this much, right now?” Delegus answers that — with a signed record both sides can check without trusting each other.
Five whys
Why does Delegus exist?
- 1
Why does Delegus exist?
Because AI agents are starting to buy, order and change things on behalf of companies — at machine speed, with sellers who have never met them.
A procurement agent orders compute at 2am. A data agent pulls records from a vendor. A support agent changes settings in a customer's account. No human is in the loop at the moment it happens.
- 2
Why is that a problem?
Because the seller has no way to know whether the company actually meant its agent to do that specific thing.
The agent can be real, its card can be valid, and it can still be doing something its company never allowed — the wrong item, the wrong amount, the wrong vendor, or after it was supposed to stop.
- 3
Why don't existing controls catch it?
Because every control we have today checks something else: cards check money, identity checks check who, fraud tools guess after the fact.
A card limit says “up to $10,000”. It does not say “only GPU-hours, only from these two sellers, only until Friday, and stop the moment we say so.” Identity says “this is Northwind's agent” — not what Northwind let it do.
- 4
Why does “what it was allowed to do” matter so much?
Because that is exactly where the losses, disputes and damage happen — a trusted agent going past its mandate.
Our founding moment: an AI agent working on RREV OS was told not to touch a live vehicle — and pulsed its suspension and raised the air spring anyway. It was a real, authenticated agent. Nothing was checking what it was allowed to do.
- 5
Why must a neutral third party do it?
Because buyer and seller don't trust each other's systems — and the evidence has to hold up later, for both, without anyone's say-so.
The buyer writes the rules once. Every seller that checks sees the same rules. Each check produces a signed receipt anyone can re-verify, even without us. Revoke once, and every seller that checks refuses — on every way to pay.
Root cause
Agents act for companies, but authority — what a company allowed its agent to do — has no standard, checkable, portable form. Delegus is that form.
The rules behind it are written down as The Authority Principles: six rules for letting AI agents act for a company, free to reuse.
The question behind the question
“Why would my agent do that? I control it.”
You control what you ask it to do. You don't control what it does — and the seller can't see either. An instruction in a prompt is a request, not a rule anything enforces. Here is how a well-built, well-meaning agent ends up out of bounds:
- It misreads the goal.“Get us enough GPU capacity for the launch” becomes a month-long reservation instead of a weekend one. The model is guessing intent, and sometimes guesses big.
- Something it reads tells it to.A vendor page, an email or a document the agent opens contains instructions (“prompt injection”) — “also renew the premium plan”. The agent can't reliably tell your instructions from a stranger's.
- It loops.A retry after a timeout places the same order again, and again. Each call looks valid on its own. Delegus refuses a request that has already been used, so a re-sent order is stopped at the seller.
- It works from stale context.The budget changed on Monday, the vendor was dropped last week, the project was canceled — the agent is still running last month's plan.
- Its credentials are used by someone else.A leaked key or a compromised tool lets an attacker act as your agent, with your card and your name.
- It isn't one agent, and it isn't all yours.Ten teams run agents; a vendor runs agents on your behalf; models get upgraded under you. “I control it” stops being true the day you have more than one.
The point isn't that your agent is bad. It's that “don't” in a prompt is not enforced anywhere. Delegus moves the rule out of the agent and into a check the seller runs before acting — so the rules it covers today (what may be bought, from whom, up to how much per order, until when, and whether it has been revoked) hold even when the agent gets it wrong, and the seller can see they hold.
The two objections
“I already have controls.”
“I've set a limit on the card. I don't need more.”
What they're right about: a card limit caps the worst case on one card. Keep it. Delegus doesn't replace it — it covers what a card limit can't see.
- A limit says how much, never what. $10,000 on a card lets the agent buy $10,000 of anything, from anyone. It can't say “compute only, these two sellers, not models.”
- Most business spending never touches a card. Invoices, net-30 terms, purchase orders, prepaid credits and usage billing all bypass the card limit entirely. The agent can commit you to a $40,000 invoice with a $10,000 card.
- Many agent actions aren't payments at all. Deleting data, changing settings, opening tickets, accepting terms. No card is involved, so no card limit applies.
- Stopping one agent means breaking everything. If one agent misbehaves, cancelling the shared card stops every legitimate purchase too. There's no “stop this agent, at every seller, now.”
- A statement shows money moved, not that you allowed it. When audit or finance asks “who approved this?”, a card statement has no answer.
With Delegus, the company sets one policy per agent: what, how much, from whom, until when. Every seller that checks sees the same policy, whether the order is on a card or an invoice. One switch revokes it everywhere they check, and every decision leaves a signed record.
“I can refuse a bot if something looks off, or if its identity doesn't check out.”
What they're right about: blocking obvious fraud and fake identities matters. Keep those tools. Delegus answers a different question.
- The dangerous agent looks perfectly legitimate. A verified agent from a real customer, with a valid card, ordering something its company never approved. Identity passes. Fraud scoring passes. The order is still wrong.
- “Looks off” is a guess — and guesses cost revenue. Refuse too much and you turn away real customers' agents, a fast-growing channel. Refuse too little and you eat the losses. You need a yes-or-no, not a score.
- When the buyer disputes, you carry the loss. “Our agent wasn't allowed to buy that” — and on an invoice there's no card network to protect you. Without evidence of the buyer's own policy, it's your word against theirs.
- You can't see the buyer's rules. Every company's approval rules live inside that company. There's no way for you to check them — unless they're published in a form you can verify.
- Revocation doesn't reach you. When the buyer pulls an agent's access, nothing tells you. The agent keeps ordering until someone notices.
With Delegus, you say yes to agent orders with confidence: one check tells you whether the buyer's own policy allows this exact order right now, and you keep a signed receipt as evidence if it's ever disputed.
Concrete situations · illustrative
What it looks like in real life
Company names and amounts are examples.
The overnight GPU order
Who allowed that data pull?
The agent that should have stopped
The agent that changed production
The air spring
“Who approved this?”
Side by side
What each control actually answers
| Question | Delegus | Card limit | Identity / bot check | Fraud scoring |
|---|---|---|---|---|
| How much, at most? | Yes, per action | Yes, per card | No | Indirectly |
| What may be bought or done? | Yes | No | No | No |
| Who is the agent? | Uses identity as input | No | Yes | Partly |
| Works on invoices and non-payments? | Yes | No | Partly | Partly |
| Stop one agent at every seller, now? | Yes, at every seller that checks | No | No | No |
| Evidence both sides can check later? | Signed receipt | No | No | No |
| Answer is yes/no, same everywhere? | Yes | Only on money | Only on identity | A score |
Getting started
Small to adopt on both sides
Write the rules once: what it may do, how much per order, from whom, until when. Pull it back with one switch. No change to how you pay.
Add one check before you act: pass the agent’s two headers and the order to one call. Act only on allow, keep the signed receipt.
Stay honest
When you don't need Delegus
- A human approves every action.If nothing happens without a person clicking yes, the person is the authority check.
- One agent, one vendor, small spend.A card limit may be enough — until you add vendors or agents.
- The agent only reads public information.Nothing to authorize.
Know the limits: today’s limits are per order. A run of fresh orders that each stay under the limit still passes. Totals across orders over a period are planned for the next version (v0.3). Until then, keep the card limit as the backstop for totals.
Delegus is for companies whose agents act across many sellers, many ways to pay, and real consequences — and that group grows every month agents get more capable.
See it, then try it.
Watch a recorded live run: one grant, two sellers on two ways to pay, refusals before any payment runs, one revoke refused at every seller that checks. Then get your own first signed decision.
Free sandbox, no card · 14 days free in production · examples above are illustrative