Model context is not a secret store
An AI agent MPC wallet should not start with a private key in the prompt. If the model can read a seed phrase, API private key, encryption key, or MPC share, the team has already crossed the wrong control boundary. The agent may help create wallets and prepare transactions, but the signing material must live in protected runtime infrastructure outside chat history, logs, and tool output.
This matters because the phrase "AI wallet" sounds deceptively simple. A user asks the agent to create a wallet, receive funds, and send transactions. A demo can solve that by printing a key. A production system cannot. Once an autonomous process can move value, the buyer problem changes from "how do I create an address?" to "where does authority live, who can approve a send, and how do we prove what happened?"
For BroLabel, the safer answer is to connect the agent to BroLabel AI Agents, BroSettlement, and Agent Skills. The model forms intent. Scoped API access, customer-hosted Co-Signer policy, MPC signing, WebSocket events, and the ledger enforce the boundary.
Short Answer
Yes, an AI agent can help create and operate an MPC wallet, but the private key should never be placed in the prompt. A safer architecture keeps secrets in protected runtime infrastructure, uses scoped Ed25519 API keys for automation, runs a customer-hosted Co-Signer for local policy checks, completes MPC/DKG readiness, and lets the agent send only structured transaction intents through idempotent API requests, WebSocket events, and ledger tracking.
Why private keys in prompts are the wrong model
A prompt is an instruction surface, not a custody system. It may be stored in conversation history, copied into traces, used in tool calls, summarized, replayed, or inspected by people and systems that should not have signing authority. Even if a specific product says it protects data, the operational lesson remains the same: model context is the wrong place to put secrets.
There are three different categories that teams often mix together:
- Instruction. What the agent is asked to do.
- Authorization. What the agent is allowed to call or request.
- Signing authority. What can actually move assets.
Those categories should not collapse into one prompt. A good agent can understand the instruction: "create a testnet wallet and prepare a USDT send." It can use authorization through a scoped API identity. But signing authority should remain outside the model and pass through policy, MPC, and audit records.
The same rule applies to seed phrases and API secrets. A seed phrase in a chat window is not self-custody; it is leaked custody. An API private key pasted into a prompt gives the model a reusable credential that may be logged, copied, or misused. MPC share material is even more sensitive because it participates in threshold signing.
Model context vs protected runtime
The safest architecture separates what the agent may reason about from what the infrastructure may sign.
| Layer | What belongs there | What must not live there |
|---|---|---|
| Model context | Task description, wallet label, network choice, asset, amount, destination, business reason | Private keys, seed phrases, API private keys, encryption keys, MPC shares |
| Agent tool runtime | Signed API request creation, validation helpers, idempotency keys, status reads | Long-lived unscoped secrets, raw wallet keys, hidden policy overrides |
| BroSettlement API | Wallet creation, address generation, transaction intent, status, ledger records | Customer MPC share material |
| Customer-hosted Co-Signer | Local policy, approval logic, MPC participation, protected persistent volume | Model instructions that can change limits by themselves |
| Finance and operations layer | Ledger review, reconciliation, exception handling, support visibility | Unexplained on-chain activity without internal owner or reference |
This separation makes the agent useful without making it sovereign over funds. It can prepare the request, explain the result, retry safely with idempotency, and surface status. It cannot silently bypass the signing boundary.
How an AI agent can use an MPC wallet safely
A controlled agent wallet flow starts before the first address is created.
- The team defines the use case: receive deposits, pay vendors, test x402-style payments, operate a service wallet, or support a user workflow.
- The agent uses Agent Skills rather than improvised instructions.
- The operator creates or grants access to a BroSettlement organization.
- Automation receives scoped Ed25519 API access, limited to the actions it needs.
- A customer-hosted Co-Signer runs outside model context and keeps protected state.
- MPC/DKG readiness is completed before any wallet is treated as signable.
- The agent creates or selects a wallet and generates a deposit address.
- For sending, the agent creates a structured transaction intent with wallet, network, asset, amount, destination, business reference, and idempotency key.
- Co-Signer policy evaluates the request before signing.
- The team tracks created, rejected, signed, broadcast, confirmed, and failed states through WebSocket events and the ledger.
The important part is that the agent is not "holding the wallet." It is operating through infrastructure that decides what can actually happen.
What scoped API keys solve, and what they do not
Scoped API keys are useful because they turn a broad instruction into a controlled capability. An AI agent may need to create a wallet, read balances, generate deposit addresses, or submit a transaction request. Those permissions should be explicit and narrow.
But API keys do not replace wallet signing controls. A scoped Ed25519 API key can authenticate a request to BroSettlement. It should not be confused with the private key of the wallet itself. If the transaction requires signing, the request still needs to cross Co-Signer policy and MPC signing.
Good API access has a few properties:
- Least privilege. The agent only gets the actions it needs.
- Rotation. Credentials can be replaced without rebuilding the wallet.
- Separation by agent. One automation should not share unrestricted credentials with every other workflow.
- Auditability. The team can see which API identity requested which operation.
- No prompt storage. Private key material for API signing should be handled by tooling or runtime, not pasted into model text.
This is why the "private key in prompt" shortcut is so fragile. It skips both authorization design and signing design.
Co-Signer policy is the control boundary
The Co-Signer is where autonomy meets policy. The model may decide that it should send a payment. The Co-Signer decides whether that request is allowed to become a signature.
For an AI wallet, policy should cover at least:
| Policy area | Example control |
|---|---|
| Asset | Allow USDT or USDC, block unsupported assets |
| Network | Allow only approved networks for the agent |
| Amount | Cap single transaction size |
| Velocity | Limit total spend per hour, day, or week |
| Destination | Require allowlist or risk check for outgoing addresses |
| Business reason | Require invoice, customer, workflow, or ticket reference |
| Approval path | Auto-approve low-risk sends, route exceptions to a callback or human |
| Emergency pause | Stop agent-initiated sends without deleting wallet infrastructure |
These rules should live in controlled infrastructure, not only in an instruction like "please do not overspend." Prompts are guidance. Policy is enforcement.
What never goes into the prompt
The short rule is simple: if it can move money or unlock signing, it does not belong in the model context.
Do not paste:
- wallet private keys;
- seed phrases;
- API private keys;
- encryption keys;
- MPC share files or recovery material;
- Co-Signer persistent volume contents;
- admin credentials;
- allowlist override secrets;
- emergency recovery credentials.
Also avoid indirect leakage. Do not ask the agent to print secrets for debugging. Do not store signing material in logs. Do not include private key paths in public issue trackers. Do not let the agent upload runtime folders to an unrelated repository. Do not allow a tool call to expose environment variables in plain text.
The agent can know that a key exists and that a Co-Signer is healthy. It does not need to see the key.
BroLabel fit
BroLabel AI Agents and BroSettlement are designed around this boundary. The agent can work with official Agent Skills, API operations, wallet setup, event status, and operational checks. The sensitive pieces remain in infrastructure designed for signing and audit, not in the model.
That makes the product fit strongest for teams that need an agent to perform real wallet operations but still want finance-grade records and controls:
- AI products that let agents pay for services or receive funds.
- Developer platforms testing agentic commerce or x402-style flows.
- Fintech teams that want wallet automation without raw key exposure.
- iGaming, neobank, or payment teams that need event visibility and reconciliation.
- Internal automation teams that want a safe testnet-to-production path.
BroSettlement does not remove the operator's regulatory responsibilities. KYC/KYB, AML, Travel Rule handling, licensing, and jurisdiction analysis still need the right processes and integrations. What it does provide is a cleaner control model for wallet creation, transaction requests, signing boundaries, events, and ledger history.
Getting started checklist
Before giving an AI agent wallet access, check this list:
- Define the exact wallet use case and maximum allowed actions.
- Use official Agent Skills rather than ad hoc setup instructions.
- Keep all private keys and MPC material outside prompt and model context.
- Create scoped Ed25519 API access for the agent.
- Run the Co-Signer in a protected customer-controlled environment.
- Complete MPC/DKG readiness on testnet.
- Define asset, network, destination, amount, velocity, and approval policies.
- Require idempotency keys for transaction requests.
- Subscribe to WebSocket events for deposits, sends, failures, and confirmations.
- Verify ledger records with finance or operations before production funds.
If any of these checks are missing, the issue is not that the agent is too weak. The issue is that the control boundary is not ready yet.
FAQ
Can an AI agent create an MPC wallet?
Yes. An AI agent can guide setup and call wallet infrastructure through approved tools and scoped API access. It should not generate or hold the wallet private key in the prompt.
Does the agent need a private key?
No. The agent needs controlled permissions to request wallet actions. Signing authority should stay in MPC and Co-Signer infrastructure outside model context.
What is the difference between an API key and a wallet private key?
An API key authenticates a request to infrastructure. A wallet private key or MPC share participates in signing transactions. They should be treated as different security layers.
Why use a Co-Signer for AI agents?
The Co-Signer enforces policy before a transaction is signed. It can check limits, destinations, assets, velocity, and approval rules even when the model wants to proceed.
Can this work on testnet first?
Yes. The safer path is to create a testnet wallet, run the Co-Signer, complete MPC/DKG readiness, test receive and send flows, and only then discuss production settings.
What should the team monitor after launch?
Monitor transaction intents, Co-Signer decisions, signed requests, broadcasts, confirmations, failures, balances, and ledger records. AI wallet operations should never become a black box.