Is It Safe to Give an AI Agent Your Exchange API Key?

Short answer: it can be, but only if two things are true. The key must not be able to withdraw funds, and something outside the agent must enforce your trading limits. Most guides stop at the first part. A trade-only key stops an agent from sending your money somewhere else. It does nothing to stop the agent from losing it through trades you never wanted.

This guide covers what can go wrong, what a trade-only key does and doesn't protect, and a checklist to work through before you hand any agent a key.

What can go wrong when an AI agent holds your key

An AI trading agent is a language model that reads instructions and data, decides what to do, and calls an exchange API to do it. Four things can go wrong, and none of them require the agent to be "evil":

1. It makes a mistake. Language models misread numbers, mix up tickers, and hallucinate. A wrong decimal place or the wrong market is a real order once it reaches the exchange.
2. Its code has a bug. A retry loop that re-sends an order, or a sizing function that ignores your balance, executes just as faithfully as correct code.
3. Someone manipulates it. Agents read untrusted text: news, social posts, token descriptions, web pages. Prompt injection hides instructions in that text. In May 2026, an attacker used a Morse-code message on X to get the Grok-linked Bankrbot agent to move 3 billion DRB tokens, worth roughly $150,000–200,000, out of a wallet. Most of it was later returned (OECD.AI incident record). Researchers testing the ElizaOS agent framework found that prompt-based safeguards were "fundamentally inadequate" against these attacks (arXiv).
4. The key leaks. Keys end up in logs, config files, agent memory, and screenshots. Whoever holds the key has the agent's powers.

The question isn't whether these will happen to your agent. It's what the key lets happen when one does.

What a trade-only key protects you from

Every major venue lets you limit what an API key can do, and this is the first thing to get right. One mistake with an over-permissioned key can wipe out months of good trading, or worse.

• Turn off withdrawals. A key without withdrawal permission can't send funds to an outside address. This removes the most direct way to steal from you.
• Use an IP allowlist where the exchange supports it, so a leaked key doesn't work from someone else's machine.
• On Hyperliquid, use an API wallet. Hyperliquid's API wallets (also called agent wallets) can trade on behalf of your account but have no withdrawal permission (Hyperliquid). Withdrawals need a separate signature from your main wallet, and you can revoke an API wallet at any time.
• On Robinhood, use an Agentic account. Robinhood's Agentic Trading gives an outside AI agent its own dedicated account, and the agent can only place trades in that account (Robinhood). Fund it with only what you want the agent to trade. Trade approvals are off by default for outside agents, so unless you turn them on, it can place trades without your confirmation (Robinhood).
• On Binance, use the Agentic sub-account. Binance's MCP server puts the agent in a dedicated sub-account, "isolated from your main account", and there is "no withdrawal scope" (Binance). Fund it with only what you want the agent to trade.
• Check the key can't change its own settings. On some exchanges, a key with transfer or withdrawal permission can rewrite its own permissions and IP allowlist through the API (Bybit). Give the agent a key that can't.

Do all of this. It's necessary. But it isn't enough.

What a trade-only key doesn't protect you from

A trade-only key limits where money can go. It doesn't limit what the agent does with it. With trading permission alone, a confused, buggy, or manipulated agent can still:

• Open a position far larger than you intended, at whatever leverage the venue allows.
• Trade a market you never meant to touch, including thin, volatile ones.
• Buy an illiquid asset at an inflated price, which moves your money to whoever sold it to you.
• Close the hedge that was protecting the rest of your portfolio.
• Trade over and over, paying fees and slippage on every round trip.

The illiquid-asset case isn't hypothetical. In March 2018, attackers who had phished Binance logins created trading API keys on the victims' accounts. They used those keys to sell the victims' Bitcoin and buy Viacoin they had positioned in advance, pushing VIA up roughly 10,000% in minutes. They never needed withdrawal access. Binance's systems blocked the withdrawals, but Binance later said it was "not in a position to reverse those trades", and some users lost funds (Trend Micro, Vice). In 2022 the same trick was run at scale with API keys leaked from the trading-bot platform 3Commas: $22–27 million lost, almost all of it through trades on users' own accounts (ForkLog).

An autonomous agent recreates that risk without any attacker. It holds a trading key, it acts on text it reads, and it runs while you sleep.

Why rules in the prompt aren't limits

The common fix is to tell the agent the rules: "never use more than 3x leverage", "never risk more than 5% per trade". That helps when the agent is working well. It fails in exactly the situations above. A model that misreads a number can misread the rule. A bug in the sizing code doesn't read the prompt. A prompt-injection attack is, by definition, an instruction that overrides yours.

A limit is only a limit if the agent can't get around it. That means enforcing it somewhere the agent doesn't control, before an order is signed.

Checklist before you hand an agent a key

1. Use a dedicated sub-account or wallet, funded only with what you're prepared to let the agent trade.
2. Create a key just for the agent, with trading only and withdrawals disabled. On Hyperliquid, use an API wallet; on Robinhood, a dedicated Agentic account; on Binance, the Agentic sub-account. Check the key can't change its own permissions.
3. Add an IP allowlist where the venue supports it.
4. Set the venue's own risk controls: maximum leverage, and position limits where the venue offers them. Few exchanges let you set trading limits on a single key.
5. Enforce your own limits outside the agent: size, leverage, markets, slippage, and a reserve the agent can't touch.
6. Keep the key out of prompts, logs, and shared config. Give it only to the process that signs orders.
7. Know how to revoke the key fast, and rotate it on a schedule.
8. Review what the agent did, not just what it reported doing.

Steps 1–4 limit the damage. Step 5 is the only one that stops a bad order before it happens.

How to enforce limits outside the agent

There are a few ways to do step 5: exchange risk settings (coarse, and different on every venue), a proxy you build and run yourself (more control, more to maintain), or a dedicated guardrail layer.

Pakt is a guardrail layer built for this. Here's how it works:

• You set the limits once. These include size, leverage, markets, slippage, reserve floors and destinations. They're committed as a numeric policy and approved with a signer you hold. Your agent can propose anything; only orders that satisfy your Pakt get signed.
• Each order is checked against your live account state, not just on its own. A trade that looks fine in isolation is refused if it would leave the account over your leverage or exposure limit.
• Checks run where the agent can't reach them. Verification and signing happen inside a secure hardware enclave (a TEE), and a zero-knowledge proof shows each order satisfies your limits. Proof generation takes under two seconds and can cover up to 10 trades.
• Refusals are final. If an order is outside your limits, no signature is released and the order never reaches the venue. Only you can change the limits; the agent can't.
• It's non-custodial. Pakt never holds your funds or keys and never submits orders. Your venue holds the funds and executes trades as it does today.

Pakt connects to Claude Code, claude.ai, Codex, Gemini, OpenCode and other agents as an MCP server, skill or CLI. It's live today for Hyperliquid perpetuals, in beta.