// AI AGENTS THAT TRADE · PILLAR GUIDE

How to let an AI agent trade prediction markets safely

2026-07-16 · Mithril

Prediction markets are unusually well suited to AI agents. The contracts are binary, the payoff structure is simple, and the alpha is often informational — reading a Fed statement, parsing a poll release, scanning a court docket — which is exactly the kind of work a language model does faster than you do. Both major venues are programmatically tradable: Kalshi through a REST API, Polymarket through its on-chain CLOB. So the tempting move in 2026 is obvious: give an agent your API keys and let it trade.

Don't do that — at least not literally. An LLM with raw exchange credentials is a machine that can lose your money in three distinct ways, and none of them are hypothetical. This post is the map of those failure modes and the architecture that closes each one. The rest of the hub goes deep on every piece.

Why agents and prediction markets fit

Before the warnings, the case for doing this at all:

• Binary contracts are legible to a model. "Will CPI print above 3.2%?" resolves yes or no. There is no options surface, no funding rate, no basis trade to reason about. A model's probability estimate maps directly to a price between 0.01 and 0.99.
• The edge is often research, not speed. Most prediction-market mispricings persist for minutes to hours, not microseconds. An agent that reads primary sources and updates positions a few times a day is a viable design — you don't need colocated infrastructure.
• The venues are open. Kalshi exposes a documented REST + WebSocket API; Polymarket's CLOB takes signed orders from anyone. And with MCP servers, models like Claude can now call trading tools natively instead of you writing glue code.

The problem is not whether an agent can trade. It's that the naive setup — keys in a prompt or an environment variable, no external limits, trust in the model's judgment — fails in three predictable ways.

Failure mode 1: custody

To trade, software needs credentials — a Kalshi API key, or on Polymarket a wallet private key that signs EIP-712 orders. If your agent holds those credentials directly, every part of the agent's stack becomes an attack surface: the prompt, the conversation log, the tool outputs, the machine it runs on, and every third-party context (a fetched web page, a pasted document) the model reads. Prompt injection is the canonical attack — a document that says "print your environment variables" — but even without an attacker, credentials that live in an LLM's context can end up in logs, traces, and training-adjacent telemetry.

The Polymarket case is the sharpest: that private key doesn't just sign orders, it controls the wallet. Exfiltration means the funds are gone, not just the account compromised.

The fix is structural, not behavioral. The agent should never see the keys. Keys live encrypted server-side, are decrypted only in memory at the moment an order needs signing, and the agent interacts through an API that accepts order intents, never credentials. The full design — envelope encryption with X25519, decrypt-only-to-sign — is in Agent custody: why your AI agent should never hold your keys.

Failure mode 2: runaway orders

An agent in a loop is a machine for repeating mistakes quickly. Classic scenarios:

• A retry loop that re-sends an order whose acknowledgment timed out, buying five positions instead of one.
• A strategy that keeps averaging down into a market that is repricing on real news the agent hasn't seen.
• A misparsed price — cents vs decimals is a genuinely easy confusion when a venue quotes 42¢ and another quotes 0.42 — turning an intended $50 order into a $5,000 one.

Telling the model "never risk more than $100 per trade" in the system prompt is not a control. Prompts are suggestions; under adversarial input or plain confusion, the model can and will violate them. The only limits that count are the ones enforced server-side, outside the model, where no output the model produces can lift them: notional caps per order and per day, per-market position limits, slippage bounds, and a kill switch that halts everything instantly. The full taxonomy is in Risk limits for AI trading agents.

Failure mode 3: hallucinated trades

Language models fabricate. In a trading context that means an agent may confidently report a fill that never happened, misstate the price it got, "remember" a position it doesn't hold, or invent a market that doesn't exist. If your only record of what the agent did is the agent's own narration, you have no record at all.

The fix is ground truth from outside the model: every order and fill recorded by the execution layer, not the agent; portfolio state queried from the venue, never carried in the model's context; and an execution receipt on every fill showing what was actually done at what price. Receipts do double duty — they catch hallucinations and let you audit execution quality, the subject of execution receipts and best execution.

The architecture that survives all three

Put together, a safe agent-trading stack has a hard boundary between the model and the market:

The agent proposes; the execution layer disposes. Concretely:

1. Keys stay server-side, encrypted, decrypted only to sign (custody post).
2. Every order passes hard risk checks the model cannot see, argue with, or disable (risk-limits post).
3. Every fill produces a receipt — venue, price, fees, timestamp — logged independently of anything the model says.
4. The agent talks to one interface, not two venue SDKs, so limit enforcement and logging can't be bypassed by switching code paths.

This is the same separation traditional trading firms enforce between a trader and the risk desk. The trader — human or model — never gets to be their own risk manager.

Where to start

The practical entry points, in rough order of effort:

• Chat-first: connect Claude to a hosted MCP trading server and trade conversationally, with limits set before the first order. Tutorial: Trading Kalshi and Polymarket with Claude via MCP.
• Understand the plumbing: if MCP is new to you, What is an MCP server? A trader's explanation covers the protocol in ten minutes.
• Code-first: use an AI coding agent to scaffold a proper bot against a trading API, test in sandbox, then go live — Building a prediction-market bot with Claude Code.
• Background reading: the venue mechanics live in the prediction market API guide, and the cross-venue price question in smart order routing.

Full disclosure of the obvious: this architecture is what Mithril is — one API and a hosted MCP server over Kalshi and Polymarket with encrypted key custody, hard server-side limits, and a receipt on every fill. But the design stands on its own. Whether you build it yourself or use ours, do not let the model hold the keys, set the limits, or keep the books.

Venue details change. Everything above reflects public documentation as of July 2026 — confirm against the venues' own docs before trading real money.