Send-flow does not start with a Send button
AI agent send crypto transaction is not a prompt that says "send 100 USDT." For a product that lets an agent move funds, the send-flow should start with a structured intent, pass policy checks, include an idempotency key, receive Co-Signer approval, use MPC signing, and end with status in the ledger and WebSocket events.
This boundary matters. An AI agent can help an operator, support team, finance workflow, or product system prepare a transaction. But the model should not receive private keys, MPC shares, API private keys, or unlimited spending authority. If an agent can send USDT, USDC, or other supported assets, infrastructure must enforce checks for amount, destination, asset, network, business reason, and risk state.
In BroLabel, this flow should be built through BroLabel AI Agents, BroSettlement, and Agent Skills. The agent creates a signed request or send intent. Wallet infrastructure checks policy, the Co-Signer keeps the signing boundary outside model context, MPC signs the transaction, and the ledger records the result.
Short Answer
An AI agent can send crypto transactions without access to a private key if it operates through scoped API access, a customer-hosted Co-Signer, allowlists, spending limits, idempotent requests, and ledger tracking. The safe flow: the agent creates a send intent, infrastructure checks policy, the Co-Signer approves or rejects the operation, MPC signs the transaction, broadcast sends it to the network, and WebSocket events expose the status.
Why autonomous sending needs a hard boundary
Receive-flow is relatively safer: an agent can create an address, listen to events, and show balance state. Send-flow is different. A mistake can immediately move funds to the wrong destination, bypass internal approval, or create a duplicate payout.
Common send-flow failures include:
- Unbounded spend. The agent sends more than the workflow or budget allows.
- Wrong destination. The address is valid but is not on the allowlist or belongs to the wrong recipient.
- Duplicate transaction. A retry without an idempotency key creates a second payout.
- Wrong asset or network. The user asked for USDT on TRON, but the intent is created for another network or asset.
- Missing business reference. Finance sees a transaction hash but not the invoice, user, withdrawal request, or case ID.
- Prompt-secret leakage. Someone tries to give the agent a seed phrase, private key, or recovery material.
The right architecture does not ask whether the agent is smart enough. It asks which system prevents the agent from signing the wrong action.
How it works
A controlled send-flow has several independent layers.
- The agent runtime receives a user or system request.
- The agent creates a structured send intent instead of a raw transaction.
- The API request is signed with a scoped Ed25519 key.
- Wallet infrastructure checks wallet, asset, network, balance, and idempotency key.
- The policy layer checks limits, allowlist, velocity, role, and compliance state.
- The customer-hosted Co-Signer approves or rejects the intent.
- MPC signing creates the transaction signature without exposing the private key.
- Transaction broadcast sends the signed transaction to the blockchain network.
- Ledger and WebSocket events update product, support, and finance teams.
The agent is not the custody layer in this flow. It is an operational interface that prepares intent and reads state. Signing authority stays inside protected infrastructure.
Required fields for a send intent
A send intent should be structured enough for machine policy and human review.
| Field | Why it matters | Example control |
|---|---|---|
| walletId | Which wallet sends funds | Wallet must belong to the correct account or treasury |
| network | Which network receives the transaction | Allow only supported networks |
| asset | Which token or coin is being sent | Reject unknown assets |
| amount | Transaction amount | Check per-transaction limit |
| destination | Recipient address | Check allowlist or risk policy |
| businessReference | Invoice, withdrawal, case, or workflow ID | Give finance full reconciliation |
| idempotencyKey | Duplicate-send protection | One business action, one payout |
| requestedBy | Which user or agent created the intent | Audit trail and accountability |
| policyProfile | Which rule set applies | Different limits for support, treasury, payout bot |
If the intent does not include a business reference or idempotency key, it is better to reject it before signing. That is cheaper than investigating a duplicate payout or unexplained withdrawal later.
Policy matrix: what the Co-Signer should check
The Co-Signer should not be only "the server that signs." For an AI-agent wallet, it should be the policy boundary between model intent and transaction signing.
| Check | What is checked | Typical decision |
|---|---|---|
| Asset and network | Asset and network are allowed for this wallet | Reject or continue |
| Amount cap | Amount does not exceed per-transaction limit | Reject, manual review, or continue |
| Velocity limit | Daily or weekly spend has not been exceeded | Pause or review |
| Destination allowlist | Address is allowed or passes risk policy | Reject or review |
| Role and permission | Agent or user may initiate this action | Reject or continue |
| Balance and liquidity | Wallet has available balance | Reject or queue |
| Business reference | Invoice, withdrawal request, or case ID exists | Reject if reference is missing |
| Compliance state | KYC/KYB, AML, and Travel Rule checks are current where applicable | Review or reject |
| Emergency pause | No active stop condition exists | Reject |
For agents, a useful operating model is "cold by default, online only to sign." This is not a claim of a strict air-gapped cold wallet unless that deployment model is actually configured. It is a practical principle: the Co-Signer should not be continuously and freely available to the agent; it should activate for constrained signing, check policy, and close access after the operation.
Auto-approval vs manual review
Not every transaction should wait for a human. But not every transaction should pass automatically.
Auto-approval fits repeated, low-risk operations:
- destination is already on the allowlist;
- amount is below the configured limit;
- asset and network are allowed;
- business reference exists;
- idempotency key is new;
- compliance state does not block the payout;
- velocity limits are not exceeded.
Manual review is needed when the destination is new, the amount is high, the withdrawal is unusual, the user risk state changed, Travel Rule data is incomplete, or the agent request does not match business context.
Important: manual review should not live inside the prompt. A human or ops system should see the structured intent, policy result, wallet, amount, address, reference, and risk reason.
What must never enter the prompt
Send-flow does not require the model to see secrets. Do not pass the agent:
- private keys or seed phrases;
- API private keys;
- encryption keys;
- MPC share material;
- Co-Signer persistent volume contents;
- recovery files;
- admin credentials;
- raw environment variables;
- unrestricted wallet export or backup material.
The agent only needs scoped permissions for allowed API actions: create send intent, read policy result, read transaction status, listen to events, and show ledger records. Signing should happen through the Co-Signer and MPC.
Step-by-step flow
- User or system gives a task. For example: "send 250 USDC to the approved vendor."
- The agent resolves context. Wallet, asset, network, destination, amount, and business reference.
- The agent creates a send intent. The intent includes idempotency key and policy profile.
- The API request is signed. A scoped Ed25519 key confirms the automation layer identity.
- Infrastructure checks basic conditions. Wallet exists, balance is available, and network is supported.
- The policy layer checks risk. Limits, allowlist, velocity, permissions, and review thresholds.
- The Co-Signer makes a decision. Approve, reject, or manual review.
- MPC signing creates the signature. The private key is not assembled in one place and does not enter model context.
- Transaction broadcast sends the signed transaction. The product receives a transaction hash.
- WebSocket events update status.
intent_created,policy_reviewed,approved,mpc_signing,broadcast,confirmed,failed, ormanual_review. - The ledger records the result. Finance sees amount, account, wallet, reference, hash, timestamps, and final state.
If any step fails, the agent response should show the state and next action instead of repeating the send request without controls.
Where BroSettlement fits
BroSettlement fits teams that need API-first wallet, ledger, and settlement infrastructure instead of a hosted checkout. For AI-agent send-flow, that means:
- Agent Skills for Codex, Claude Code, Cursor, or other agentic tooling;
- scoped Ed25519 API keys for automation;
- customer-hosted Co-Signer as the signing boundary;
- MPC signing without a private key in the prompt;
- idempotent send requests;
- WebSocket events for the transaction lifecycle;
- ledger records for audit and reconciliation;
- policy controls for limits, destinations, roles, and review.
This does not remove KYC/KYB, AML, Travel Rule, licensing, or jurisdiction responsibilities from the team. BroSettlement provides the infrastructure layer. The team still has to define rules, risk process, and legal requirements for its market.
Checklist before production
Before giving an AI agent send access, verify:
- which wallets the agent can see;
- which assets and networks are allowed;
- which per-transaction and daily limits apply;
- which destinations are on the allowlist;
- when manual review is required;
- who can approve or pause the flow;
- where the Co-Signer runtime is stored;
- whether secrets can enter prompts or logs;
- how idempotency works for retries;
- which WebSocket events the product listens to;
- how ledger records reach finance;
- what happens during failed or stuck transactions.
If these answers are not documented, the agent is not ready for autonomous sending.
FAQ
Can an AI agent send crypto transactions?
Yes, but only through a controlled flow. The agent should create a send intent or signed API request, not receive a private key. The policy layer, Co-Signer, and MPC signing should determine whether the transaction can be signed.
Does the agent need a private key?
No. Private keys, seed phrases, MPC shares, and recovery material should stay outside prompts and model context. The agent only needs scoped API access and status visibility.
Why is an idempotency key required?
An idempotency key protects against duplicate sends. If a network or API request retries, infrastructure should know that this is the same business action, not a new payout.
What does the Co-Signer check?
The Co-Signer should check asset, network, amount, velocity limits, destination allowlist, permissions, business reference, emergency pause, and applicable compliance state.
When is manual review needed?
Manual review is needed for new destinations, high amounts, unusual withdrawals, incomplete compliance data, or an intent that does not match business context.
How do you track transaction status?
The product or agent runtime should listen to WebSocket events and read ledger records. Useful states include intent_created, policy_reviewed, approved, mpc_signing, broadcast, confirmed, failed, and manual_review.