How a single API keeps portfolio agents safe across many markets

A single API can protect a multi market portfolio agent by enforcing safety rules at the infrastructure layer before any order reaches a venue. Instead of trusting the agent to regulate itself, the API applies scoped keys, budget caps, position limits, and owner approved withdrawal addresses that the agent cannot override. This means one agent can trade stocks, crypto, perps, options, and prediction markets through the same interface while remaining physically unable to steal funds or exceed the guardrails set by its owner.

Why does one API simplify safety for agents trading across markets?

Managing risk across multiple asset classes is difficult when each venue uses its own credentials, margin rules, and order formats. An agent that trades stocks through a stock broker, crypto through a crypto exchange, and perps through a perps venue must juggle three different authentication schemes, three sets of rate limits, and three monitoring dashboards. Fragmentation increases the chance of a configuration error, an expired key, or an unnoticed position in one account while the agent is busy trading another. When safety policies are scattered across separate systems, the owner must replicate every change, and the agent can exploit gaps between them.

A unified API removes this fragmentation. The agent speaks one language, orders sized in USD, and the API translates those instructions into the native formats required by each underlying venue. Safety policies are enforced at the translation layer, so a single set of controls governs every market. The owner does not need to replicate budget caps or kill switches across multiple accounts. One policy surface is easier to audit, harder to misconfigure, and faster to lock down when behavior looks wrong. Audit logs are also centralized. Every request, rejection, and flatten command appears in one stream, so the owner can trace a bad decision across markets without hopping between dashboards.

This centralization does not create a single point of failure for funds because the API is noncustodial. The owner retains the private keys to the wallet that holds the capital. The API can only instruct spending within the limits encoded in the scoped key. If the API itself were compromised, the attacker could not withdraw funds to an arbitrary address because withdrawal addresses are owner approved and immutable by the agent. non-custodial-agent-trading

How do scoped keys limit what an agent can touch?

A scoped key is a credential that carries its own restrictions inside it. When an owner issues a key to an agent, the owner defines which markets the key can access, the maximum order size in USD, the allowed order types, and the total budget cap. The key cannot be used to trade outside those boundaries even if the agent asks politely or prompts maliciously. The scope is encoded in the key material and validated by the API on every request.

These limits are enforced by the API, not by the agent. This distinction matters because large language models and autonomous agents can hallucinate, be jailbroken, or simply contain bugs. If the agent generates a request to buy one million dollars of an option when the cap is one thousand dollars, the API rejects the order before it leaves Felix. The agent does not have the authority to override its own scope. The rejection is logged, and the owner can inspect the incident without any money having moved.

Scoped keys also reduce blast radius. An owner can issue separate keys to separate agents, each with its own budget and market restrictions. A crypto only agent receives a key that cannot reach a stock broker. A rebalancing agent receives a key that can only trade between two approved ETFs. If one key leaks, the damage is contained to its narrow scope. Owners can revoke a single key without rotating credentials for every venue. Keys can also be time bound, expiring automatically after a trading session or a backtest period. This temporal scoping is useful when the owner wants to grant temporary access for a specific strategy deployment without leaving a permanent door open. secure-ai-trading-without-giving-up-custody

What stops an agent from concentrating risk in a single market?

Multi market portfolio management only works if the safety model understands the whole portfolio. A single API can aggregate exposure across all connected venues and enforce limits that prevent the agent from piling into one asset class. The owner sets budget caps per market type and per underlying symbol. For example, the owner might allow the agent to trade stocks, crypto, perps, options, and prediction markets, but cap perps exposure at 20 percent of total capital and options exposure at 10 percent. The API tracks notional exposure in real time and blocks an order that would breach any cap. This happens regardless of whether the agent is acting on a strategy bug, a bad signal, or a misunderstood prompt.

Concentration limits also protect against venue specific risks. If a perps venue experiences a funding spike or a prediction market experiences a liquidity gap, the agent might try to chase the move. The API treats the hard limit as a wall. The agent receives a rejection and must either rebalance within the allowed bounds or wait for the owner to adjust the limit. The owner, not the agent, decides when to raise or lower a cap.

Because orders are sized in dollars, the API can compare exposure across instruments with different contract mechanics. A one thousand dollar stock position and a one thousand dollar perp position count equally against the same cap. The agent does not need to understand lot sizes, multipliers, or margin tiers. The owner expresses risk in plain currency, and the API normalizes the comparison. This prevents the subtle but common mistake of an agent thinking it is small in one market when it is actually large in notional terms. how-autonomous-trading-systems-enforce-hard-limits

How do exit plans and kill switches prevent catastrophic losses?

Every automated strategy needs an off ramp. An exit plan is an instruction programmed in advance that tells the API how to unwind positions when a condition is met. The condition might be a drawdown threshold, a time boundary, or a manual trigger from the owner. When the condition fires, the API sends closing orders to every venue where the agent holds open positions. The agent does not need to be online or cooperative for this to work. The exit plan lives in the infrastructure layer.

The kill switch is the more extreme version. It immediately flattens all positions, cancels all open orders, and revokes the agent's key. The agent cannot disable the kill switch because the switch lives in the API infrastructure, not in the agent's logic. Even if the agent is stuck in a loop or compromised by an external prompt, the owner retains the ability to stop all trading with one action. The kill switch is irreversible from the agent's side. Once triggered, the key is dead, and the agent must be explicitly reauthorized before it can trade again.

These controls are especially important when an agent trades correlated instruments across markets. A long stock position hedged with a short perp might become unbalanced during volatile periods. An exit plan can unwind both sides simultaneously according to the owner's instructions. The API handles the sequencing so that the agent does not accidentally create a naked exposure while closing one leg before the other. The owner can define priority rules, such as closing prediction market positions first and perps last, to minimize slippage or funding costs. practical-checklist-ai-portfolio-rebalancing

Can an agent trade multiple asset classes without taking custody?

Yes. The noncustodial design is built into the architecture, not added as a feature. Funds sit in a wallet that the owner controls. The agent receives a scoped key that authorizes spending, but the key does not authorize withdrawals to arbitrary addresses. The API will only move funds to addresses that the owner has explicitly approved in advance. This means the agent can trade stocks, crypto, perps, options, and prediction markets without ever holding the owner's capital. The agent can buy, sell, open, and close, but it cannot send money to itself or to a third party. If the agent's host environment is compromised, the attacker might gain the ability to place trades within the existing limits, but they cannot sweep the wallet.

Live trading requires explicit owner authorization of a key. Paper trading exists for testing, but the agent cannot promote itself to live trading without the owner generating and authorizing a new scoped key with live permissions. This two step process prevents an agent that was safe in simulation from accidentally gaining real money access before the owner is ready. The authorization step is a deliberate human checkpoint, not a default setting.

Noncustodial trading also simplifies compliance and bookkeeping. Because the funds never leave the owner's wallet until a trade executes, the owner maintains a clear chain of control. The agent is merely an authorized operator, similar to a power of attorney with strict limits. The owner can revoke that authority instantly without waiting for a venue to process an account closure. This relationship is possible because the API connects to venues on the agent's behalf while the wallet remains under the owner's sole control. secure-ai-trading-without-giving-up-custody

How does dollar sizing normalize risk across venues?

Different venues use different contract sizes, tick values, margin formulas, and minimum lot requirements. An agent that tries to reason in native units might miscalculate a stock lot, a crypto decimal, a perp contract, an options multiplier, and a prediction market share. The resulting errors can produce oversized positions, insufficient hedges, or failed orders. When the agent is managing a portfolio across five market types, these frictions multiply. A small rounding mistake on one venue can cascade into a cross market hedge break.

Felix sizes every order in plain US dollars. The agent specifies the desired notional value, and the API converts that value into the correct number of shares, contracts, tokens, or shares for the target venue. The agent does not need to know that a perps venue uses one contract size while an options venue uses another. The agent simply requests five hundred dollars of exposure, and the API handles the math. This removes an entire class of agent errors caused by unit confusion.

This normalization also makes risk limits easier to express. A cap of ten thousand dollars means the same thing whether the agent is trading on a stock broker or a prediction market. The owner does not need to translate dollars into venue specific units to set a policy. The API maintains the mapping, which reduces both agent errors and human configuration mistakes. Developers can write strategies that think in portfolio terms rather than venue terms.

The exact request schema is in the docs; the shape looks like this:

curl -X POST https://api.felix.trade/... \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "market_type": "perps",
    "direction": "buy",
    "notional_usd": 500
  }'

Notice that the agent only needs to state the market type, the direction, and the dollar amount. The API resolves the venue specific details. The owner can change the underlying venue or add a new market type without rewriting the agent's sizing logic. The abstraction keeps the agent's code clean and the owner's risk model consistent.