AI trading agents: autonomy, capital permissions and control boundaries

An AI trading agent is software with permission to act

An AI trading agent observes information, forms or selects a plan, uses tools and checks what happened. A chat box does not make software an agent. The meaningful line is whether it can move from analysis to an action that affects an account without asking a person to approve every step.

Its authority might be as narrow as cancelling an order after a limit breach, or broad enough to choose instruments, rebalance a portfolio and manage collateral. Once authority expands, model quality is only one part of the assessment. Credentials, hard policies, execution code, reconciliation and human intervention all become part of the product.

Agent, assistant, signal and bot are different jobs

Products often span more than one row. A managed product may use agents internally, while a conventional bot may use a model only to classify market state. Use the broader AI-for-trading taxonomy if the product's action boundary is unclear.

A seven-part control loop

A language model can interpret context or choose among approved actions. It should never be the sole judge of whether an order is legal, affordable or inside the portfolio mandate. Code should enforce hard limits after the proposal and before execution.

Turn vague instructions into reviewable intent

“Buy more ETH” leaves too much unresolved. A reviewable intent names the instrument, side, maximum notional, execution window, price protection, reason, evidence timestamps and a unique action ID. Derivatives also require leverage, collateral impact and liquidation constraints.

Any arrow can break. A venue may accept an order even though the request times out locally. Retrying can then double the exposure unless the request is idempotent or the agent checks open orders first. Fills can be partial, and an onchain transaction can stay pending while the market moves. The agent has to read current state instead of assuming its last command worked.

Keep hard controls outside the model

• Least privilege: credentials permit only required venues, accounts, assets and actions.
• Exposure limits: position, order, concentration, leverage and loss limits are enforced in code.
• Freshness limits: stale prices, balances, model outputs and venue status are rejected.
• Price protection: orders have maximum slippage, limit prices or minimum received amounts.
• Approval thresholds: unusual size, new assets or withdrawals require a human or separate signer.
• Idempotency: retries cannot silently duplicate an order or transaction.
• Reconciliation: account and onchain state are compared with the agent's internal record.
• Emergency control: an independent operator can pause execution and revoke authority.

This is the systems boundary described in the automated trading systems guide. Calling the decision layer an agent does not remove established requirements for supervision, testing and operational control.

The news can be right while the trade is wrong

Suppose an agent correctly identifies a negative announcement and proposes reducing a position. The source may be authentic, yet the proposal can still be unsafe: the market price may have already moved, the account may have an open hedge, liquidity may be thin, or a large market order may create more loss than waiting.

A controlled path checks the source timestamp, current positions, open orders, liquidity and modeled execution cost. It expires the proposal quickly. Policy may resize the action, switch to a limit order, request approval or reject it. This is why factual accuracy, strategy quality and execution quality require separate tests.

Failure modes unique to tool-using agents

Hallucinated or overextended evidence

A source may be real while the conclusion is unsupported. Evaluation should test whether each material claim is faithful to the source, whether contrary evidence was omitted and whether the evidence is sufficient for the proposed action. A fluent explanation is not a substitute for those checks.

Agent hijacking

A tool-using agent consumes untrusted material: websites, token descriptions, news, messages and API responses. Malicious instructions embedded in that material can redirect a vulnerable agent. NIST's agent-hijacking work describes this as a separation problem between trusted instructions and untrusted data. Restricting tools and enforcing policy after model output reduces the consequence of a successful manipulation.

Goal drift

“Increase return” can encourage concentration or leverage unless the mandate defines the permitted risk. Objectives need explicit constraints and conflict rules. When two goals disagree—reduce drawdown and avoid realizing a loss, for example—the system should follow a documented priority or escalate.

Hidden delegation

An agent may call another model, service, smart contract or bridge. Each dependency adds data, availability and permission risk. The execution record should identify the versions and endpoints that materially affected the action, not only the name of the front-end agent.

A benchmark that rewards the demo

A benchmark can reward completion while missing unsafe shortcuts. Test rejected actions, repeated attack attempts, regime changes, missing data, contradictory sources and venue failures. Then run shadow mode on live data before allowing bounded capital. A passing backtest establishes neither reliable tool use nor live execution quality.

Questions to settle before granting authority

Logs, proofs and returns answer different questions

An intent log shows what the agent proposed. A policy record shows what a control allowed. An order or transaction record shows what was submitted. A fill, receipt or state proof can show what happened at an execution layer. None of these alone proves that the strategy was profitable, suitable or complete.

For onchain actions, continue to what trade proofs can and cannot prove. For portfolio authority, custody and exit mechanics, read onchain asset management. For AI operating directly in DeFi workflows, use the DeFAI guide.

Sources and scope

• CFTC Technology Advisory Committee — Artificial Intelligence in Financial Markets
• NIST — AI Risk Management Framework
• NIST — Building Evaluation Probes into Agentic AI
• NIST — Strengthening AI Agent Hijacking Evaluations
• FINRA — AI in the Securities Industry: Key Challenges
• Onchain Off Emotion editorial methodology

These examples show what to inspect; they are not evidence that a particular agent is safe or profitable. Confirm its current permissions and features before giving it access to funds.