AI Wallet Control

AI agent spending controls.
Give every proposal a policy check.

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.

Policy decisionDoes this intent fit the rules?
  1. Agent proposal
  2. Budget & permissions
  3. Decision reasons
Illustrative workflow · availability and access controls apply
A familiar challenge

An agent proposes a payment. Before anything moves, your team needs to understand whether that proposal fits its permissions and budget.

A more useful way forward

Inspect a decision with reasons. This preview does not approve, reserve, sign, or broadcast a payment.

See a practical example ↓
Why it matters

Make agent spending decisions understandable.

For agent-platform, purchasing, and treasury developers.

Bound the request

Associate a workload with the wallet context and permitted actions it is allowed to request.

Inspect the decision

Evaluate a typed intent against the applicable policy instead of treating a model’s output as spending authority.

Keep execution separate

An allowed evaluation does not reserve a balance, approve a payment, create a signature, or broadcast a transaction.

Core capabilities

The capabilities behind the outcome.

Match these capabilities to your workflow. Enabled operations and access are confirmed during integration planning.

  • Workload identity & wallet context

    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.

  • Versioned wallet policies

    Read current and historical policy commitments to understand which controls govern a proposal. Reading a policy does not grant permission to replace it.

  • Native-asset budget inspection

    Review per-asset budget state before evaluation. Preserve exact decimal amounts; balances in different assets are not interchangeable or a combined fiat spending allowance.

  • Side-effect-free intent evaluation

    Submit a typed proposal to check policy admission without creating an intent, reservation, event, approval, transaction, signature, or broadcast.

  • Decision reasons & retained history

    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.

  • Execution-readiness review

    Inspect the available execution mode and readiness evidence. A policy-approved record is not signing authority or proof that funds moved.

How AI Wallet Control works

A proposal is not a payment.

  1. 01
    Read the agent’s context

    Inspect the authenticated workload binding and policy context for the intended wallet and network.

  2. 02
    Evaluate the intent

    Submit a typed proposal to the documented evaluation contract. Review its decision and reasons against the configured controls.

  3. 03
    Use the result responsibly

    Show the result to your application or reviewer. Any future funds-moving step needs separately available authorization and execution controls.

Where this fits

Give the agent a task—not the final say over spending.

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.

Evaluation checklist

Suggested tests—not recorded customer results. Run them only with agreed access and representative non-production data.

Evaluate an in-policy proposal

Expected result
Inspect the decision and reasons; do not label the proposal paid or approved.
Evidence to retain
The exact test intent, relevant policy/budget context, and returned evaluation reasons.

Test a disallowed proposal

Expected result
For a disallowed destination or amount, the decision explains the violated control without executing a payment.
Evidence to retain
The rejected scenario and the policy reason returned by the deployed contract.

Repeat an evaluation

Expected result
Confirm that evaluation does not create a balance reservation, signature, or transaction.
Evidence to retain
Before/after state checks using authorized reads—not just a screenshot of an allowed result.
Where to start

Three useful pilots.
One explicit spending boundary.

Illustrative evaluation workflows—not claims of autonomous payment execution or customer deployments.

Purchasing assistants

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?

Treasury copilots

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?

Agent-platform builders

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?

For your integration team

Put a policy check between intent and action.

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.

Explore the AI Wallet Control API
1. Discover the permitted binding
Read wallet bindings

Use the context returned for your principal. Do not let the agent select a different workspace or role in a request.

2. Inspect policy and budget
Review the native-asset budget

Read current policy and preserve exact decimal amounts. Treat missing or unverifiable context as a reason to stop.

3. Evaluate, explain, and re-check
Evaluate a proposed intent

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.

Start with this guide

Evaluate your first agent spending proposal

Walk through AI wallet binding, policy and budget reads, then test permitted and rejected agent proposals without moving funds.

One useful first evaluation.

Follow the worked example, inspect the current contracts, and use the failure cases and checklist to review your own results.

Read the practical guide
Decision-only preview

Plan your first deployment.

The 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.

Before your first integration

  • Choose representative allowed and denied spending intents.
  • Test budget and destination policy decisions with the intended binding.
  • Keep evaluation separate from approval, signing, reservation, and broadcast.
Open workspace
Questions before you build

AI Wallet Control, explained.

How is AI Wallet Control different from an MPC wallet?

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.

Does my agent need a private key to evaluate a proposal?

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.

Can I create bindings or change spending policies through the preview?

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.

Can my agent pay autonomously through this public API?

Not through the current decision-only milestone. Start with policy reads and evaluation; request explicit execution availability if your launch depends on autonomous payments.

Which controls should a pilot test?

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.

Does an allowed result guarantee execution later?

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.

What should we agree before starting a pilot?

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.

Explore the technical architecture and walkthroughs

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

From agent policy to a safe evaluation.

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.

  1. Read the binding and policy

    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
  2. Inspect the native-asset budget

    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
  3. Evaluate without executing

    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
Start with one useful result

Your evaluation should produce…

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.

Discuss your deployment
Build the next part of your workflow

Connected products.

Start with AI Wallet Control. Review these adjacent capabilities when your requirements call for them.

Hybrid Cortex

Share selected knowledge, discover business needs, and build accountable connections.

Explore Hybrid Cortex