Open Wallet Standard (OWS): How AI Agents Sign Transactions Without Exposing Keys

The Missing Signing Layer for AI Agent Wallets

AI agents can read blockchain data, prepare transactions, and orchestrate multi-step DeFi flows. But when it comes to signing — the act of authorizing a transaction with a private key — every agent framework has been building its own approach from scratch. Keys end up hardcoded in environment variables, written into config files, or passed as arguments. From there, they surface in process logs — and, worst, in the LLM's own context window.

The Open Wallet Standard (OWS) is an open-source framework launched in March 2026 by MoonPay that standardizes how AI agents create wallets, manage keys, and sign transactions — across every major blockchain — without ever exposing a private key to the agent process.

OWS is backed by 20 organizations including PayPal, Circle, OKX, Ripple, the Ethereum Foundation, the Solana Foundation, the TON Foundation, the Filecoin Foundation, Base, Polygon, Sui, Arbitrum, Tron, LayerZero, Dynamic, and others. It is available on GitHub, npm (@open-wallet-standard/core), and PyPI (open-wallet-standard). Early traction is visible: the launch hackathon drew 247 submissions, all agent-focused — an early signal that standardized, policy-gated signing is a real bottleneck for agent builders.

Why AI Agents Need a Signing Standard

The problem OWS solves is fragmentation. Before OWS, if you wanted your AI agent to sign a transaction, you had three options — all flawed:

1. Custodial API signing — Send the transaction to a provider (Coinbase, Crossmint) and they sign for you. Simple, but you trust the provider with your funds. A provider compromise, insider threat, or regulatory seizure can result in fund loss.
2. Roll-your-own local signing — Import a crypto library, manage key generation, encryption, storage, and policy enforcement yourself. Every framework re-invents this wheel, and most get it wrong. Keys end up in plaintext env vars.
3. No signing at all — The agent prepares unsigned transactions and signing happens externally — a hardware wallet, a custody provider, or a human-in-the-loop approval step. Safest, but adds latency to every transaction and rules out fully autonomous agent operation.

OWS provides a fourth option: standardized local signing with policy gates. The agent can sign autonomously within predefined constraints — spending limits, approved chains, time windows — while keys remain encrypted on the host where the agent runs and are never exposed to the agent process.

How OWS Works

The OWS vault runs wherever your agent runs — inside your own trust boundary. That matters for infra teams running agent fleets at scale: signing stays a first-class part of your runtime, not a hop out to a custody provider.

Key Generation and Storage

OWS generates a single BIP-39 mnemonic phrase and derives accounts across 10 chain families via BIP-44 derivation paths: EVM (Ethereum, Polygon, Base, Arbitrum, and any EVM-compatible chain), Solana, Bitcoin, Cosmos, Tron, TON, Sui, Spark, Filecoin, and XRP Ledger.

Private keys are encrypted at rest using AES-256-GCM with scrypt as the key derivation function, taking design cues from the widely-adopted Ethereum Keystore v3 format. The encrypted keystore lives at ~/.ows/on the host where the agent runtime executes — your server, VM, or container, never a third party's infrastructure.

OWS v1.3.0 also ships a Ledger hardware wallet integration — the first hardware-signing path for agent wallets. When enabled, the signing step is routed to the connected Ledger device instead of the software keystore: the private key never leaves the hardware element, so even a fully compromised host cannot extract it. This is the recommended configuration for high-value autonomous wallets.

The Signing Path

When the agent needs to sign a transaction, the flow is:

1. Policy evaluation — The OWS policy engine evaluates the signing request against all configured policies before any key is touched. If any policy denies the request, the flow stops immediately.
2. Key decryption — The private key is decrypted from the keystore into protected memory that cannot be swapped to disk (mlock).
3. Transaction signing — The transaction is signed using the appropriate chain-specific signing algorithm.
4. Key wiping — The decrypted key is zeroed out in memory (zeroize) immediately after signing.

The OWS API never returns raw private keys. The agent receives only the signature — never the key material that produced it.

The Policy Engine

Two auth modes, two tiers of access. OWS distinguishes the credential a caller presents:

• Owner mode (passphrase) — full access, used by platform operators for provisioning: creating wallets, minting API keys, registering policies. Policies are not evaluated in owner mode — the passphrase is the capability.
• Agent mode (ows_key_* token) — scoped access for autonomous processes. Each token is bound to policies at creation time; signing is gated on those policies. The token itself doubles as the decryption capability, so a denied request never touches key material.

The production flow — the one running inside your agent fleet — is always agent mode. Owner mode is the bootstrap surface.

Every agent-mode signing request passes through the policy engine before any key is decrypted. Built-in policy types:

All policies use AND semantics — every policy must approve the request. The first denial short-circuits evaluation. Custom executable policies extend the engine: OWS supports an executable field pointing to a script or binary that receives transaction context via stdin and must exit 0 to allow signing.

Every signing operation is logged to an append-only audit trail at ~/.ows/logs/audit.jsonl, recording policy evaluations, simulation results, and transaction hashes.

OWS vs Custodial Signing vs External Signing

How WalletSuite Integrates OWS

WalletSuite's MCP server integrates OWS as an optional signing layer. When enabled, six OWS tools are added across two bands. Three are available to any caller; three additional owner-mode tools let the wallet owner bootstrap the vault, mint scoped agent API keys, and register custom policies — those are gated behind OWS_AUTH_MODE=owner so a runaway agent cannot create new wallets or rewrite policy.

Two Signing Modes

With OWS integration, WalletSuite's MCP server supports two modes — teams choose based on their security requirements:

1. Built-in signing (OWS) — For teams deploying the MCP server into their agent runtime. The full flow is automated: prepare the unsigned payload via the WalletSuite API, sign locally via OWS, broadcast back through the API. No external wallet needed. Enabled via OWS_ENABLED=true.
2. External signing — For teams already signing via custody providers or hardware. The MCP server prepares unsigned payloads; signing happens in MetaMask, Ledger, Fireblocks, or any signing solution the team controls. This remains the default mode.

End-to-End Flow with OWS

When the agent decides to send 1 ETH to 0xdef... — triggered by upstream logic (rebalance, payout, policy evaluation, or a direct operator instruction) — with OWS enabled:

1. The LLM calls get_wallet_address(chain="ethereum") — OWS returns the local wallet address
2. The LLM calls prepare_serialized_unsigned_tx — the WalletSuite API returns a serialized unsigned transaction payload in the format OWS expects
3. The LLM calls send_transaction — OWS evaluates policies (spending limit, chain allowlist), decrypts the key, signs the transaction, broadcasts to the Ethereum network, wipes the key from memory, and returns the transaction hash
4. The LLM calls get_tx_status to confirm the transaction

At no point does the LLM see or handle key material. OWS is a service dependency that runs alongside the MCP server.

Security Considerations

OWS significantly improves the security posture of Model 2 (non-custodial with local signing) compared to roll-your-own implementations. However, it does not eliminate all risk:

• Host compromise — If the signing host is compromised, an attacker with root access could potentially extract keys from the encrypted keystore. Mitigated by running signing on a hardened node — a dedicated VM, locked-down container, or TEE-backed enclave — with least-privilege access and full-disk encryption.
• Policy bypass via prompt injection — A sophisticated prompt injection could attempt to trick the agent into calling sign_transactionwith malicious parameters. OWS policies are enforced outside the LLM's control — the policy engine cannot be influenced by prompts. However, the parameters the LLM passes to the tool are under the LLM's control.
• Spending limit configuration — Policies are only as good as their configuration. A wallet with no spending limit policy is effectively unprotected. OWS stores policies locally at ~/.ows/policies/ — they cannot be overridden by the MCP server or the LLM.

Defense in depth remains the safest approach: WalletSuite's band filtering ensures sign tools are only loaded when explicitly configured. The default band is read— an agent that only needs to query balances never has access to signing tools. Even with OWS enabled, WalletSuite's Claude Code hooks prompt the operator for confirmation before every sign_transaction and send_transaction call.

For applications where maximum security is required, external signing (Model 1) remains the recommended approach. OWS is best suited for autonomous agents operating within well-defined policy constraints.

Frequently Asked Questions

Getting Started

WalletSuite's MCP server includes OWS integration today — enable it with OWS_ENABLED=true. Build your first AI wallet agent starting with the read and prepare flow, or request early access to the hosted MCP server. Design-partner slots are open for teams running agent fleets in production.