The Co-Signer is the control boundary
An AI agent Co-Signer is not just another service in the wallet stack. For teams that let AI agents create wallets, prepare payouts, or help with treasury operations, the Co-Signer is the line between useful autonomy and unrestricted signing authority.
The agent can read context, prepare a transaction intent, explain a failure, or suggest a next action. It should not hold private keys, MPC shares, API private keys, recovery files, or unlimited permission to move funds. That boundary has to live in infrastructure, not in a prompt.
In BroLabel AI Agents, this pattern connects the agent layer with BroSettlement and Agent Skills. The agent can guide setup and initiate structured requests. The customer-hosted Co-Signer checks policy before MPC signing happens, and the ledger records what was approved, rejected, broadcast, confirmed, or failed.
Short Answer
An AI agent can help operate a wallet, but the Co-Signer should decide whether a transaction is allowed to be signed. A safe architecture keeps the model in the intent and visibility layer, while customer-hosted infrastructure enforces limits, destination rules, approval thresholds, emergency pauses, and MPC signing. The agent proposes; the Co-Signer controls.
Why autonomy needs a separate signing boundary
Agent autonomy feels simple when the task is low-risk: read a balance, create a report, fetch an invoice, or draft a support reply. Money movement is different. A successful mistaken action can become an irreversible transaction.
That is why an AI-wallet architecture needs two separate questions:
- What is the agent allowed to request? This is the agent permission model.
- What is the system allowed to sign? This is the Co-Signer and policy model.
Those questions should not collapse into one permission. If an agent can create a payout request, that does not mean it can sign every payout. If an operator asks for an urgent withdrawal, that does not mean the transaction can skip limits, allowlists, idempotency, or review.
The Co-Signer creates a durable control point outside the model context. Even if the prompt is wrong, incomplete, or manipulated, the signing layer still has to evaluate structured data.
What the agent decides vs what the Co-Signer enforces
The clearest way to design the flow is to split responsibilities.
| Layer | What it can do | What it should not do |
|---|---|---|
| AI agent | Understand the request, gather context, prepare a wallet or transaction intent, explain status | Hold wallet secrets or decide final signing alone |
| API layer | Authenticate scoped automation, validate request shape, enforce idempotency | Treat a signed request as automatic spending approval |
| Policy engine | Check amount, asset, network, role, destination, velocity, and risk state | Depend on natural-language instructions as the only source of truth |
| Co-Signer | Approve, reject, or route to manual review before MPC signing | Stay permanently open to unrestricted agent commands |
| MPC wallet layer | Create signatures without assembling a private key in one place | Expose MPC share material to the agent |
| Ledger and events | Record state changes and publish WebSocket events | Leave finance or support without a traceable status |
This separation is what makes the wallet usable by an agent without turning the agent into the custody layer.
How it works
A controlled AI-agent wallet flow usually looks like this:
- A user, product workflow, or operations system gives the agent a task.
- The agent resolves the business context: account, wallet, asset, network, amount, destination, and reason.
- The agent creates a structured intent instead of a raw transaction.
- The API request is signed with a scoped Ed25519 API key.
- BroSettlement checks request shape, idempotency, balance, and wallet ownership.
- The policy layer evaluates limits, allowlists, velocity, roles, risk state, and review thresholds.
- The customer-hosted Co-Signer approves, rejects, or pauses the request for manual review.
- MPC signing produces a valid transaction signature without exposing a private key to the model.
- The transaction is broadcast to the network if approved.
- WebSocket events and ledger records update the product, support, operations, and finance teams.
The important detail is not that every step is complicated. The important detail is that every step is explicit. An agent should never rely on a vague instruction such as "you can spend up to whatever is reasonable." Reasonable has to become a policy.
Co-Signer policy checklist
Before an AI agent can request sends, the Co-Signer should have a clear decision model.
| Control | Question to answer | Example rule |
|---|---|---|
| Wallet scope | Which wallets can this agent touch? | Only wallets assigned to one product, brand, or treasury profile |
| Asset scope | Which assets are allowed? | USDT and USDC only, or testnet assets only during onboarding |
| Network scope | Which networks are allowed? | Allow TRON or EVM only after operational readiness |
| Amount limit | How much can be sent per action? | Reject over the transaction limit or require review |
| Velocity limit | How much can be sent per hour, day, or week? | Pause if cumulative spend crosses the threshold |
| Destination rule | Where can funds go? | Allowlist required for automatic approval |
| Role rule | Who or what can initiate the request? | Separate support, finance, and automation permissions |
| Idempotency | Is this a duplicate action? | Same business reference cannot produce multiple payouts |
| Business reference | Why is money moving? | Invoice, withdrawal request, case ID, or treasury instruction required |
| Emergency pause | Can the flow be stopped quickly? | Reject all new signing requests while pause is active |
This checklist should be configured before the agent gets any send capability. It is easier to loosen a conservative rule later than to explain a transaction that should never have been signed.
What never belongs in the model context
The model should not become a secret store. Do not place these materials in the prompt, chat history, tools output, logs, or files that the agent can read:
- private keys or seed phrases;
- API private keys;
- encryption keys;
- MPC shares;
- Co-Signer persistent storage;
- recovery files;
- admin credentials;
- unrestricted wallet export data;
- environment variables containing secrets.
The agent can work with scoped actions and visible states: create an intent, read a policy result, check a transaction status, subscribe to WebSocket events, or summarize ledger records. It does not need the signing material itself.
Manual review is a product feature, not a prompt trick
Some teams try to handle risky actions by instructing the model to "ask a human if unsure." That is not enough. Manual review should be a real state in the transaction workflow.
A review screen or operations queue should show:
- wallet and account;
- asset, network, and amount;
- destination address;
- business reference;
- agent or user that initiated the intent;
- policy result and risk reason;
- previous attempts with the same idempotency key;
- approve, reject, and pause actions.
This matters for support and finance. If a payout is delayed, the team needs to know whether it is waiting for policy review, Co-Signer approval, network broadcast, confirmations, or failure handling. WebSocket events and ledger entries make those states visible.
Where BroSettlement fits
BroSettlement fits teams that need wallet autonomy with infrastructure controls. It is not a hosted checkout button. It is API-first wallet, ledger, and settlement infrastructure for products that need to create wallets, receive funds, send transactions, and keep operational records under their own product experience.
For AI-agent use cases, BroSettlement gives the agent a safer operating surface:
- Agent Skills for guided setup and API operations;
- scoped Ed25519 API keys for automation identity;
- customer-hosted Co-Signer for signing control;
- MPC signing without raw private keys in prompts;
- policy controls for amount, destination, role, and velocity;
- idempotent transaction requests;
- WebSocket events for real-time state;
- ledger records for audit and reconciliation.
This infrastructure still needs a clear operating policy from the team. BroSettlement does not remove KYC/KYB, AML, Travel Rule, licensing, or jurisdiction-specific responsibilities. It gives the team a controlled layer where those responsibilities can be enforced instead of improvised inside a chat prompt.
Getting started
Before giving an AI agent wallet authority, map one narrow flow:
- choose a testnet wallet scenario;
- define which agent can request the action;
- create scoped API access;
- run the Co-Signer outside model context;
- define amount, destination, velocity, and review rules;
- require an idempotency key and business reference;
- listen to WebSocket events;
- verify ledger records with finance or operations.
If the first flow cannot be explained in a table, it is too early to automate it with an agent.
FAQ
What is an AI agent Co-Signer?
An AI agent Co-Signer is a customer-controlled signing component that checks policy before a wallet transaction is signed. It lets an agent request an action without giving the model private keys or unrestricted signing authority.
Can the AI agent approve its own transaction?
For low-risk actions, an agent can create an intent that is automatically approved by predefined policy. But the approval should come from infrastructure rules, not from the model deciding that its own request is safe.
Does the Co-Signer replace MPC?
No. The Co-Signer is part of the signing control model. MPC is the cryptographic signing approach that avoids assembling a private key in one place. For agent wallets, the two work together.
Where should the Co-Signer run?
The Co-Signer should run in customer-controlled infrastructure, outside the model context and outside the agent prompt. That allows the customer to enforce its own signing policy and operational controls.
What should trigger manual review?
Manual review should trigger for new destinations, high amounts, unusual velocity, missing business references, changed risk state, incomplete compliance data, or anything outside the normal policy profile.
How does the team audit agent wallet actions?
The product should use ledger records and WebSocket events to track intent creation, policy review, approval, signing, broadcast, confirmation, rejection, and failure states.