Exchanges gave agents API keys. Agents still need limits.

In 2026, every large crypto exchange shipped something for AI agents: MCP servers, command-line tools, agent "skills". Users can now connect Claude, ChatGPT or their own agent to their exchange account in a few minutes.

Most of those tools were built on the API key. That was the fastest way to ship. It's also the reason the controls aren't as strong as they need to be for users to really trust them.

The API key was built for scripted actions, not agents

Exchange API keys were designed for trading bots and algorithms written by the account holder. The controls reflect that:

• Permissions: read, trade, withdraw, switched on or off per key.
• IP allowlists: the key only works from known machines.
• Withdrawal whitelists: funds can only leave to approved addresses.

Those controls assume the code does exactly what is scripted. An AI agent doesn't by design. It interprets instructions, acts on text it reads, maybe makes mistakes, and sometimes runs on a laptop with the key in a config file.

A trade-only key can still lose money through trades

Turning off withdrawals stops the most direct theft. But it doesn't stop bad trades, and bad trades are how the largest key-based losses have happened.

In 2022, API keys leaked from the trading-bot platform 3Commas were used to trade victims' holdings into illiquid tokens the attackers had priced up. Losses were $22-27 million, almost all of it through trades on users' own accounts. In 2018, phished trading keys were used on a major exchange to buy Viacoin from attacker accounts, pushing it up roughly 10,000% in minutes. Neither attack needed withdrawal access.

An agent recreates that exposure without an attacker. A model that misreads a number, a bug in its sizing code, or a manipulated instruction could produce the same kind of order.

Most exchanges give agents too much freedom

A review of the agent tools four large exchanges published in 2026 found:

• Most put the agent on the existing key. The agent's limits are the key's limits: trade or don't, withdraw or don't.
• The agent-specific safety features mostly run on the user's machine. Confirmation flags that the agent supplies itself, spending caps passed as command-line options, a kill switch that's a local file. Useful, but the agent's own process can skip them.
• No exchange offered server-side trading limits per key. No cap on notional, order count, leverage or which pairs a key can trade.
• Some keys can change their own settings. On at least one exchange, a key with transfer or withdrawal permission can rewrite its own permissions and IP allowlist through the API.
• Keys don't expire with the task. Where keys lapse at all, it's after 14 to 90 days, usually only if unused or not tied to an IP address, not when the job they were issued for ends.

One exchange did change the model. Its agent integration gives each agent its own funded sub-account, scopes the agent can't widen, no withdrawal scope at all, and a single emergency stop that disconnects every agent and cancels their orders. That's the right direction. However, it still has no limits on what the agent trades inside that sub-account.

We need stronger controls to protect customers

Some users will connect agents whether or not the controls are ready. If an agent blows up an account, the user's first call is to the exchange.

It's also a market-integrity question. A manipulated agent with a trade-only key is a tool for pumping thin markets, as the 3Commas and 2018 cases showed.

Hong Kong's SFC told licensed virtual-asset platforms in June to limit "connectors and tool permissions to what is necessary for the intended use case" and to "apply maker-checker controls for high-impact actions". The HKMA has floated "kill-switch" mechanisms "to suspend agents before an issue escalates". ESMA expects firms to keep the "unconditional capacity to monitor, suspend, or terminate algorithmic trading".

An exchange that offers customers real agentic controls that create trust will lead adoption:

1. Each agent connected separately, with its own account or sub-account and its own funding.
2. Limits that live with the exchange, not the agent. Your clients will connect agents from many AI providers and switch between them. A cap in a CLI flag or a confirmation in an agent skill changes with every agent; a limit the exchange enforces holds whichever one is connected.
3. Limits scoped to that agent and enforced on the exchange side or at signing: notional per order, total exposure, leverage, allowed markets, and a loss limit.
4. Checks against the account after the trade, not just the order on its own.
5. Limits the client sets and the agent can't change, including through the API, starting from safe defaults.
6. One policy across trading, transfers and earn products, so the agent can't route around a trading limit through another product.
7. Access that expires when the task does, plus an emergency stop.
8. A record per agent of what it proposed, what was allowed and why.

Pakt offers agentic guardrails

Pakt runs this pattern today on Hyperliquid, which already separates a user's main wallet from trade-only API wallets. Pakt adds the missing layer on top: the client approves rules (markets, size, leverage, concentration, price protection, an equity floor), the agent proposes orders, and Pakt's restricted signer only signs the ones that pass, checked against the account's projected state inside secure hardware. Refused orders never reach the exchange. Genuine reduce-only exits are always allowed through.

Trading is only one example use case for Pakt's agentic guardrails. For a centralized exchange, the same engine can sit behind your agent API or MCP server, or act as the signer for agent keys, and cover your other products too.

• Rule design for the products you want agents to use: spot, perps, margin, earn, transfers.
• Integration: at your API gateway, your MCP server, or as the signing step for agent-scoped keys.
• Receipts your users, and your risk team, can check for every agent order.

Sources

• ForkLog on HAPI's 3Commas analysis
• Trend Micro on Binance 2018
• SFC circular
• HKMA: Carmen Chu
• ESMA algorithmic trading briefing