Agent Wallets and Scoped Permissions: What Non-Custodial Actually Guarantees

Whose keys does the agent hold? That is the live question of August 2026 in AI trading, and "non-custodial" is the answer every product page now gives. MetaMask launched its Agent Wallet on August 6, 2026 with EVM and Hyperliquid support,¹ Coinbase shipped Agentic Wallets, and OSL announced AgentPay on August 10,² each promising that the agent leaves custody with you. The word is doing more work than one word can. Four different arrangements sit behind the same label, and they differ on the only thing that matters when something breaks: whose keys can move the funds, and under what limits. This page maps the four arrangements, states what the agent can and cannot do inside each, and turns the marketing word into questions you can test before capital moves. The search behind it is usually some form of "can an AI trading agent withdraw my funds," and the honest answer is a mechanism, not an adjective.

Evidence boundary: This page describes custody mechanisms as published by vendors and venues, and links DXRG controls research where a policy layer changes what a scoped key means. Documentation describes intended behavior, and no mechanism description here establishes that a specific deployment is configured correctly, profitably, or safely.

The Word Hides a Spectrum

Custody answers three mechanical questions: who holds the keys, what those keys can sign, and who can take that power back. The 2026 label "non-custodial" covers arrangements that answer all three differently, and we count four in current products, ordered by how much of the guarantee still depends on a company. The differences decide what breaks when the agent misbehaves, when the vendor vanishes, or when a credential leaks.

The first arrangement is custodial broker rails. Robinhood's Agentic Trading, launched May 27, 2026, connects ChatGPT and other models to a ring-fenced brokerage account through the Model Context Protocol (MCP).³ The broker holds the account and the model holds nothing: it proposes orders through typed functions, and the broker's confirmation layer decides what reaches the market. The agent can read the ring-fenced account and place orders inside it. It has no path to funds outside that account, because it holds no keys at all. If the integration disappeared tomorrow, the account would still be a brokerage account: you log in yourself and withdraw, under the usual custodial protections and the usual custodial risks. What you trust is the broker: its solvency, its confirmation layer, and its perimeter around the ring-fenced funds.

The second arrangement is the API-key bot, the oldest wiring in retail automation. You create an API key on a centralized exchange, enable trading, leave withdrawals disabled, and hand the key to a bot platform or a script of your own. The exchange still holds the funds; the key is a bearer credential that scopes what the bot may ask the exchange to do. A trade-only key cannot withdraw through the API, and that is the sentence the marketing quotes. The sentences it skips matter more. Scopes vary by exchange, keys leak through logs and compromised vendors, and a leaked trade-only key can still drain an account economically: the attacker trades your balance into a thin token they are selling. If the bot vendor disappears, you revoke the key at the exchange and nothing else changes. What you trust is the exchange as custodian, plus your own key hygiene, plus every machine the key ever touched.

The third arrangement is the smart account with session keys. Funds sit in an onchain account you control, commonly a Safe smart account, and the agent receives a session key: a delegated credential that signs only a defined set of actions under limits encoded onchain. MetaMask's Agent Wallet, generally available since August 6, 2026, productized this pattern for EVM chains and Hyperliquid with scoped delegations and spend limits.¹ The agent can sign exactly what the delegation allows. A delegation covering swaps on one venue carries no transfer power to arbitrary addresses, and the agent cannot widen its own scope. Revocation is a transaction you send, or one a watchdog you authorize sends, and it works while the chain works, whether the vendor's servers are up or down. What you trust is the smart account's code, the delegation's scope as actually encoded, and your own readiness to revoke.

The fourth arrangement is the venue-native agent wallet. Hyperliquid's mechanism issues agent keys at the venue itself: an agent key signs orders on the master account's behalf, it carries no withdrawal or transfer path, and the master account revokes it with one signed action at the venue.⁴ The funds stay in your account on the venue, and the agent's authority lives inside the venue's permission system rather than in a contract you deploy. The agent can trade, and that is the entire permission. If the tooling around the agent disappeared, you would revoke the key at the venue and the funds would stay where they were. What you trust is the venue: its matching engine, its permission layer, and its solvency, because the funds sit on it.

The custody spectrum: four arrangements behind the non-custodial label, and what the agent's credential can actually do in each

Read the spectrum as a gradient of where the guarantee lives. At the top, the guarantee is a company's promise and its perimeter. In the middle, the guarantee is a credential's scope, enforced by a custodian or by a chain. At the bottom, the guarantee is the venue's own permission code. Each step down depends less on a vendor's continued operation and more on mechanisms you can inspect, and each step also moves responsibility toward you: an onchain revocation you never send is a revocation that never happens.

What Each Arrangement Allows

The four rows of the spectrum, compressed:

Four Questions That Make Custody Testable

Marketing answers "is it non-custodial" with yes. The separating questions are mechanical, and each has an answer you can verify in the product itself before depositing.

1. Can the agent move funds anywhere but the venue? The honest answer names a mechanism: withdrawals disabled at the exchange, a delegation with no transfer action, or a venue key with no withdrawal path. If the answer is a sentence about the team's intentions, treat the arrangement as custodial whatever the label says. Verify it on the exchange's API-key page, in the delegation's encoded scope, or in the venue's documentation.
2. Can the agent change its own limits? In a sound arrangement the answer is no by construction: an API key cannot edit its scopes, a session key cannot widen its delegation, and a venue agent key cannot grant itself withdrawal rights. If the agent can renegotiate permissions through the same channel it trades on, the limits are decoration.
3. Who can revoke, and does revocation depend on the vendor's uptime? Exchange keys die at the exchange, venue keys die at the venue, and session keys die onchain. The first two need the custodian alive; the third needs the chain alive. If revocation routes through the bot vendor's dashboard alone, the vendor belongs on your failure map.
4. What does a signature actually authorize? Every tier ends in a signature somewhere: an HMAC against an exchange API, an EIP-712 typed delegation, an agent-key approval at the venue. Reading what a signature covers, before signing it, is the custody review. An unread scoped permission is an unscoped one.

Why a Scoped Key Still Needs a Policy Engine

A scope is a ceiling, and everything under the ceiling is allowed. A trade-only key with nothing around it permits any trade the venue offers: any size, any frequency, any instrument in scope. The difference between a trading agent and a trading accident is what happens between the model's output and the signed action.

That gap is the layer our work builds and measures. In our stack, the owner's mandate compiles into an explicit contract, and every proposed action is checked as a typed object against deterministic policy before execution, with the whole path recorded in one trace. The guardrails article describes that system in engineering form, and the guardrail matrix dataset (CSV) maps each control to its evidence requirement and failure signal. The mandate compiler article covers how owner intent becomes the contract our policy engine enforces.

The measured difference is behavioral. In controlled pre-launch tests from the DX Terminal Pro record, an intervention that demoted prior reasoning from precedent to context cut fabricated sell rules from 57% to 3% in the affected population.⁵ Same credential scope, same model, different policy context, different behavior. A trade-only key plus a policy engine is a different product from a trade-only key alone, and the second is what most non-custodial marketing is actually selling.

The regulatory seam runs through the same gap. In our response to the FSB's agentic AI consultation, we argue that accountability for a transaction-capable agent attaches to whoever controls the mandate and the policy around it, precisely because a key's scope alone says nothing about what the agent will attempt inside that scope. Scope limits what can happen. Policy governs what does happen. The first comes from the custody arrangement; the second comes from the harness.

The Custody Checklist

Reduced to a pre-deposit routine, the custody question becomes five checks we run before capital moves:

1. Where do the funds sit, and whose key can move them?
2. What is the agent's credential scoped to do, and where is that scope enforced: exchange configuration, onchain delegation, or venue permission?
3. Can the credential withdraw, transfer, or change its own limits?
4. How do we revoke, and does that path work while the vendor is offline?
5. What sits between the model's output and an order: a broker confirmation layer, a deterministic policy engine, or nothing?

A product that answers all five cleanly is engineered. A product that answers with adjectives is asking you to underwrite its custody risk blind.

The Bottom Line

Non-custodial guarantees exactly what the credential's scope guarantees, and each tier scopes differently. Broker rails keep the model away from keys entirely while leaving you in a custodial account. Exchange API keys keep withdrawals off the API while leaving the exchange as custodian and the key as a leakable secret. Session keys and venue agent wallets put the scope in code, onchain or at the venue, and turn revocation into a transaction instead of a support ticket. None of these arrangements decides whether the agent trades well; our evidence series on Claude and ChatGPT covers that measured record. What the arrangement decides is the worst case: whether a confused model, a leaked key, or a dead vendor can move your funds somewhere you never authorized. Ask for the mechanism behind the label, and read the scope before the pitch.

Version 1.0. Published August 20, 2026. Corrections: poof@dxrg.ai. This article is research and educational material, not financial advice.

Footnotes

1. MetaMask, Agent Wallet launch, generally available August 6, 2026 with EVM chain and Hyperliquid support. Scoped permissions are delegated onchain. (metamask.io) ↩ ↩²

2. OSL, AgentPay announcement, August 10, 2026. (osl.com) ↩

3. Robinhood, Agentic Trading, launched May 27, 2026: customers connect ChatGPT and other models to a ring-fenced brokerage account through the Model Context Protocol. (robinhood.com) ↩

4. Hyperliquid documentation, agent wallets: trade-only keys that sign orders for the master account, cannot withdraw, and are revocable at the venue. (Hyperliquid docs) ↩

5. Barton, T.J. et al., Operating-Layer Controls for Onchain Language-Model Agents Under Real Capital, arXiv:2604.26091, 28 April 2026. (arXiv abstract) ↩