Bound the request
Associate a workload with the wallet context and permitted actions it is allowed to request.
Your AI agent can identify a purchase or propose a treasury action. That should not give it permission to spend. AI Wallet Control connects an agent’s wallet context, versioned policy, and native-asset budget so your application can evaluate a proposal and explain the decision. The decision-only preview does not sign or send payments.
Decision-only preview · Check the exact operation and deployment.
Inspect a decision with reasons. This preview does not approve, reserve, sign, or broadcast a payment.
See a practical example ↓For agent-platform, purchasing, and treasury developers.
Associate a workload with the wallet context and permitted actions it is allowed to request.
Evaluate a typed intent against the applicable policy instead of treating a model’s output as spending authority.
An allowed evaluation does not reserve a balance, approve a payment, create a signature, or broadcast a transaction.
Match these capabilities to your workflow. Enabled operations and access are confirmed during integration planning.
Discover the Signed Workload Identity binding and independently enrolled operational wallet your authenticated principal can access. Workspace and role come from the bearer—not from the agent’s request.
Read current and historical policy commitments to understand which controls govern a proposal. Reading a policy does not grant permission to replace it.
Review per-asset budget state before evaluation. Preserve exact decimal amounts; balances in different assets are not interchangeable or a combined fiat spending allowance.
Submit a typed proposal to check policy admission without creating an intent, reservation, event, approval, transaction, signature, or broadcast.
Explain the evaluation result in your application. Read the retained intents, activity, and review evidence available to your principal separately; a dry run does not create that history.
Inspect the available execution mode and readiness evidence. A policy-approved record is not signing authority or proof that funds moved.
Public records illustrate inspectable data; they are not customer results or confirmation of production activation.
Inspect the authenticated workload binding and policy context for the intended wallet and network.
Submit a typed proposal to the documented evaluation contract. Review its decision and reasons against the configured controls.
Show the result to your application or reviewer. Any future funds-moving step needs separately available authorization and execution controls.
A prompt can tell an assistant to stay within a budget. It cannot replace the controls around the wallet. AI Wallet Control gives your application a separate place to evaluate the proposed action against the binding’s current policy and native-asset budget. The model supplies a proposal; it does not get to rewrite the rules used to evaluate it.
Suggested tests—not recorded customer results. Run them only with agreed access and representative non-production data.
See how protected data, agent context, and wallet controls fit together.
Illustrative evaluation workflows—not claims of autonomous payment execution or customer deployments.
An agent finds a supplier or service. Before your application considers payment, evaluate the proposed destination, asset, and amount against the binding’s policy and budget.
Pilot question: can your team explain why one proposal fits and another does not?
An agent recommends a movement of funds. Review the wallet context, policy commitment, and per-asset budget without turning its recommendation into spending authority.
Pilot question: what happens when the requested asset or wallet context is wrong?
Keep policy evaluation outside the model’s reasoning loop. Use authenticated workload bindings to evaluate typed requests and return decision reasons to your application or reviewer.
Pilot question: does an out-of-scope request fail closed, even when the agent asks confidently?
Start with an authenticated workspace principal, an existing Signed Workload Identity binding, and an independently enrolled operational wallet. Confirm that provisioning with the team before building against the preview.
Read access uses ai-wallets:read. Dry-run evaluation requires the separate ai-wallets:evaluate scope. Keep credentials server-side and use the deployed API contract for exact request fields.
Use the context returned for your principal. Do not let the agent select a different workspace or role in a request.
Read current policy and preserve exact decimal amounts. Treat missing or unverifiable context as a reason to stop.
Show the decision and reasons. Re-read governing resources before any separately authorized downstream action; a preview result does not lock a budget or guarantee later execution.
Walk through AI wallet binding, policy and budget reads, then test permitted and rejected agent proposals without moving funds.
Follow the worked example, inspect the current contracts, and use the failure cases and checklist to review your own results.
Read the practical guideThe current public milestone is decision-only: authenticated reads and intent evaluation. Transaction construction, approval actions, MPC signing, balance reservation, and broadcast are not exposed by this milestone.
AI Wallet Control evaluates the spending request: its workload binding, wallet policy, and budget context. MPC wallet infrastructure concerns wallet authority and separately enabled signing. A policy result is not an MPC signature, and neither should be treated as settlement evidence.
No wallet private key is needed for this evaluation API. Your integration needs the appropriate authenticated access, an existing workload binding, and an independently enrolled operational wallet. Treat API credentials as sensitive and keep them out of prompts and client-side code.
The current public milestone provides reads and side-effect-free evaluation. Binding lifecycle changes, policy replacement, retained intent creation, and approval actions are not enabled by it. Confirm provisioning and supported operations before planning your integration.
Not through the current decision-only milestone. Start with policy reads and evaluation; request explicit execution availability if your launch depends on autonomous payments.
Use the deployed contract to test permitted actions, network and asset constraints, destinations, amounts, expiry, and relevant budget or velocity rules. Include both acceptable and unacceptable proposals.
No. It is an evaluation result, not an approval, balance reservation, signature, or settlement commitment. State and authority must be checked by any separately enabled execution flow.
Use the product-specific checklist above to define scope and acceptance tests. Ask the team to confirm the deployment environment, access, supported operations, integration responsibilities, support arrangements, and commercial terms. Availability labels are not a pricing quote or a service-level commitment.
Optional deeper reading. Demonstrations are illustrative, not live operational status or a promise of activation. Use the availability guidance above and the current API contract for integration decisions.
DOCUMENTED WORKFLOW · CHECK THE BOUNDARIES
These are integration walkthroughs based on published contracts, not customer case studies or live execution results. Confirm scopes, network readiness, and deployment availability before use.
Use your scoped bearer to discover the agent’s existing binding, then read its effective policy. A visible binding does not grant authority to change it.
GET /api/v2/ai-walletsBinding discovery contract Read the budget for that binding. Keep amounts as exact decimal strings and assets separate; do not interpret a native-asset limit as a fiat spending allowance.
GET /api/v2/ai-wallets/{binding_id}/budgetBudget read contract The separately scoped evaluation checks a typed proposal without creating a reservation, approval, transaction, signature, or broadcast. An allowed decision is not a completed payment.
POST /api/v2/ai-wallets/{binding_id}/intent-evaluationsSide-effect-free evaluation contract A privately retained set of permitted and denied proposals, their actual evaluation reasons, and a clear list of the controls needed before any execution phase.
Suggested evaluation goals—not a pre-packaged service commitment. Agree access, scope, and responsibilities with the team.
Start with AI Wallet Control. Review these adjacent capabilities when your requirements call for them.
Separate wallet authorization from any one signing service.
Explore Native MPC WalletsShare selected knowledge, discover business needs, and build accountable connections.
Explore Hybrid CortexConnect a credential to its issuer, status, and verification history.
Explore Trust Center & Identity