Almost never. An agent with trade-only access can lose you money through bad trades; an agent that can withdraw can send everything to someone else in a single transaction. The exchanges’ own defaults point the same way: the world’s largest exchange blocks withdrawals from its agent subaccounts by default.
What is the difference between trade and withdrawal permissions?
Trade permission lets an agent move your money between assets inside your account; withdrawal permission lets it move your money out. That one difference sets your worst case. Exchanges split API keys, the credentials that agent software uses to act on your account, into separate permission tiers for exactly this reason.
| Permission | What the agent can do | Realistic worst case |
|---|---|---|
| Read | See balances, orders and history. | Your account data is exposed. |
| Trade | Place and cancel orders inside the account. | Bad trades, fees and losses, but the funds stay in your account. |
| Internal transfer | Move funds between your own accounts or subaccounts. | Funds end up in the wrong place, but still yours. |
| Withdraw | Send funds to an outside address. | The whole balance leaves for good. |
Our judgement, in one line: with trade-only keys, the worst case is bad trades, not theft. That is not a small difference. A bad trade usually leaves something behind. A withdrawal to an attacker’s address usually leaves nothing, and blockchain transfers generally cannot be reversed.
Why do exchanges treat withdrawals differently?
Exchanges single out withdrawal rights for extra caution, and their own documentation says so. The rules differ by exchange, but the ones we reviewed add friction to withdrawals that they do not add to trading.
One large exchange’s API documentation tells users to set the minimum permissions needed. It says a key used only to place orders does not need withdrawal rights, and that withdrawal permission should be enabled only on keys that genuinely need to move funds, with strict IP whitelisting. IP whitelisting means the key only works from internet addresses you list in advance.
Another large exchange goes further. Its API help pages say keys that have trading or withdrawal rights but are not bound to an IP address are deleted automatically after 14 days of inactivity. To withdraw through its API at all, you must first add the destination address to your account. A third large exchange sets new keys to read-only by default, and warns that trading or withdrawal rights take effect the moment you share a key that has them.
The newest agent products follow the same logic. On the world’s largest exchange, each agent gets a dedicated subaccount, and withdrawals from it are blocked by default. The effect is a sandbox around the agent’s activity.
Are there good reasons an agent might need to move money?
Yes, there are legitimate cases, but almost none of them need a full withdrawal permission on your main account. Most can be met with a narrower tool.
An agent might need to pay for data or computing, rebalance between your own accounts, or settle a payment for a business. Here are the narrower options, from safest to riskiest:
- Internal transfers only. Some exchanges describe transfers between your own accounts separately from withdrawals. An agent can rebalance without being able to send funds outside.
- A small, separate agent wallet. Fund a wallet just for the agent, with only what it needs for the week. If the agent goes wrong, the loss is capped by design.
- Built-in spending limits. The largest exchange’s agent wallet has daily limits it sets itself, for example $50,000 for swaps and $20 for agent payments. Check what limits apply before relying on them.
- Pre-approved addresses only. An address allowlist means funds can only go to destinations you listed in advance. An attacker cannot simply add their own address through the agent.
- Human approval for every withdrawal. The agent proposes a transfer; you confirm it. This is slower, which is the point.
Our judgement is that if none of these work for your use case, the agent probably should not be handling the money at all.
If I grant withdrawal rights anyway, how do I limit the damage?
Stack every control you can, so that no single failure empties the account. If you decide the benefit is worth it, treat this as a minimum, not a full list.
- Use a dedicated subaccount that holds only the amount the agent needs, never your main balance.
- Bind the key to fixed IP addresses. One exchange lets you attach up to 20 addresses to a key.
- Allowlist destination addresses so withdrawals can only reach wallets you control or have verified.
- Set the smallest withdrawal limits the exchange or wallet allows.
- Turn on alerts for every withdrawal, by email or app notification, so you see it in real time.
- Rotate the key regularly and revoke it the moment you stop using the agent.
None of these steps make withdrawal rights safe. They make the worst case smaller and easier to spot.
What could go wrong?
The real danger is not that the agent decides to steal from you. It is that someone else gets it to act, or gets hold of its key. Three risks stand out.
Prompt injection. An attacker hides instructions in content the agent reads, such as a web page, a token description or a message. If the agent follows them, its permissions become the attacker’s permissions. A trade-only agent fooled this way can make bad trades. A withdrawal-enabled agent fooled this way can send your funds to the attacker.
Leaked keys. A key with withdrawal rights is effectively a bearer instrument: whoever holds it can use it. Keys sitting in agent software are exposed to malware, shared machines and careless copying. IP binding and address allowlists are what stop a leaked key from becoming a theft.
Trade-only is not zero-risk. A trade-only key still controls the balance inside the account. Our inference is that someone who controls it could, in principle, push it into poor trades, for example buying a thinly traded asset at a bad price. That is why the balance in an agent’s subaccount should be money you can afford to lose, whatever the permissions.
The trust takeaway
The safest default is simple: an agent can trade, it cannot withdraw. If money has to move, use the narrowest tool that does the job, from internal transfers to small, separate wallets with hard limits. Treat any request for full withdrawal rights as a reason to slow down.
Before you grant any agent access to funds, check:
- Withdrawals: Is withdrawal switched off on this key or subaccount, and does the agent have no way to switch it on?
- Need: If the agent must move money, can internal transfers or a small separate wallet do the job instead?
- Destinations: Can funds go only to addresses I have allowlisted?
- Key binding: Is the key bound to fixed IP addresses?
- Alerts: Will I be notified of every withdrawal as it happens?
- Exposure: If the agent were fooled tomorrow, how much could leave, and could I live with that?