Your keys neverreach the model
An API key that can place orders is the most dangerous thing you will hand to any trading tool. Here is precisely where it goes, which process can read it, and what stays impossible even if the model is talked into asking.
What happens to a key you paste in
It goes to a secrets store, not to a database column
Venue credentials are written to a secrets store under a path belonging to your account, and read back only by the service that talks to the exchange. They are not in the application database, not in a settings row, and not in any log line — the code that formats venue errors for display strips them before the message is written.
The model is never given them
The language model reaches the platform through a fixed set of tools: read market data, run a screen, draft a proposal, ask for an evaluation. None of those tools returns a credential and none accepts one. This is a property of which tools exist, not a rule the model is asked to obey — a prompt that talks it into wanting a key finds nothing to call.
One customer’s keys, one process
A process holding several customers’ venue keys is one bug away from a leak that hits all of them at once, and no amount of row filtering downstream changes that — the keys are already in the same heap. So the money path is isolated per paying customer, while shared analytics stays shared. It is the more expensive design, and it is the one that survives a mistake.
Restrict the key before you paste it
Every venue we support lets you create a key that can trade but cannot withdraw, and most let you pin it to an IP address. Do both. A key that cannot withdraw turns the worst case from "your funds are gone" into "someone made bad trades you can see in the audit trail" — and we would rather lose that argument than have you learn it the other way.
What stays impossible
Not policies. Calls that do not exist, in a system where the part that drafts orders and the part that approves them are different services with different credentials.
- Withdrawing funds. The console never asks a venue to move money off it.
- Reading a credential back out. There is no route that returns one, to the model or to the interface.
- Trading an account you have not connected, or an instrument you have not enabled for it.
- Approving its own order. The service that submits will not accept an intent without a signed evaluation from the service that checks it, and that signature expires in seconds.
- Silently continuing after a refusal. A blocked order is recorded with the check that stopped it, and you can read it.
The awkward questions
What if your own service is breached?
Then the attacker reaches what that service can reach, which is why the money path is isolated per customer and why we ask you to create withdrawal-disabled keys. We would rather tell you the blast radius than claim there is none.
Can I revoke access without contacting you?
Yes, and it is the correct first move in any doubt: delete the API key at the exchange. Everything the console can do at that venue stops immediately, with no ticket, no waiting and no cooperation needed from us.
Does the model see my positions and balances?
It sees them when you ask it something that needs them, because that is the product. It sees your account, never another customer’s — and it is reading them, not able to move them.
Do you sell or share my trading data?
No. It is not aggregated into a signal sold back to anyone, and it is not order flow for sale. If that ever changed it would be a change you were asked to accept, not a paragraph quietly edited into a policy.
Read it, then test it on paper
A paper account needs no venue key at all. Run the whole system first, and connect an exchange only once you believe what this page says.