Delegus Check
Authority for machines that act.
Delegus Check verifies what an AI agent is allowed to do before it acts, then signs the answer so both sides can prove it later. The service that receives the agent's action makes one call and pays per check. The company that gives its agent authority pays nothing.
Try it freeWatch the 70-second recording
Telling an agent “don’t” in a prompt is a request, not a rule. Delegus Check keeps the rule outside the agent and checks it before the action. Machines are starting to act for us: AI agents that buy and book, and robots that move and assemble. The business or site on the other side needs to know each action was actually allowed. Delegus Check verifies that before the action and keeps a signed receipt of the answer. This page takes that down to the root, answers the two objections people raise most often, and shows it in real situations.
You stay in charge. You decide what the agent may do, anything over the line is refused, one revoke takes it back everywhere, and every decision carries a signed receipt showing whose authority it ran on.
Delegus Check is also the check inside EnterpriseWorld, where agents are trained and evaluated on real business work.
The answer in one breath
Identity tells you who it is. Payment tells you the money moved. Nothing tells you it was allowed.
When a machine acts for a company, the question that matters is not “is this a real agent?” or “is this card good?” It is “did this company allow this machine to do this, under these limits, right now?” Delegus Check answers that before the action, and signs the answer so both sides can check it later without trusting each other. For payments, read An AI agent can pay. That doesn’t mean it was allowed to.
Verify before. Prove after.
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. They do it 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 Northfield's agent”. It doesn't say what Northfield 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 it 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 confirm is genuine, even without us. Revoke once, and every seller that checks refuses, whatever way they get paid.
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”), like “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 Check 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, and 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. That way the rules it covers (what may be bought, from whom, up to how much per order, how much in total across orders, until when, and whether it has been revoked) hold even when the agent gets it wrong. The seller’s own steps (quoting, accepting an order, delivering) can be checked the same way, and a later step can rely on an earlier decision, which is checked first, and the seller can see they hold.
Check it: Over the limit, replayed or revoked, in the live demo · The check order, spec §5.4
Before production
Agents should learn the rules before they meet a real seller.
Most agents first run into a limit in production, which is the worst place to find out they never learned one. So we built Northfield, a working company with purchasing, a plant and a finance team. Agents do real jobs there: they chase a shortage, order from a supplier, pay an invoice. Every consequential action they try goes through the same Delegus Check verify a seller would run.
When an agent oversteps, the check refuses it and records why. That record shows exactly where an agent goes wrong, long before it touches your money. And the rules it learned against are the same ones it meets later, in production. See how the research works.
Check it: How a run is graded · A recorded episode
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 Check 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.” 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.
Check it: Receipts and offline re-check · The conformance tests
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? | Per action and across orders (budgets) | 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.
Identity is necessary. It isn’t sufficient.
Four questions get asked about any machine that acts. Each needs its own answer.
- Identity. Who is this machine?
- Capability. What can it do?
- Agency. Can it act on its own?
- Authority. May it perform this action on behalf of this principal?
The agent economy needs all four. Delegus is infrastructure for the fourth.
Open format. Closed service.
Anyone can verify a Delegus artifact without calling Delegus. Nobody else can produce a fresh one.
Published and reproducible
- Grant semantics and the constraint vocabulary
- Proof format, carrying the request’s method and URL
- Protocol verification rules, versioned and hashed
- Receipt and outcome formats
- Use your own web domain as your company’s identity
Run by Delegus
- Issuer trust and domain verification
- Live revocation and replay protection
- Decision signing and evidence preservation
- The outcome graph, and what it eventually makes possible
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: a total across orders applies only when the grant of authority declares a budget: a total, a limit per day, week or month, or a number of uses. Without one, each order is checked on its own, so a run of orders that each stay under the per-order limit still passes. A budget is spent only after every other check passes, so a refused request never uses it up. Money budgets cover purchases; for the seller’s quotes and acceptances only a number of uses can be set today. These rules are in v0.3, a release candidate that is final once an outside cryptographic review is done.
Delegus is for companies whose agents act across many sellers, many ways to pay, and real consequences. That group grows as 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