An agent can prepare a payment, collect proof, route a review and monitor settlement. None of that means it should inherit the treasury.
The useful question is not whether software can move money. The useful question is whether it can perform a defined financial job without gaining the authority to redefine that job.
That is the difference between giving an agent a wallet and giving it a mandate.
A wallet is not a mandate
A wallet answers one narrow question: can this key sign a transaction?
A mandate answers the questions an organization actually needs to control:
- What job is this agent responsible for?
- Which actions can it take?
- How much can it prepare, authorize or execute?
- Which recipients and payment sources are allowed?
- What evidence must exist before payment?
- Who reviews the work?
- Which signing path may settle it?
- How can the authority be paused or revoked?
If those decisions live only in a prompt, the agent has instructions but not enforceable authority boundaries. Prompts can guide behavior. They should not be the control plane for a treasury.
Start with the job, not the agent
Financial operations contain different jobs. Preparing a contractor payout is not the same job as reviewing milestone evidence. Reviewing compliance context is not the same job as authorizing an amount. Authorizing a payment is not the same job as signing it.
Decrow models those differences as agent roles. An agent can operate as Payout Ops, Recipient, Milestone Reviewer, Compliance, Finance Review, Treasury, Audit or a bounded Custom role. There is no Owner or Admin agent role.
Each role begins with a limited set of scopes. A Payout Ops agent can work with recipients, draft payments and milestones, but it does not receive authorization or execution scopes by default. A Finance Review agent can inspect and authorize eligible payments. A Treasury agent can authorize and execute, subject to its policy.
The role describes the job. Scopes describe the actions available to that job. Neither gives an agent the right to expand its own authority.
Policy comes before payment
Scopes alone are too broad for financial work. An agent that may draft a payment still needs boundaries around the payment it is drafting.
A Decrow policy can define:
- a maximum amount per payment;
- daily and monthly limits;
- allowed recipients and recipient types;
- allowed payment sources;
- required milestone proof;
- compliance and finance review gates;
- whether automatic execution is allowed;
- who pays the settlement fee;
- an expiration time.
The policy is evaluated against the payment, the current usage, the available proof, the recorded reviews and the workspace plan before execution can proceed.
Automatic execution is not the default. It requires the necessary authorization and execution scopes, an explicit policy decision and a compatible signer mode. The organization defines that boundary. The agent cannot use MCP to rewrite its own policy.
Signing is a separate control
An authorized payment is still not a signature.
Decrow supports two organization-controlled settlement paths. A connected treasury wallet can complete the payment in the workspace, or the organization can run Decrow Signer locally. The local signer keeps delegated key material in an encrypted vault and does not send the seed phrase or private key to Decrow.
The signer can operate in three human-configured modes:
- Supervised, with local confirmation for each payment.
- Policy-bound, executing API-issued jobs while the signer is running.
- Automatic, for continuous operation after the organization explicitly enables automatic execution.
The policy decides whether the payment is eligible. The signer controls how an eligible payment is signed. Keeping those responsibilities separate prevents a capable agent from becoming its own policy author, reviewer and unrestricted signer.
What this looks like in a real payout
Consider a contractor milestone for 2,400 USDC.
A team could let a Payout Ops agent create the recipient, prepare the milestone and draft the payment. A Recipient agent could submit proof of completed work. A Milestone Reviewer could review that proof. Finance could authorize the payment after the required evidence and review are present. A Treasury agent or connected wallet could then settle it through the approved signing path.
The exact separation is configurable, but the principle stays constant: no single piece of software needs unlimited authority to complete the workflow.
If the amount exceeds the policy, the recipient is outside the allowed set, a required review is missing or the quote is no longer valid, the payment does not silently pass through. The system records a policy decision and the next required action remains visible.
Revocation is part of the design
Agent authority should be easy to remove without rotating the organization's entire treasury setup.
In Decrow, an agent credential can be revoked. A policy can be replaced or revoked by a human actor. Revoking an agent also revokes its active credentials and policies. Agent activity, policy decisions, reviews and execution state remain part of the workspace audit trail.
This matters because software changes. Models change, tools change and operating responsibilities change. A financial mandate should be explicit enough to inspect and narrow, and disposable enough to revoke.
A practical evaluation checklist
Before connecting an agent to a payment workflow, ask:
- Can it become an owner or administrator?
- Can it grant itself new scopes?
- Can it change its own limits, recipients or review requirements?
- Are preparation, review, authorization and signing separate actions?
- Is automatic execution opt-in and bounded by policy?
- Does the organization retain control of private key material?
- Can one credential or mandate be revoked without rebuilding the treasury?
- Is there an audit record connecting the agent's action to the payment state?
A system that cannot answer these questions is offering automation without a complete operating model.
The current boundary
Decrow Agentic Payments is a connected surface for payout and collection operations, not a promise of an autonomous treasury.
It currently requires an active Launch plan or higher and sufficient DECROW held in the registered treasury for each active agent slot. Settlement runs on the supported Solana and USDC rail, and the organization still needs a funded connected treasury wallet or local signer. The free trial does not include MCP access.
Those prerequisites are intentional signals that an agent is entering a real financial workflow. The goal is not to remove human authority. It is to let software do more useful work inside authority that humans can define, inspect and revoke.
Explore how the mandate works in Decrow, or inspect the current roles, scopes and payment tools in the MCP reference.
For the operating controls around a recurring payout, read What a stablecoin payroll run actually needs.