Hyperliquid Agent Wallets Explained: What You're Actually Approving (and Is It Safe?)

Connect a wallet to almost any third-party Hyperliquid frontend — a trading terminal, a copy-trading tool, a bot, Hyperhelm — and before you can place a single order you will be asked to sign something called approveAgent. A large share of Hyperliquid's daily active traders now trade through third-party interfaces, which means this signature has quietly become one of the most-signed approvals in DeFi. It is also one of the least understood.

The popup is asking you to authorize an agent wallet (the docs also call it an API wallet): a separate key that will sign your orders from now on. Most people click through it the way they click through cookie banners. That is a mistake in both directions — the approval is far safer than a blind signature deserves, and slightly more dangerous than 'it can't withdraw' suggests.

This article explains exactly what an agent wallet can and cannot do, where the real risk sits, and the hygiene that makes it a non-issue.

An agent wallet is a fresh keypair that gets registered against your Hyperliquid account, on-chain. It holds no funds. It is not a smart contract with an allowance over your tokens. It is a signing permission: 'orders signed by this key count as orders from my account.'

Why does Hyperliquid need this at all? Because on Hyperliquid every order, cancel, and leverage change is a signed action processed by the chain. If apps used your master key for that, your main wallet key would have to live hot inside a browser tab, signing dozens of actions per session — and a popup for every single order would make an order-book venue unusable. Bots and automated strategies have the same problem: they need to sign continuously, and nobody should paste their master private key into a script.

The agent-wallet pattern solves both: your master key signs once to delegate, then goes back in its drawer. The agent key does the repetitive signing — scoped, replaceable, and disposable by design.

Hyperliquid's protocol splits actions into two classes, and the split is the whole security model.

An approved agent can sign the trading surface:

• Place and cancel orders (including TP/SL trigger orders)

• Adjust leverage and margin mode on positions

• Manage the ongoing life of your positions

It structurally cannot sign what Hyperliquid calls user-signed actions — the protocol only accepts these from your master wallet:

• Withdrawals to your address on another chain

• Sending USDC or spot assets to any other address

• Approving new agents (an agent cannot mint itself successors)

• Approving builder fees (the fee cap third-party apps charge)

The distinction is enforced by protocol validation, not by app policy. Compare that with a centralized-exchange API key where 'withdrawals disabled' is a checkbox in the exchange's backend — a policy that the exchange applies on your behalf. On Hyperliquid, a withdrawal signed by an agent key is not a forbidden request; it is an invalid one. There is no admin panel where that rule could be misconfigured.

'It can't withdraw' is true, and it is not the same as 'it can't hurt you.' If an agent key leaks — malicious frontend, compromised device, sloppy bot infrastructure — the attacker can still trade your account. That has real attack surface:

• They can open oversized, max-leverage positions and let the market do the damage.

• They can trade your account against their own resting orders — crossing the spread from your side to theirs — bleeding your balance into theirs through fills that are technically just trades.

• They can simply burn your capital through fees and churn.

Your funds cannot leave your account, but they can be lost inside it. So the correct mental model is: an agent approval is custody-safe but not harm-proof. The docs' own design implies this, and ecosystem security guides say it outright — which is why expiry timestamps on agent approvals exist.

The practical mitigations are simple: approve agents only for frontends you have reason to trust; prefer approvals with an expiry; use one agent per app rather than reusing keys; keep experimental bots on a sub-account with a small balance; and revoke what you no longer use. Each of those cuts the blast radius of a leak to something survivable.

Hyperliquid bounds how many agents can exist and for how long:

• One unnamed agent plus up to three named agents per account (sub-accounts get two additional named agents each). Named agents are just agents registered with a label, so different apps can coexist without overwriting each other.

• Named agents support an expiry: the approval can carry a valid-until timestamp, after which the agent is pruned automatically. If an app offers a validity period, use it — an approval that expires in 30 days is strictly better than one that lives forever.

• Approving a new unnamed agent deregisters the previous unnamed one — replacement is revocation. The same applies to a named agent re-approved under the same name. You can review and manage what is currently approved from the API section of the official Hyperliquid app.

One sharp edge worth knowing: agent addresses should never be reused. Once an agent is deregistered and its nonce history is pruned, previously signed actions could in principle be replayed against a re-registered identical address. Well-built apps generate a fresh agent key every time — if you are building your own bot, do the same.

Hyperhelm uses exactly this mechanism, with the conservative defaults you would hope for. When you connect, an agent key is generated client-side, in your browser — it never touches our servers, and there is no backend that could leak it. The agent signs your orders locally; the protocol guarantees it can trade and nothing else. Withdrawals, transfers, and any new approvals still require your master wallet, in your hands.

On top of the protocol's boundary, Hyperhelm adds its own: the risk governor. Every order the agent signs has already passed through a gate that caps size and leverage for the current regime — so even the trading permission the agent does have is exercised under constraint, and every decision is logged.

That is the right layering for anything that touches real money: the chain enforces what an agent may sign, the governor constrains what it should sign, and you keep the master key. If you want to see what a governed agent looks like in practice, the cockpit is free to open — the approval only appears at the moment you choose to execute.