A second signerthat can only say no.

Why spending limits aren't enough

Agents can now pay invoices, buy services and move funds. The usual safeguard is a policy: a spending limit and an allowlist of payees. Caps and allowlists stop strangers. The theft that actually happens to businesses is small, looks routine, and often pays someone already on the list:

• Lookalike addresses. An address that shares its first and last characters with a supplier's, so both look the same when shortened.
• Changed payout details. An email from a lookalike domain says the supplier's wallet has changed.
• Planted instructions. A web page or document the agent reads tells it to send money somewhere.
• Duplicate invoices. A reminder for an invoice that was already paid, to the supplier's real address.
• Padded amounts. A listed supplier paid more than the invoice says.

Every one of these fits inside a normal weekly limit. On Veto Bench, a plain policy (allowlist plus a per-payment cap) lets 17 of 50 attacks through, every one to a listed supplier, and blocks 8 honest payments to new suppliers the mandate allowed. Veto's screen, running in NEAR AI's enclave, catches all 50, including every one a plain policy lets through.

How a payment flows

1. The agent proposes. It calls propose on the vault with the payee, amount and invoice number, and sends the evidence behind it (the email, the invoice) privately to the guardian. Only a hash of that evidence goes on-chain (the shared sandbox, whose emails are made up, also publishes them).
2. The contract checks the hard limits. Per-payment and weekly caps, listed assets, agent allowed, vault not frozen. Anything over a cap is refused right here.
3. The guardian screens it privately. It sends the mandate, the payee list, recent payments, deterministic risk signals (lookalike, new payee, duplicate) and the evidence to a model running in a TEE on NEAR AI Cloud. The model answers PASS or VETO with reason codes, and the enclave signs the exact request and response.
4. The contract checks the verdict. It recovers the signer with ecrecover, checks it is an approved model key, checks the response names this exact proposal, then records the verdict.
5. PASS pays, VETO blocks. A pass is re-checked against the caps and paid. A veto stays blocked unless the owner overrides it, which waits for a delay and can be cancelled. No verdict before the deadline means the payment expires.

The rule: the AI can only say no

The design keeps the AI out of the decision to move money. It can only add a no. That way an AI mistake can never cost more than the limits you already accepted.

How anyone can check a decision

Every verdict on the vault records the model, the signer, the chat id and the hashes of what the model saw and said. To check one:

1. Open the decision's Proof page in the app, or read it from the contract with get_proposal.
2. The signer is the model's key, published in NEAR AI Cloud's attestation report and backed by an Intel TDX quote. The vault approved that key before any verdict.
3. On the Proof page, Check the enclave now verifies that from scratch with a fresh random nonce: the TDX quote against Intel's certificates, the GPU evidence with NVIDIA's attestation service, that the quote binds the key and the nonce, the app the enclave runs, NEAR AI's gateway, and that the attested key signed this verdict. node bench/verify.ts --attested runs the same checks from a terminal.
4. The signature covers model:sha256(request):sha256(response). In the shared sandbox the exact request and response bytes are published, and the Proof page re-hashes them in your browser: they match what the enclave signed and the vault checked, and the email inside the request matches the hash the agent put on-chain before screening. A vault someone owns keeps them private; the standalone guardian (services/guardian) keeps them in a private audit record, so an owner can show the exact prompt to an auditor.
5. NEAR AI's own verifier confirms the signature independently, and Veto Bench results can be re-checked offline with node bench/verify.ts.

What this proves: the verdict came from that model inside a genuine enclave. It doesn't prove the model judged correctly, which is why the AI can only say no.

Paying suppliers on other chains

Suppliers hold USDC on many chains. The vault sits on NEAR and pays out through NEAR Intents: the owner sets a route (for example "base: USDC on NEAR to USDC on Base, fee at most 1%"), and when a cross-chain payment passes the screen the guardian brings a 1Click quote for exactly that amount to exactly that address.

The vault checks 1Click's ed25519 signature on the quote itself and confirms it pays the screened payee, on the screened chain, for the screened amount, refunds only to the vault and stays under the fee cap. The caps count what actually leaves the vault, fees included. Then it sends the deposit. A doctored quote is refused on-chain.

Or from the vault's own address

The vault can also hold its own address on an EVM chain through NEAR Chain Signatures. When a payment to a Base supplier passes, the vault builds the transfer itself: exactly the screened payee and amount, gas under the owner's cap. Then it asks NEAR's MPC network to sign that transaction's hash. The guardian only broadcasts the signed bytes and reports the hash, so the vault's Base address can never send anything that didn't pass both gates.

Agent wallets on OutLayer

Some agents don't pay from a vault at all. They hold an OutLayer wallet: keys inside a TEE, with an owner policy that can require approvals. Veto plugs in as one of those approvers, so the same screen covers a wallet it doesn't hold.

1. The agent asks its wallet to pay. The wallet's policy needs an approval, so OutLayer holds the payment and returns an approval id. The agent hands that id and its evidence to the guardian.
2. The vault records it. The guardian reads the held operation, checks OutLayer's hash of it, and records the payment on your vault with propose_external. Your caps apply exactly as they do to vault payments.
3. It is screened and checked on-chain. The model screens it privately, and the vault checks the signed verdict. The OutLayer approval id and operation hash are part of the proposal hash the model must echo.
4. Veto votes only after a pass. If the vault passes it, the guardian signs a yes on OutLayer and the wallet sends it. The guardian then checks that transaction on NEAR, and only then marks it paid. On a veto Veto never votes, so the wallet keeps holding it.

The owner is a second approver on the wallet. An override on the vault waits out the same delay, then Veto votes yes; the owner can also approve on OutLayer directly. Keeping the veto rejects it on OutLayer right away; an approval nobody signs expires after 24 hours.

NEAR Intents Agent API wallets

The NEAR Intents Agent API gives an AI agent its own account on NEAR Intents. The owner signs one policy, which is the hard limit: which actions, which assets, how much, and where money may go. Whoever is allowed to spend holds a grant.

1. Veto holds the only grant. The AI agent has none, so it can't move money. It can only ask Veto.
2. Veto screens the request. The same enclave model reads the agent's evidence against the mandate and the business's payment history, and Veto requires the verdict to be signed by a key the vault approves.
3. Only a pass is sent. A supplier on NEAR gets a transfer; a salary is a withdrawal that NEAR Intents pays out on the chain the worker chose, Base in the demo. Veto calls the API with its grant, under an idempotency key tied to that screening, so a retry can never send twice. A veto never reaches the API.
4. The owner's policy still decides. Even after a pass, the API refuses anything the policy doesn't allow: an unlisted payee, more than the per-payment or daily limit, or a frozen account. The demo's policy allows withdrawals only to Tunde Bello's saved Base address, so a “new wallet” would be refused there even if the screen missed it.

The demo's account lives on mainnet and holds a few real dollars, so the inbox's amounts are scaled 1:2000 on this path: the examples that pass cost $0.09 and $0.075, and the owner's policy allows at most $0.10 a payment. The sandbox vault is on testnet, so these decisions aren't recorded on it; the enclave's signed verdict and the API's own operation record are the trail.

What stays private

Try it on testnet

The live demo is at veto-beta.vercel.app, with nothing to install. The shared sandbox is treasury.veto-rhwe0krb.testnet, a made-up business called Lagoon Goods that holds test USDC and pays three suppliers (two on NEAR, one on Base) and a member of staff. Anyone can act as its owner, and it goes back to its default rules for each new visitor. For a vault only you control, start with step 1.

1. Do open Create your vault, connect a NEAR testnet wallet (Meteor Wallet at meteorwallet.app makes a testnet account for free; switch it to testnet first), name your business and sign. A new wallet starts with no NEAR, so Veto sends it 0.3 test NEAR for gas when it connects. See your own vault live in a few seconds, with $5,000 test USDC, two suppliers and its own test agent. From here on, overrides, freezes and rule changes need your wallet's signature.
2. Do open the app and press Try it (the green V on a phone, Try the agent at the top of the sidebar on desktop). See the agent's inbox: a real invoice, a real salary and four scams that look ordinary.
3. Do let the agent pay the real Kano Cotton Mills invoice. See "Agent proposed", "Screening privately", then Paid, with testnet transaction links.
4. Do let it pay "Updated payment details". See Vetoed: a lookalike address, a new payee and changed payout details, while the payment was inside the weekly limit.
5. Do open the decision, then Proof. See the signer, the hashes and the on-chain check, then the exact bytes the model saw, re-hashed in your browser.
6. Do on that page, press Check the enclave now. See eight checks of NEAR AI's enclave run live: Intel's quote, NVIDIA's GPUs and the key that signed the verdict.
7. Do open Activity and press Download CSV. See one row per payment, ready for an accountant: date, payee, amount, status, reference, verdict and reasons, the payout transaction and a link to its proof.
8. Do press Override (your wallet signs it in your own vault; in the sandbox anyone can). See a countdown; the override pays only after the delay and can be cancelled.
9. Do in the sandbox, switch Pay from to OutLayer wallet and repeat. See the paid invoice approved by Veto on OutLayer and sent by the wallet; the scam stays held, and Keep it blocked rejects it there for good.
10. Do press Write your own email and write the agent an invoice, or a scam. See a real AI agent on NEAR AI read it and propose whatever it asks for, then Veto screen that payment like any other.
11. Do in the sandbox, let the agent pay Tunde Bello's salary. See Paid on Base, the chain Tunde chose, sent from the vault's own Base Sepolia address with NEAR Chain Signatures, with a Base explorer link.
12. Do let it pay “New wallet for my salary”. See Vetoed: the address imitates Tunde's saved one, it has never been paid, and the request came from outside the company.

Verdicts are signed by Qwen3-VL-30B inside NEAR AI's enclave, and each decision's Proof page shows which key signed it (a few early sandbox decisions were signed by a labelled test key). The sandbox and the vaults you create trust only the enclave key, so without an answer the payment expires unpaid.

For developers

An agent connects with a key that can only call propose:

import { Veto, toUnits } from "@veto/sdk";

const veto = new Veto({
  vaultId: "treasury.veto-rhwe0krb.testnet",
  agentAccountId: "buyer.<your-account>.testnet",
  agentKey: process.env.AGENT_KEY,      // a propose-only key
  guardianUrl: "http://localhost:8799",
});

const { id } = await veto.propose({
  payee: "kano-cotton.<your-account>.testnet",
  asset: "usdc.<your-account>.testnet",
  amount: toUnits("180", 6),
  memo: "INV-2290",
  evidence: { source: "email", body: "…" },  // stays off-chain
});

const decision = await veto.decision(id); // Paid, Vetoed, Expired…

Contract methods

Run it yourself

pnpm install
pnpm test                         # core, contract and factory tests
pnpm build:contracts              # the contracts, as wasm
node scripts/check-deployed.ts    # the code on testnet is exactly this build
node bench/verify.ts bench/results/Qwen_Qwen3-VL-30B-A3B-Instruct.json --attested
pnpm build && pnpm start          # the app on http://localhost:3000, reading the live sandbox
pnpm demo:setup                   # optional: your own testnet sandbox from the faucet (see the README)

Built on NEAR

• NEAR AI Cloud. Models in TEEs (Intel TDX and NVIDIA confidential GPUs) that sign every answer; the vault checks that signature on-chain.
• NEAR Intents (1Click). Pays suppliers on other chains; the vault verifies the signed quote before sending.
• Access keys. Function-call keys limited to one vault and a few methods: the agent can only propose, the guardian can only record verdicts and settle payments.
• Global contracts. The vault code is deployed once (NEP-591); every vault the factory creates runs it by hash and stores only its own state.
• Named accounts and sub-accounts. treasury., buyer., guardian. under one owner account, so roles are readable on-chain.
• NEP-141 tokens and contract events. USDC payments, with every decision emitted as a NEP-297 event.

What works today

• Live on testnet
  Vault contract: caps, verdict check, overrides, freeze

  48 contract tests; deployed on NEAR testnet.

• Live on testnet
  Your own vault, owned by your wallet

  A factory creates a vault for any NEAR testnet account in one transaction its wallet signs. The vault code is deployed once as a NEAR global contract, so each new vault stores only its own state (about 1.6 KB). Its agent and screening accounts are its own too, each holding one key that can only call that vault. Every owner action is signed by the owner's wallet.

• Live on testnet
  OutLayer agent wallets

  Veto is an approver on an OutLayer wallet's policy. Pass, veto and override all run on testnet, settled against the wallet's real transactions.

• Live on mainnet
  NEAR Intents Agent API wallet

  An agent account on mainnet whose owner-signed policy is the hard limit. Veto holds its only grant, screens each request with the same enclave model, and sends only a pass: a transfer to a supplier, or a salary withdrawn to the worker's address on Base. Each payment is a few cents of real USDC, and runs while the wallet holds some.

• Live on testnet
  Payroll: staff paid on the chain they chose

  Staff sit on the payee list with their own wallet and chain. The sandbox pays a salary in test ETH on Base from the vault's Chain Signatures address and vetoes a fake request to send it to a new wallet.

• Live on testnet
  Agent inbox and guardian screening

  Real proposals and verdicts on testnet, screened by Qwen3-VL-30B inside NEAR AI's enclave. The sandbox trusts only the enclave key, like every vault you create: if NEAR AI can't answer, the payment expires unpaid.

• Live on testnet
  Owner actions in the app

  In your own vault, only your wallet. In the shared sandbox, a demo-owner key limited to the owner methods, so anyone can try it without a wallet. The sandbox goes back to its default rules for each new visitor.

• Live on testnet
  Private AI screen on NEAR AI Cloud

  Qwen3-VL-30B runs in an Intel TDX enclave on NEAR AI Cloud and signs each verdict in about 1.5 s. The vault checks the signature on-chain against the model's attested key.

• Live on testnet
  Enclave verification

  Every Proof page re-checks NEAR AI's enclave live with a fresh nonce: Intel's TDX quote, NVIDIA's GPU evidence, the key and nonce bound into the quote, the app it runs, the gateway, and that the attested key signed the verdict. Tested offline on a captured real quote.

• Live on testnet
  Activity export

  Download CSV gives one row per payment, ready for an accountant: date, payee, amount, status, reference, verdict and reasons, payout transaction and a link to its proof.

• Built and tested
  Paying suppliers on other chains (NEAR Intents)

  The vault verifies 1Click's signed quote on-chain, tested against a real executable quote. The mainnet payout is scripted and runs once the mainnet vault is funded.

• Live on testnet
  Veto Bench

  100 scenarios. Qwen3-VL-30B catches 50 of 50 attacks and blocks 8 of 50 honest payments; all 100 signatures re-verify offline. Plain-policy and rules-only baselines are published beside it.

• Built and tested
  Shield incident check before cross-chain payouts

  Holds a payout while a NEAR Intents Shield incident touches its chain, bridge, token or payee; fails closed if it outlasts the deadline. Runs when the Shield key is added.

• Live on testnet
  The vault's own Base address via Chain Signatures

  The vault builds each passed transfer and NEAR's MPC network signs exactly that; the contract tests include byte-for-byte checks against ethers.

Questions