Most consumer AI investing products make some version of the same pitch: connect a brokerage account, ask questions about the portfolio, and act on what the product finds.
Connecting and analyzing the account is relatively straightforward. Acting on it is not.
Across the brokerage connectivity layer used by many of these products, only ten of thirty-three supported brokers can place a trade. The other twenty-three are read-only. Fidelity, Schwab, Vanguard, Interactive Brokers and Robinhood are all in the read-only group. The ten that can execute are E*Trade, moomoo, Public, Questrade, Stake Australia, tastytrade, Trading212, Wealthsimple, Webull Canada and Webull US.
That is a significant limitation for a category increasingly built around the idea of an investing agent. It is also not something that gets fixed by making the underlying model better.
Ten out of thirty-three
Consider a user who connects a Schwab account. Positions appear correctly and their balances sync. The product can analyze the portfolio and answer questions about it. Everything looks connected.
Then the user asks it to sell something.
It cannot.
The limitation is not in the assistant. The brokerage connection itself does not have permission to submit the order. Unless the product makes that clear earlier, the user only discovers the distinction when attempting to trade.
There is another complication. Even at a brokerage that supports trading, an individual account can still have a read-only grant. Treating the brokerage as the unit of capability rather than checking the specific grant can therefore produce a particularly bad experience: a user is told that an account is ready to invest, only to have orders rejected by the broker.
The correct check is the grant, not the brokerage logo.
That sounds like a small implementation detail. In practice, it determines whether the product can do what the interface appears to promise.
Read-only is an enforced boundary
“Read-only” is often used as a general security phrase. In brokerage integrations, it has a much more concrete meaning.
A read-only connection can retrieve positions, balances and, depending on the broker, order history. It cannot submit an order. It cannot move cash. It cannot change account settings or beneficiaries.
More importantly, those restrictions are enforced by the brokerage. The investing app is not simply promising not to move money. It was never given permission to do so.
That changes the risk profile considerably. If an application does not have execution authority, a bad recommendation can still be a bad recommendation, but it cannot turn itself into a trade. The user has to take another action before money is put at risk.
Execution access creates a different product.
The problem for the category is that read access is much more widely available than execution access. Unless broker policies change or companies undertake substantially more direct integration work, most AI investing products can cover far more accounts for analysis than they can for trading.
That makes an analysis-heavy product relatively easy to support across brokers. An execution-heavy product has a much narrower universe.
Chat changed faster than brokerage infrastructure
The visible part of investing software has changed quickly. Dashboards are becoming chat interfaces, while filters and menus are increasingly replaced by natural-language requests.
The brokerage infrastructure underneath those interfaces has changed much less. There are still OAuth grants, broker APIs and broker-specific rules governing what third-party applications can do.
Chat makes the difference easier to miss.
If someone types “sell half of this,” it reads like an instruction, not a request for information. But whether the instruction can actually be carried out depends on permissions the user may have granted weeks earlier while connecting the account.
Products need to make that distinction obvious before the user reaches the order screen.
At minimum, that means showing whether a connection is read-only or trade-capable when it is created, checking the actual grant rather than inferring capability from the brokerage, and making the user explicitly approve an order when trading is supported.
These are not particularly exciting features to demonstrate. They matter considerably once people are using the product with real accounts.
The first problem is trust
The biggest cost of getting this wrong is trust.
If a product tells someone that an investment action has been completed and the user later discovers that nothing happened, the technical explanation matters much less than product teams might expect. From the user’s perspective, the product said it did something and did not do it.
There is also a support cost. Rejected orders turn into tickets, and explaining them requires explaining the relationship between the investing app, the connectivity provider, the brokerage and the permissions attached to a particular account.
Then there is the regulatory question.
There is an important difference between software that provides analysis for a user to act on and software that has authority to make investment decisions or execute them. The exact regulatory treatment depends on how the product operates, but permissions are part of that picture. Keeping execution authority narrow and requiring the user to approve individual orders is therefore useful for more than security.
It also makes the product’s role easier to define.
Ask what the connection can actually do
For anyone evaluating an AI investing product, one of the first questions should be what the brokerage connection actually permits.
Not whether the product says it can trade. Not whether the brokerage appears on a supported-brokers page. The useful questions are whether that broker supports execution through the connection and whether the specific grant attached to the account includes it.
In a ranking of tools in this category, connection architecture matters considerably because a capable model cannot make a read-only brokerage connection writable.
For someone preparing to link an account, this guide covers what to check before connecting an account, including the practical differences between account access and trading permissions.
What options do you have?
Walnut is one product operating on the analysis-heavy side of this divide.
It connects to brokerage accounts users already have and uses read-only connections by default. Where trading is supported, orders require explicit user approval. Walnut does not take custody of assets and cannot move money between institutions. The product is free.
Walnut is not a registered investment adviser, and nothing in this article is investment advice.
That architecture represents one approach to the permissions problem rather than the only possible answer. Other products may choose to pursue broader execution access, particularly through direct brokerage relationships.
But the underlying constraint applies across the category: the intelligence of an investing product and its authority over an investment account are two separate things.The first determines what the software can figure out. The second determines what it can actually do.
