How payments are controlled

Vestiarion's agent decides what to do with each bill, but a decision is not a payment. Before any money moves, rules in Vestiarion's code check the decision, limits cap what the agent may pay on its own, and people decide whatever it may not. This page says what each of those does, what stops the agent, and where money can move at all. Each part links to the guide that goes into it. How the data behind these decisions is protected, from tenant isolation and encryption to connector tokens, webhooks and the services that receive data, is on the Security page.

A decision is not a payment#

For each bill, the agent decides to pay it now, to pay it on a later day, to hold it for a person, to flag it, or to ask for what is missing, and it writes down why. A model proposes that decision; when no model is configured, a written policy does. Either way:

• A decision to pay is checked by code before anything is sent. If a check fails, nothing is sent: the bill is held, flagged or sent back for what is missing, and its card says "Blocked by code, not by the model" and names the rule in words. Nothing the model writes changes these checks.
• In shadow mode, nothing is paid until a person agrees. Each decision asks Do you agree with the agent?, and Agree and pay pays it through the same checks a person's approval goes through. See Run alongside how you pay today.
• A scheduled payment is decided again on its day. Scheduling sends nothing; on the day, the checks run again.

Every decision, refusal, approval and payment is a signed entry in the workspace's ledger. See The record.

The checks in code#

These checks run on every payment the agent would make, in src/lib/agent/guardrails.ts. Each names its rule on the card that it stopped.

The last two run after every other check, and only ever hold: a payment another check stopped is left as it was.

Payments in EURC and to payees on other chains have checks of their own, such as a cap on the swap's or the transfer's cost.

Limits#

• Each payee's limit. Every vendor and contractor has a Payment limit (USDC): the most the agent pays it on one bill without a person. Screening sets how much of it applies: all of it for a payee screened clear, a quarter for medium risk, and none for high risk. See Changing a payment limit.
• The agent's spending limit. On the console, the Agent spending limit caps what the agent pays on its own per day and per 7 days. A payment that would pass it waits, and is decided again when the limit has room. A payment a person approves is neither stopped by it nor counted against it. On Arc mainnet a workspace always keeps a figure, starting at 50 USDC a day and 150 USDC in 7 days. See Cap what the agent pays on its own.
• A project's budget. A bill or milestone in a project has its money set aside in the project's budget before the agent pays or schedules it, one decision at a time, so two never spend the same budget. One the budget cannot cover waits for a person. A project's budget is an earmark in Vestiarion, never money locked on chain, and a person's approval is not held by it. See Give each project its own budget.
• A limit enforced on Arc. The spending limit is checked in Vestiarion's code. On Arc testnet, Enforce on Arc also puts it in a contract the agent's payments must go through, which refuses anything past it. On Arc mainnet, a treasury in a wallet you hold pays the agent only through a contract your wallet deploys, within the daily and 7-day figures you set in it. See Enforce the limit on Arc and Path C: your own wallet.

People#

Owners, admins and approvers decide what the agent did not pay, in Approvals: Approve and pay, reject, or return it to the agent.

• The person who entered a bill cannot approve it. The card says "You created this invoice", and another owner, admin or approver decides it. In a workspace with only one person who can approve payments, that person may, and the ledger records that they did.
• A partner never approves their own commission. A member named as the partner on a commission plan cannot approve the payable that pays them, nor give one of its two approvals, even as the only person who can approve payments. See Pay commissions on money received.
• A first payment to a new address needs two people. The first payment to a payee at an address it was never paid at needs two people, even if the workspace has paid that address for someone else. Whoever gave the address cannot approve that first payment: the card says "You gave this payee's address". For an address the payee sent through a payee link, that is whoever created the link. For one sent on GitHub, or one whose giver no one can name, it takes two different members: one confirms the address on Counterparties, and another approves its first payment. Whoever confirmed it cannot approve it, and no one approves it alone before someone else has confirmed it, since approving would confirm it too. The only approver in a workspace may pay it, and the ledger says so.
• Two approvals above a figure. An owner can make payments above a figure need two people, under Two approvals in Settings (Payments above (USDC)). The agent never pays above it on its own. On Arc mainnet a workspace starts with two approvals above 100 USDC, and an owner can raise the figure but not turn it off. See Two approvals above a figure.
• Each bill waiting for a person has an owner and a day. Its card in Approvals, and its row on Bills & receivables, say its priority (Overdue, Due today, Due this week or Later), the day to decide it by, and "Who can act": the owners, admins and approvers who may approve it, less whoever entered it and, for a first payment to a new address, whoever that address leaves out. The day is its due date, or the last day of its early-payment discount while that comes first: "Decide by Oct 15, 2026 to keep the early-payment discount". Someone who cannot decide it is told whom to ask.
• A bill past its day is escalated once. After each scheduled cycle, each person who can decide gets one email listing the bills they may decide that passed the day they were to be decided by, each bill once for that day, unless they turned off Email me when payments need a decision in Settings, under Notifications. A discount's last day passing moves the day to the due date, and the bill is escalated once that passes. If the day moves, because the due date changed, it is escalated again when the new day passes. Escalations count from the first cycle that ran them in your workspace: a bill already past its day then is not emailed about.

Stopping it#

• Pause agent, on the console, stops the agent at once: it runs no cycle and moves no money, and its scheduled runs are skipped. You can give a reason, which every page shows and the ledger keeps. Owners, admins and approvers can pause it; owners and admins start it again with Resume agent. People can still pay or reject from Approvals while it is paused. See Go live.
• From your own wallet, on Arc mainnet, Stop the agent's payments sets your wallet's approval for its contract to 0, so the contract can move nothing, and pauses the agent.
• For every workspace, whoever runs the deployment can switch payments off. Every page then says "Payments are switched off for every workspace right now."

Where money can move#

USDC on Arc testnet has no market value: it comes from Circle's faucet or from Vestiarion's float, and lets you try everything, real transactions included. A workspace's network is chosen when it is created and never changes. Some features run on Arc testnet only: payouts to other chains, the USYC reserve, the EURC swap and escrow. See On Arc mainnet.

Who holds the keys#

• On Arc testnet, and on Arc mainnet with your own Circle account, the wallets are developer-controlled wallets in Circle: Circle signs for them on Vestiarion's behalf. A limit enforced on Arc keeps the agent, and the code that pays for it, within the figures; it does not protect against someone who took over Vestiarion's server, who could also sign for the operating wallet.
• On Arc mainnet with your own wallet, in your browser or with a passkey, Vestiarion never holds your USDC. The agent pays from your wallet only through the contract your wallet deployed and approved, within its figures, and your wallet can change the figures or stop it.

When a payment fails#

Vestiarion never sends a second transfer while the first could still settle. A payment that has not confirmed 15 minutes after it was submitted to Circle is reported to the workspace's people, in the console, in Slack and Telegram, and by email. A failed attempt says why on its card, and approving it again sends a new transfer. See When a payment does not confirm.

The record#

Every decision, refusal, approval and payment is an entry in the workspace's ledger, signed with Ed25519 and linked to the entry before it, so a change to any entry breaks every link after it. In Audit log, Verify hash chain checks every signature and link and answers "Chain intact" when they hold. To check it outside Vestiarion, Verify an audit export. For one payment, Why it was paid on its card lays out its evidence link by link, from the purchase order to the receipt, and says how each fact is known: see Why a payment was paid. When the model and the policy disagree reads production decisions, and the payments code refused, from the same record.

Edit this page on GitHub (opens in a new tab)