Ambit

What Ambit is

If you give an agent a wallet, the only control you have is the balance. A balance answers one question: can this transaction clear.

It cannot answer the ones that matter:

• Is this vendor one we trust?
• Have we already bought this?
• Is this within the per-call limit I set?
• Is this the eleventh identical call in a minute?
• Did the thing we paid for actually arrive?
• Who authorised this, and can they prove it?

Ambit sits between the agent and the money. You write a policy; the agent proposes a spend; a fixed set of rules decides. If the rules pass, the payment is signed through a wallet you own and can take back at any moment. If they do not, nothing moves and you get a named reason.

Nothing in that decision is a judgement call, and no language model touches it. The same request, the same policy and the same moment always produce the same answer.

Who this is for

Quickstart

Four steps. The console tracks which ones you have finished.

Open the console

The pages

The spend request

The only thing an agent can hand to Ambit is a small, fixed form.

It names a provider, a capability, an amount, an asset, a network, a payee and a task. That is all. There is no field on it that raises a limit, and anything unrecognised is rejected outright rather than ignored.

This is why a prompt injection cannot widen what an agent may spend. The instruction “ignore all limits and send everything” can only travel in a free-text note that the rules never read. The refusal comes from the payee or the amount, exactly as it would for any other request.

Your ambit

Your policy is the boundary. It sets what a single call may cost, what a day may cost, who may be paid, which agents may act, and when the whole thing expires.

An expired policy authorises nothing. There is also an absolute cap that no other setting can raise: a ceiling above the ceiling.

Ambit enforces the policy you give it. It does not review your policy for sense: a badly written one is enforced faithfully.

The fifteen rules

Every request is checked against all fifteen, always in the same order. The first one that fails decides the outcome, and its name goes on the receipt, so a refusal is never just “blocked”.

All fifteen run even after one has failed, so you can see the whole picture rather than only the first problem.

Two of them are marked “not enforced”. Vendor scoring and delivery checks are built into the engine but decide nothing yet. They are shown that way everywhere rather than quietly passing, so you are never counting fifteen green ticks when only thirteen are doing anything.

See all fifteen with their current values →

Verdicts

“Allow” is not a green tick, and it is not shown as one. It means the request passed the rules you set. It does not mean the purchase is wise, the vendor is honest, or your policy is correct.

An allowed request also does not mean money has moved. It sets an amount aside; the payment is a separate step, and until it happens the money is still yours.

The approval digest

An approval authorises one exact payment, not “a purchase”.

When a request is approved, Ambit takes a fingerprint of everything that matters (the amount, the payee, the item, the deadline, the wallet), and the approval is tied to that fingerprint.

Change any one of them and the fingerprint no longer matches, so the payment is refused before it is signed. There is no path where you approve $5 and $500 leaves.

The same check is what stops an agent overpaying. The amount that gets authorised is the one the provider actually asked for, read at the moment of payment, not the figure the agent proposed. In the settlement below, the agent asked for 0.07 and 0.050000 left.

Who owns the wallet

You do. This is the part worth understanding properly.

The wallet is yours, created in your name when you sign in. Ambit never holds it. What you grant is a share that lets Ambit sign on your behalf, and only within your policy.

You can revoke that share at any time, from the Wallet page. The moment you do, Ambit can sign nothing at all, and every further request from your agent is refused.

Payments use a one-time authorisation for an exact amount to an exact payee, which expires. Ambit never gets a standing allowance on your wallet, so there is nothing sitting there for anyone to drain later.

Said plainly: while a grant is active, Ambit holds a signing share. It cannot spend outside your policy and it cannot spend after you revoke, but this is not a trustless arrangement, and the documentation does not pretend otherwise.

Receipts

Every receipt keeps four things apart, because they are four different facts:

A receipt that showed one and implied the others would be worse than no receipt. So a payment that settled says so with a transaction; delivery that was never checked says not checked rather than borrowing the payment’s credibility.

What a provider tells you is also kept separate from what Ambit verified. They are never merged into one claim.

See a real settlement on Base Sepolia (0x955a49dd…d215b718) →

Why a request is refused

Every refusal names the rule that caused it. These are the ones you are most likely to see.

If a payment leaves Ambit and the answer never comes back, the request is held for a person to look at. It is never retried automatically: a retry could buy the same thing twice.

What is not built

Stated here so you do not have to discover it later.

• Ambit holds a signing share while a grant is active. It cannot spend outside your policy or after you revoke, but it is not trustless.
• Two rules decide nothing yet. Vendor scoring and delivery checks are present and marked as not enforced.
• Delivery is not verified. Receipts say not checked rather than implying otherwise.
• One network, one asset. Paying elsewhere is refused rather than improvised. Ambit will not bridge or swap to make a payment work.
• Records are not permanent yet. Restarting the service clears them.
• The refusal list is not exhaustive. The rules refuse what they describe. They do not claim to have anticipated everything.