Letting an AI agent trade on your exchange account, without handing it the keys to everything

01Context

Yellow.pro is a crypto spot and perpetuals exchange: centralised-exchange speed, with users keeping control of custody. I joined in March 2026 as Senior Product Manager across the retail terminal, and took ownership of a track nobody had defined yet: what should "AI trading" mean for us?

The constraints shaped everything. A small engineering team already committed to the core exchange roadmap. A compliance position that ruled out Yellow making trading decisions for users. And an API-key system built for developers, with five scopes and no concept of "an AI acting for me".

02Problem

User pain. Traders were already wiring LLMs to exchanges the unsafe way: pasting a full-access API key into a chat tool or a script. One bad prompt and the agent could touch the whole balance. And getting that far needed a terminal, a JSON config file and patience. The people most curious about agent trading were the least able to set it up safely.

Business pain. An exchange lives on volume and on reasons to choose it. Agents are a new class of trader, but we could not see them: agent orders looked like any other API order, so we could not measure the channel, reward it in competitions, or report on it to partners.

03Approach

I became the first user. Before writing requirements I connected Claude to my own account and ran live strategies with real money at small size. This found things no document review would: how the venue treats reduce-only orders when a stop and a take-profit compete for the same position, which data an agent misreads, where an agent needs the exchange to say "no" clearly. Every one of those became a requirement or a docs page.

Persona UAT. I ran the setup as three people: a developer in a terminal, a trader using a desktop AI app, and a curious retail user on a phone. The third one failed almost immediately, which set the bar for onboarding.

Options on the table:

An earlier, broader scope (vaults, an in-app agent runtime, a spending-cap gateway) had been written up before I narrowed it. I cut almost all of it. It was the right ambition and the wrong first release.

Local first, hosted second. Once MCP was the path, the next trade-off was where the server runs:

We shipped the local server first as the proof of concept: open source, fast, and the cheapest way to learn what an agent needs from an exchange. The hosted connector followed for retail onboarding: no install, no pairing code, one link that every supported AI app accepts.

04Decision

What we shipped, in the order a user meets it:

1. An agent sub-account. The AI never sees the main account. The user funds the agent with what they are willing to put at risk, and takes it back the same way.
2. Pick your AI. Seven supported clients, each with setup steps checked against the vendor's own docs.
3. Read-only by default. Trading is an explicit opt-in on the same screen, recorded with a risk acknowledgement. A withdrawal permission is never granted to an agent key, on any path.
4. A one-time pairing code that expires in minutes, instead of copying secrets around.
5. "Check it works". Three read-only checks run before the user trusts the connection.
6. One page, two modes. No agent key yet: onboarding. Key exists: an overview with revoke, the trading switch, funding, and "connect another AI".
7. Attribution. Agent volume is tagged at the source, so leaderboards, competitions and partner reports can finally see it.

Alongside the product: the open-source MCP server on npm (market data, balances, orders, positions, funding, transfers), fifteen documentation pages, and a public library of ten strategy prompts where every order waits for the user to type "confirm".

Then the hosted connector. One URL, mcp.yellow.pro, that the user pastes into their AI app or adds with a single command. No install, no pairing code: the app asks Yellow for access, the user approves it in the browser with the same scope and limit controls, and the connection is checked before it is trusted. Ten providers are covered, each with setup steps verified against the vendor's own documentation.

05Outcome

Shipped: the local MCP server went public in September 2026 as the proof of concept, followed by the hosted connector for retail, and agent onboarding is live in the app. I trade through it myself most days, which remains the fastest bug-finding process we have.

Too early for adoption numbers, and I would rather say so than invent one. What I am tracking: connected agents, share of volume that is agent-attributed, time from "create agent account" to first agent order, and how many users stay read-only.

What surprised me. The hard part was not the protocol. It was the twenty-fifth iteration of the onboarding page. Users did not fear the AI trading badly; they feared not being able to stop it. Revoke, the trading switch and the separate balance did more for trust than any copy we wrote.

06Reflection

I reversed my own decision inside an hour, and it was cheap because I had written down why. I briefly changed the default key from read-only to read-and-trade to shorten the path to a first order. Rereading the risk rationale, with no spending-cap gateway at launch the connect-time disclosure was the only control we had, and a read-only default is what forces every user through it. I put it back. The lesson I kept: record the reason next to the requirement, because inverting a stated decision takes minutes and hunting an unstated one takes days.

I would draw mobile first. The desktop flow was on its fifteenth version before anyone drew the phone. The two components most likely to break on a small screen were exactly the two we had polished most.

I would ship attribution before the feature. We launched able to see agent volume, but with no baseline from before. Instrumentation is a feature with a deadline earlier than the launch.