AI recommendations are not permission to act

Schwab's restrictions on unauthorised agents expose an AEO problem: public discovery, private information and consequential actions need different rules.

Permission to discover an offer should never be mistaken for authority to transact.

Author: Ian Ash

Published: October 17, 2026

Category: Analysis

Brands want AI to recommend them. They are considerably less comfortable letting the same software operate inside a customer's account. Schwab's reported response to external agents illustrates why that is not a contradiction: making an offer discoverable and authorising an action are different decisions, with different consequences for security, service and the customer relationship.

On October 16, Bloomberg reported, in a copy syndicated by Moneycontrol, that Charles Schwab was actively blocking unauthorised agents attempting to move clients' money. CEO Rick Wurster described plans for secure model context protocol servers that would let external large language models view account balances and conduct research, while withholding permission to move money. Those controlled connections were described as a future plan, not an already available read-only service. [1]

The same report placed Wurster's remarks alongside Jamie Dimon's earlier-week opposition to giving outside agents free rein with JPMorgan customer-account information. It does not disclose either company's complete access policy or independently test its implementation. As the earlier JPMorgan and customer-loyalty analysis explained, a restriction on account access is not evidence that a company is withdrawing from public AI discovery.

Access decisions need a task, not a single AI label

An assistant explaining savings accounts performs a different job from an agent transferring money between them. Comparing airline baggage policies differs from changing a booking; preparing an insurance application differs from submitting it. Treating all of these as one decision about “AI access” obscures what has actually been permitted.

Cloudflare's documentation makes a related distinction at the website-traffic level. It names Search, Agent and Training as three AI-related use cases customers can manage. Search collects or indexes content for later answers; Agent describes real-time activity on a person's behalf; Training crawls material to train or fine-tune a model. Cloudflare also says a single bot can have more than one behaviour and that other classifications exist. [2]

These are behaviour classifications, not a complete customer-authorisation policy or proof of an agent's identity. They nevertheless support a useful operating principle: decide what software may do, with which information and through which channel. Blocking an automated transaction need not make public product information harder to retrieve. Publishing that information does not grant access to private records or permission to enter an agreement.

Security and commercial interests can coexist

The security concerns are credible. A business needs to know who authorised software to act, what the authority covers and what happens if an action is wrong. A password handed to an outside tool is not the same as a narrowly scoped, revocable connection.

There is also a commercial tension. An assistant could help compare alternatives, identify an expensive renewal or prepare a switch, weakening advantages that depend on familiarity and the effort of changing suppliers. That is an economic inference, not evidence that a particular company's security rationale is a pretext. Genuine security concerns and commercial incentives can exist together.

A restriction may feel reassuring when it prevents an unfamiliar tool from moving money, but obstructive when it blocks a trusted assistant from completing an explicitly approved task. Which reaction dominates remains a research question. The announcements reviewed here do not measure customer switching, loyalty effects or the pace of autonomous adoption. The existing-customer advice article explains why these tasks deserve separate research rather than a generic question about trusting AI.

Four permissions for an agent strategy

A more useful approach separates Discover, Compare, Prepare and Act. This is a proposed AEO Updates framework, not an industry standard, a validated risk scale or a requirement that every business enable every stage. The permissions are not an automatic progression. They depend on the task, information involved and consequences of failure; even reading private information can carry substantial risk.

Discover: let AI read public facts

Make product descriptions, eligibility criteria, service information and policies accurate and accessible through appropriate channels. Assign ownership for updates and test whether assistants retrieve and correctly describe the offer. Public discovery should not imply permission to read a customer's account.

Compare: let AI evaluate the complete offer

Keep prices, limitations, qualifying conditions and meaningful differences close to the claims they qualify. A headline rate without its conditions or a price without mandatory charges can distort comparison. Test whether the assistant represents the full offer accurately, including situations in which it is unsuitable. Visibility has limited value when the answer creates expectations the business cannot meet.

Prepare: let AI assemble a draft or shortlist

An agent might build a shopping basket, assemble an itinerary or complete a draft application. Specify which information it may use, which fields it may change and when the customer must review the result. Keep permissions narrow and changes reversible where possible. Preparation must not silently become submission: a draft that creates a binding commitment belongs in Act, regardless of the interface's label.

Act: permit a specific consequential commitment

Buying, booking, submitting an application or moving money requires a task-specific authorisation model. Define the permitted action, scope, amount, recipient and duration where relevant. Require confirmation at appropriate points and preserve a record of what was authorised and executed. Some businesses will reasonably stop at preparation and hand the customer into their own authenticated process; that can be a deliberate service-design choice, not a failure to adopt AI.

The framework's purpose is to make each permission explicit. Permission to discover an offer should never be mistaken for authority to transact. The retailer guide applies a related distinction to discovery, checkout and a completed order.

Recognising an agent is only the first check

Visa's Trusted Agent Protocol offers a publicly documented cryptographic specification for recognising approved agent requests and validating message integrity. Its merchant specifications distinguish the agent-recognition signature from linked consumer or device-recognition objects and payment containers. Recognition data can help match a represented consumer; payment containers carry integration-dependent payment information. These are different functions. [3][4]

A valid signature does not by itself establish that a customer legally consented to a particular purchase, oblige a merchant to accept the request, impose a universal spending limit or guarantee settlement. Visa's product terms place responsibility for applicable disclosures and legally required consents on implementers. Documentation and a sandbox reference are also not evidence of widespread production deployment. [4][5]

Before granting access, a business should answer four operating questions: can it verify the requesting service; confirm the customer's authority and data scope; enforce those boundaries when an action occurs; and provide revocation, records and recovery? Where reversal is impossible, confirmation and dispute handling become especially important. These are proposed operating questions, not a claim that adopting one protocol resolves every risk. The system carrying out the action must enforce the permission, rather than relying only on an assistant to remember an instruction.

Measure the permitted journey, not just the answer

A visibility dashboard can show whether a brand appears in selected answers. It cannot, by itself, show whether a customer can complete the next permitted task. Test representative journeys alongside visibility: find an offer, compare its conditions, prepare a choice and attempt an authorised handoff or action.

Record where the journey stops and why. Inaccurate information, a deliberate security restriction and a broken handoff are different problems with different owners. Report retrieval, offer accuracy, draft completion, permitted handoff completion and action completion separately. Give each action rate its own denominator of eligible, authorised attempts. A refusal that correctly enforces policy is not automatically a failed transaction, and these operational rates are not citation percentages.

A hypothetical Canadian bank could make public fees and eligibility easier to interpret while retaining strict account controls, then support a clear handoff from comparison into a bank-owned application process. Neither choice requires unrestricted autonomous banking. Customer research should distinguish understanding a fee, comparing mortgages, drafting an application and moving funds, then test the permissions people would grant and how restrictions affect provider trust.

AEO Updates Takeaway

The emerging competitive issue is whether brands can accommodate customers who arrive with an assistant while maintaining clear accountability. A blanket welcome can expose customers to actions they did not intend; a blanket refusal can make useful assistance unnecessarily difficult. For AEO teams, the expanded brief is to help the brand appear accurately in the answer, then work with product, security and service teams to make the next permitted step clear and dependable. Being recommended creates consideration. Whether an authorised handoff works may determine whether that consideration becomes business; the loyalty effects still need to be measured.