HYBRID DEVNET · PUBLIC EVIDENCE LIVEVerifiable infrastructure for value, markets, identity, and operational dataInspect the network

Products & integrations

Does an allowed AI Wallet Control result send a payment?

3 min read

No. The public decision-only preview supports policy reads and intent evaluation. An allowed evaluation is not construction, reservation, approval, signing, or broadcast of a payment, and it does not promise later execution will succeed.

An evaluation answers a policy question

AI Wallet Control’s public decision-only preview examines a proposal in its permitted context. An allowed result means the evaluation produced that decision under the relevant conditions. It is useful information for review, but it is not a transaction receipt. The agent has not thereby reserved money, obtained all required approvals, or sent funds. A user interface should name the result as an evaluation so an ordinary reader does not mistake it for a completed purchase.

Why the separation is useful

A business can test proposed behavior before introducing financial execution. It can inspect decision reasons, try allowed and denied proposals, and check whether the approved identity and policy context are being used. This makes the assistant’s role easier to govern. It also avoids handing an agent a private key simply because it needs to reason about spending. Knowledge of a budget and permission to propose an action are different from authority to spend that budget.

Treat any later execution as a separate workflow

If an enabled integration later performs a financial action, it must satisfy its own current requirements. The asset, recipient, policy, available balance, and permission context may have changed since an earlier evaluation. Do not cache an allowed decision as unrestricted future authority. During a pilot, keep the evaluation result and the proposed details together, and demonstrate that a denied or incomplete proposal cannot silently become a payment. The public preview should remain clearly labeled as decision-only throughout that test.

In plain language

Permission, signing, and completion are different

Think of a business bank payment: preparing the instruction, approving it, and seeing it complete are separate events. A wallet workflow also has distinct responsibilities. Authorization means the required person or policy permits a particular action. Signing means the participating systems produce the cryptographic signature needed for that action. Completion means the relevant system has accepted or settled the result under its rules. A screen displaying a wallet, or a service responding successfully, does not combine these steps into one. In Hybrid-Chain, customer authorization is separate from distributed signing participation. When reviewing a status, ask which of these stages it describes, which asset and network it concerns, and whether the evidence is current. This distinction helps prevent a common mistake: treating an informational record as permission to move money. An operator should be able to explain the stage in ordinary language without asking you to share any secret material.

In plain language

An example is not a production result

The examples in this FAQ explain how to think about a workflow. They are not reports of customer results, guarantees of performance, or instructions to use real funds. A useful evaluation starts with agreed access, a non-production environment where appropriate, and data that you are permitted to use. Decide in advance what a pass looks like and what must be refused. An allowed case alone is not enough: the team should also try an unauthorized request, a missing requirement, or an unavailable dependency where the test scope permits it. Keep the result and its context so someone else can understand what was demonstrated. Passing that test provides evidence for the tested combination of product, configuration, and environment. It does not automatically enable a different operation or network. Moving to production should be a separate, explicit decision with the required owners involved.

What to do next

Use the evaluation guide to test both permitted and rejected proposals while keeping execution separately authorized.

First evaluation guide ↗AI Wallet Control ↗