Who approves an AI trade? What broker MCP connections actually allow

An assistant can explain your portfolio without being allowed to change it. It can prepare an order that you submit yourself. Or it can hold a connection capable of submitting orders. All three experiences may be presented as “connect your broker to AI.”

Our earlier MCP infrastructure overview examined how agents reach financial tools. This follow-up asks a narrower question: which part of the connected system decides whether a proposed action may actually happen?

The distinction matters before choosing a model or comparing an agent’s reasoning. A persuasive answer, a paper account and a confirmation message each tell you something different about the system.

Separate access, environment and approval

Start with three questions.

Access: which actions can the connection perform? Reading positions, changing settings, cancelling an order and submitting one are separate permissions.

Environment: which account receives the action? Paper trading directs activity to a simulated environment. That can help contain financial consequences during testing, but it does not answer whether a human must approve each action.

Approval: what must happen before this particular action is sent? A rule in the prompt, a host confirmation screen and an execution service that rejects an unauthorized request occupy different places in the system.

The MCP tools specification recommends human oversight and confirmation interfaces, while leaving the interaction model to implementations. Its schema reference also treats tool annotations as hints. A readOnlyHint helps describe a tool; it does not constrain what the server’s credentials can do.

An OAuth consent screen adds another distinction: authorizing a connection is not necessarily authorizing each later order. The actual scope and approval policy determine what follows.

What the three connections document

These products expose different capabilities. This is a comparison of documented action boundaries, not a broker recommendation or a safety ranking.

Connection	Documented capability	Approval boundary to distinguish
SnapTrade hosted MCP	Reads connected brokerage data and can generate a brokerage-connection link. Its documentation says the MCP surface cannot trade, transfer money or alter account settings; issued tokens are scoped to reads.	Consent grants data access. Trading features elsewhere in SnapTrade’s API are outside this documented MCP surface.
IBKR standard AI Integration	Research, monitoring and trade-instruction preparation.	IBKR says the user reviews and submits each order. Preparing an instruction is distinct from executing it.
IBKR Autonomous Trading, separately described	Supported AI can execute within a funded AI Partition, with product and account restrictions.	IBKR describes a mode without approval for every order. Its page also qualifies eligibility and says availability is planned for specified entities. This review does not establish availability for any reader’s account.
Alpaca MCP v2	Exposes trading and data tools, with selectable toolsets. The configured trading environment defaults to paper.	Tool exposure and account environment need separate checks. In the inspected order wrapper, submission does not require a human-approval receipt. A host or additional service may impose one; that behavior was not tested here.

Connection

SnapTrade hosted MCP

Documented capability

Reads connected brokerage data and can generate a brokerage-connection link. Its documentation says the MCP surface cannot trade, transfer money or alter account settings; issued tokens are scoped to reads.

Approval boundary to distinguish

Consent grants data access. Trading features elsewhere in SnapTrade’s API are outside this documented MCP surface.

Connection

IBKR standard AI Integration

Documented capability

Research, monitoring and trade-instruction preparation.

Approval boundary to distinguish

IBKR says the user reviews and submits each order. Preparing an instruction is distinct from executing it.

Connection

IBKR Autonomous Trading, separately described

Documented capability

Supported AI can execute within a funded AI Partition, with product and account restrictions.

Approval boundary to distinguish

IBKR describes a mode without approval for every order. Its page also qualifies eligibility and says availability is planned for specified entities. This review does not establish availability for any reader’s account.

Connection

Alpaca MCP v2

Documented capability

Exposes trading and data tools, with selectable toolsets. The configured trading environment defaults to paper.

Approval boundary to distinguish

Tool exposure and account environment need separate checks. In the inspected order wrapper, submission does not require a human-approval receipt. A host or additional service may impose one; that behavior was not tested here.

IBKR’s page illustrates why a product name alone is insufficient. Standard integration and its separately described autonomous mode have different submission authority. Its documentation also says revoking the connection does not automatically cancel pending or partially filled orders. Access removal and order cancellation therefore need separate procedures. IBKR mode and revocation FAQs.

An account toolset can still contain writes

Alpaca’s pinned toolset definitions contain a useful detail: the account group includes patchAccountConfig. It is a configuration-changing operation alongside account reads. The watchlists group also mixes reading with creation, updates and deletion.

Disabling the trading group therefore does not, by itself, demonstrate that the remaining connection is read-only. Group labels are a starting point. The review needs to reach the individual operations.

The pinned server implementation separately selects the trading base URL from ALPACA_PAPER_TRADE and filters operations using the selected toolsets. These are different mechanisms. Changing one does not establish the other.

In the inspected order wrapper, the stock-order function builds a request and passes it to _post_order, which calls the orders endpoint. That wrapper does not require an approval token or invoke a human-confirmation exchange. This is a finding about this source path, not proof that every compatible host submits without asking.

The accompanying security middleware labels returned data as untrusted. That addresses how a model should interpret tool output. It is a different responsibility from deciding whether an order may be sent.

Give approval a specific owner

A 2 November 2026 preprint by Yao and colleagues examines confirmation across MCP servers and hosts. It reports gaps between those layers in its sampled systems. It is a new preprint, is not a finance-specific evaluation and does not establish the behavior of the broker connections in this article. Its relevance here is architectural: check who actually enforces the pause.

For a workflow that requires per-order review, we propose the following separation. It is a design to assess and test, not an implemented integration.

1. 01Propose

   What exact action is being requested?

   Account and environment · instrument · side · quantity · order type and price conditions

2. 02Check

   Does the proposal fit the applicable rules and current state?

   Policy version · holdings snapshot · open orders · missing information

3. 03Authorize

   Who approved this version, and where is denial enforced?

   Authenticated approver · proposal identity · expiry · rejection path

4. 04Submit & reconcile

   What did the broker accept, reject or fill?

   Submission identifier · broker response · uncertain status · later fills

Under this proposed design, approval refers to a particular version of the action. A later change to the account, instrument, size or order conditions requires a fresh check and approval. The execution component enforces that rule. A model-generated field saying approved: true is not an independent authorization record.

Keep the submission credential behind that component. If the agent can use the same credential through another server or direct API path, the proposed gate is bypassable.

Review the failed handoffs too

A demonstration in which the user approves an order tests one path. A more informative review also exercises refusal, missing context and uncertain outcomes.

Proposed scenario	Behavior to verify in a per-order approval workflow
The connection is intended to be read-only	Write tools are absent or denied. Check account changes and cancellation as well as new orders.
The user denies or dismisses approval	No order-submission request reaches the broker.
The proposed quantity changes after approval	The old approval cannot authorize the changed request.
Required holdings, valuations or open-order information is unavailable	The configured policy returns an explicit unresolved result instead of silently assuming a zero exposure or a pass.
A submission times out	Reconcile the original request and broker state before making another attempt.
Access is revoked while an order remains open	Confirm the separate process for identifying and handling outstanding orders.

Proposed scenario

The connection is intended to be read-only

Behavior to verify in a per-order approval workflow

Write tools are absent or denied. Check account changes and cancellation as well as new orders.

Proposed scenario

The user denies or dismisses approval

Behavior to verify in a per-order approval workflow

No order-submission request reaches the broker.

Proposed scenario

The proposed quantity changes after approval

Behavior to verify in a per-order approval workflow

The old approval cannot authorize the changed request.

Proposed scenario

Required holdings, valuations or open-order information is unavailable

Behavior to verify in a per-order approval workflow

The configured policy returns an explicit unresolved result instead of silently assuming a zero exposure or a pass.

Proposed scenario

A submission times out

Behavior to verify in a per-order approval workflow

Reconcile the original request and broker state before making another attempt.

Proposed scenario

Access is revoked while an order remains open

Behavior to verify in a per-order approval workflow

Confirm the separate process for identifying and handling outstanding orders.

These are acceptance criteria for a reviewer to run and record. We did not execute them against the three services.

Timeout handling deserves its own entry. Alpaca’s inspected wrapper explicitly warns that a request may have reached the broker even when the response was lost. An error message is therefore not proof that no order exists. Pinned submission code.

Download the review worksheet. Record the server version, host configuration, credential scope, account environment and evidence for each result. Leave untested rows marked untested. The worksheet supports documentation; it does not enforce permissions.

Where investor context fits

An execution boundary still needs something to check. Portfolio exposure, exclusions and investor rules have to reach the system in a usable form.

The TradingAgents–Investboard connector documents supplying policy and position context and posting the completed analysis to Investboard, which David Bartas founded, for storage and a mandate check. Our connector case study separates that record handling from model behavior and live server validation.

That is a role for context and records. A stored mandate verdict does not establish broker-side enforcement. Connecting it to an order gateway would require a separately implemented and tested execution path. The proposed architecture does not depend on using Investboard; the same responsibilities can be supplied by other systems or versioned local records.

The useful record connects the original proposal, the inputs checked, the authorization and the eventual broker outcome. It should preserve an explicit “unknown” when any handoff remains unresolved.

Sources and scope

This article was prepared with AI assistance from primary documentation and source files checked on 4 November 2026. No model benchmark, security audit, authenticated account test or investment-performance assessment was performed.

Alpaca source observations are pinned to commit 63cc4278d87b31f3ed4efcfaa55624095c6d7be8. Hosted documentation was reviewed as available on the stated date; it is not an immutable service snapshot. Availability, exposed tools and host policies can change.

• Protocol: MCP tools specification, version 2025-11-25 and tool annotations schema.
• Alpaca: pinned README, server construction, toolsets, order wrappers and output middleware.
• Interactive Brokers: AI Integration and Autonomous Trading documentation, including eligibility and availability qualifications.
• SnapTrade: hosted MCP capabilities and authentication. These claims concern that MCP surface, not every SnapTrade API.
• Research context: Yao et al., When Neither Side Confirms, preprint v1, submitted 2 November 2026. Its results are attributed to the authors and were not reproduced for this article.
• Investor context: TradingAgents–Investboard documentation and our earlier reproducible case study. The November review does not repeat that article’s offline experiments.