Scoped API Keys for Trading Agents: Roll Your Own or Use an Agent-Ready API

Building scoped access for a trading agent yourself means writing your own permission layer on top of venue keys that were designed for humans, while using an agent-ready API like Felix means the scoping already exists as a property of the key. The manual route gives you full control and full responsibility: you write the policy engine, the budget ledger, the order validation, and the kill switch, and any bug in that layer is a bug in the thing protecting your money. The built-in route trades some flexibility for enforcement that lives outside your code and outside the agent's reach. For most developers, the second path is the right default, and this article explains why in concrete terms.

What is a scoped API key for a trading agent?

A scoped API key is a credential that can only do a subset of what the account behind it can do. For a trading agent, that subset is the whole point. The agent needs to place and cancel orders within a defined budget, in defined markets, at defined sizes. It does not need to withdraw funds, change account settings, or create new credentials, and a scoped key makes those actions impossible rather than merely discouraged.

Most venue API keys were designed for a human running a script. They typically offer broad permissions with, at best, a toggle for withdrawals. They have no concept of a budget, a per-order cap, or a position limit, because the assumption baked into them is that a person is watching. An autonomous agent breaks that assumption. Once an agent holds a key, the key's permissions are the only thing standing between a loop, a bug, or a hallucination and your balance.

A well-scoped key for a trading agent usually encodes:

• ·Which market types it can trade, such as stocks, crypto, perpetual futures, options, or prediction markets
• ·A total budget in dollars that cumulative spending cannot exceed
• ·Per-order and per-position size caps
• ·Withdrawal rights, which for an agent should be none
• ·An expiry time and a way to revoke it instantly

The purpose of all this is blast radius. With a full-permission key, a malfunctioning agent can do anything the account can do. With a scoped key, the worst case is bounded by the envelope you chose. Trading can lose money, including everything you allocate to an agent, so the size of that envelope is a decision to make deliberately, not a default to inherit from whatever the venue gives you.

What does building key scoping yourself involve?

The manual path starts from an uncomfortable fact: if the agent can read the raw venue key, nothing you build on top of it matters, because the agent can bypass your code entirely. So the first thing you build is a gateway. The real keys live in a secrets store the agent cannot reach, and the agent talks only to your service, which checks every request before forwarding it. From there, the work multiplies:

1. 01A policy engine that evaluates every order against rules for size, market, and frequency
2. 02A budget ledger that tracks cumulative spending, including fees, partial fills, and rejected orders
3. 03Contract math normalization, because each venue defines size differently and a dollar limit has to mean the same thing everywhere
4. 04Key storage, rotation, and revocation across every venue you use
5. 05A kill switch that cancels open orders and flattens positions, not just blocks new ones
6. 06Audit logging so you can reconstruct what the agent did and why

None of these components is exotic, but each is a real project with real edge cases. The ledger has to stay correct when a venue returns a partial fill and then goes offline. The kill switch has to work while the agent is misbehaving and the venue is degraded, because that is exactly when you will reach for it. And all of it sits on the critical path between an autonomous system and real money, which raises the bar for testing and review. Plan for this to be a substantial build, not a weekend project, and plan for it to keep costing you time as venues change their APIs.

Where do manual setups tend to break?

The failure mode is rarely a wrong policy. It is incomplete enforcement. Suppose your gateway validates orders, but one code path lets the agent query a venue directly for market data, and that path quietly grows order placement because a venue SDK makes it easy. Or imagine your ledger counts submitted orders rather than fills, and drifts after a run of partial fills until the agent's real exposure is well past its nominal cap. These examples are hypothetical, but they describe the shape of actual incidents: the permission layer develops a hole, and the agent finds it, because agents systematically explore whatever space they are given.

There is a second, newer failure mode worth naming. Agents read external data, and external data can be hostile. A manipulated page or message can try to steer an agent into placing orders it should not, a pattern known as prompt injection. Scoped keys are the mitigation of last resort here: even a fully steered agent cannot exceed its envelope. But that protection only holds if enforcement lives outside the agent's own process. A limit the agent can edit is not a limit, and a kill switch the agent can disable is not a kill switch.

What does the agent-ready path look like with Felix?

Felix takes the opposite approach: enforcement is a property of the key itself, not of code you maintain. One key and one API give an agent access to five market types: stocks, crypto, perpetual futures, options, and prediction markets. The system is non-custodial by construction. Funds sit in a wallet the owner controls, the agent can spend within its limits, and it can never withdraw to itself, because withdrawal addresses are owner-approved only. The non-custodial design means the worst case for a broken or compromised agent is bounded by its budget, not by the account balance.

The controls map directly onto the manual build list from earlier. Scoped keys define what the agent may touch. Budget caps and position limits are enforced by the API, not by your ledger. Exit plans describe what to do with open positions. And a panic switch flattens positions and revokes access in one action, which is the property a kill switch most needs and most often lacks. Orders are sized in plain US dollars, and the API normalizes each venue's contract math, so the normalization project disappears entirely.

Creating a scoped key is a single call: The exact request schema is in the docs; this example shows the shape.

curl -X POST https://api.felix.trade/v1/keys \
  -H "Authorization: Bearer YOUR_OWNER_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "research-agent",
    "markets": ["crypto", "perps", "prediction_markets"],
    "budget_usd": 5000,
    "max_position_usd": 1000,
    "max_order_usd": 250,
    "withdrawals": "disabled",
    "expires_in_days": 30
  }'

Agents connect through MCP tools from clients like Claude or Cursor, or directly over the REST API, so the same scoped key works from whatever MCP client your agent runs in. Paper trading lets you exercise the whole integration against simulated fills before any real money is involved, and live trading requires explicit owner authorization of a key, so an agent cannot promote itself from testing to live. The full reference is in the docs, and the broader operating model is covered in the guide to running an AI trading agent safely.

How do the two paths compare in practice?

Put side by side, the differences look like this:

• ·Enforcement location: your own process, which the agent might bypass, versus the key itself, which the agent cannot
• ·Time to a safe first trade: a gateway, ledger, and kill switch to design and test, versus one API call to create a scoped key
• ·Cross-market consistency: contract math you reimplement per venue, versus dollar-denominated orders normalized by the API
• ·Revocation: rotating venue keys and redeploying services, versus one action that flattens positions and revokes access
• ·Custody: whatever the venue's account model gives you, versus non-custodial by construction with owner-approved withdrawal addresses
• ·Maintenance: venue API changes become your incidents, versus behavior the platform absorbs

The honest trade-off is flexibility. When you own the enforcement layer, you can express any policy you can code: unusual sizing rules, custom interactions between strategies, integration with an existing risk system. A platform gives you the controls it built. The question worth asking is whether your requirements are actually unusual, or whether they are the standard set of caps, limits, and revocation that almost every trading agent needs.

When does building it yourself still make sense?

There are real cases for the manual path. If you already operate custody and risk infrastructure that a new agent must plug into, building on it is often simpler than adopting a second system. If you need venue features that an agent API does not expose, you may have no choice. And if your organization has a security team that will genuinely review the enforcement layer, the biggest weakness of the manual path, unaudited coverage, is partly mitigated.

For everyone else, the calculus is straightforward. The guardrails are not the product; the strategy is. Every hour spent reconciling a budget ledger with a venue's fill reports is an hour not spent on the logic that is supposed to make good decisions. Built-in scoping gets you to a safe default quickly, and you can always add a custom layer later if a real requirement emerges. What does not change on either path is the underlying risk: trading can lose money, including everything you allocate, and no key structure, manual or managed, alters that.