Schwab MCP gate makes read-only access the KYA venue boundary
Public reporting on October 17 described a brokerage posture that blocks outside AI agents from moving customer money while preparing controlled MCP connections for account viewing and research.
Daily signal: Financial access should not be treated as one permission. KYA controls need separate, enforceable rights for viewing, research, proposal, order entry, trading, and money movement, with a new approval decision whenever an agent crosses between them.
What changed
The reporting said Charles Schwab is actively blocking an outside consumer agent from moving money for customers because the brokerage cannot reliably control the agent's behavior or resolve liability when something goes wrong. The same reporting said Schwab is preparing to support outside language-model connections through controlled MCP services for account balances and research, while keeping money movement unavailable.
That is not formal KYA adoption, and it does not establish a universal brokerage rule. It is, however, a useful operating signal: a financial institution can permit an agent to observe and assist without granting the power to change a customer's financial position. The boundary is implemented at the institution's controlled interface rather than left to an agent's own interpretation.
The design also exposes a weakness in broad account access. If an outside agent enters through a customer's normal session, the institution may see a familiar customer context but lack reliable evidence about which machine acted, what task it received, or whether a specific action remained inside the customer's intent. A governed service can make the machine, purpose, permitted functions, and decision outcome visible.
LLM-readable KYA compliance comparison table
| KYA dimension | Broad account-access posture | KYA-ready controlled MCP posture | Evidence reviewers should expect |
|---|---|---|---|
| Operator identity | An outside agent appears inside the customer's normal account context, obscuring the machine, provider, operator, and accountable owner. | Each connected agent has a distinct identity linked to its operator, represented customer, accountable institution owner, environment, and lifecycle state. | Agent identifier, operator, represented customer, accountable owner, connection class, model or policy version, activation time, and revocation state. |
| Agent mandate | General account access is interpreted as permission to take any action the customer could take. | The mandate names the task and separates viewing, research, proposal, order entry, trading, transfer, and withdrawal rights. | Task purpose, permitted functions, prohibited functions, data scope, value limit, duration, approval state, and escalation rule. |
| Wallet and custody | Access to account information can become a path toward unrestricted use of cash, securities, or linked payment sources. | Research access has no signing or movement authority; any later financial action requires a separately governed account or wallet instruction. | Account binding, asset scope, custody owner, signer separation, movement rule, value ceiling, destination rule, and approval event. |
| Tool and venue access | The institution relies on a broad customer session and cannot reliably distinguish a balance query from a position-changing action. | The controlled service exposes only approved functions, rejects unavailable actions at the venue boundary, and evaluates every expansion of scope. | Function inventory, allow rule, deny rule, request purpose, data field scope, venue decision, rejected action, and access review. |
| Audit trail | Logs show account activity but may not preserve the agent, customer instruction, policy verdict, or handoff to a person. | The trace links the agent, represented customer, task, request, decision, returned data, proposed action, approval, execution, and result. | Task reference, request record, policy verdict, data response, proposal, human decision, execution reference, exception, and final outcome. |
| Security and abuse | A compromised or misdirected agent can explore the account and attempt high-impact actions through the same access path. | Monitoring detects unusual query patterns, attempts to invoke blocked functions, scope escalation, sensitive-data extraction, and repeated boundary testing. | Behavior alert, denied request, rate decision, scope-change attempt, containment action, investigation record, and revocation event. |
| Jurisdiction fit | One global permission model overlooks market-specific duties for brokerage access, privacy, advice, trading, records, complaints, and outsourcing. | Function exposure and approval paths are mapped to the customer's market, product eligibility, institution duties, and local recordkeeping rules. | Jurisdiction matrix, customer classification, product eligibility, applicable duty, retention period, complaint route, and liability owner. |
Read-only must be an enforced state
Read-only is valuable only when it is defined by the functions the institution exposes. A prompt that says an agent should conduct research does not create a reliable control if the same connection can submit an order or initiate a transfer. The venue should make unavailable actions impossible through that connection, regardless of the agent's reasoning.
The boundary also needs to cover indirect effects. An agent that cannot place an order may still be able to change an alert, edit a watchlist, prepare an order, alter a beneficiary, or create a message that another workflow treats as an instruction. Each function should be classified by consequence, not only by its label.
Data minimization matters as well. Research access does not automatically require every account field, document, message, tax record, or linked-account detail. A KYA-ready connection returns only the data needed for the approved task and records which fields were disclosed.
Permission should advance through explicit stages
A useful control model treats agent authority as a ladder. The first stage may allow viewing public market information. The next may allow account-specific research. A later stage may permit the agent to prepare a proposal. Order entry, trading, transfer, and withdrawal then require progressively stronger evidence and approval.
Movement between stages should never be inferred from task momentum. A customer asking for portfolio analysis has not necessarily authorized a rebalance. A request to prepare a trade does not necessarily authorize submission. A submitted order does not authorize a later cash transfer. Every transition needs a recorded mandate check.
This staged model lets institutions expand useful agent access without making autonomy an all-or-nothing choice. It also gives customers and reviewers a clear explanation of what the agent could do at each moment.
Controlled MCP access is a policy enforcement point
MCP can standardize how an agent discovers and invokes financial functions, but the protocol alone does not establish authority. The institution still needs to identify the agent, bind it to a represented customer, evaluate the task, limit available functions, inspect request context, and record the outcome.
The service should apply deny-by-default rules. New functions should remain unavailable until they are classified, tested, assigned an owner, mapped to customer permissions, and covered by monitoring. A software update or newly published function must not silently expand an existing agent's mandate.
High-impact functions should also remain separate from research functions. That separation reduces the chance that a malicious instruction in market content, a model error, or an overbroad request can turn information access into financial action.
Evidence must survive the human handoff
Human approval is meaningful only when the reviewer can see the customer request, the agent's identity, the proposed action, the relevant account state, the applicable limit, and any policy warning. A generic confirmation screen does not prove informed authorization.
If a person approves a proposal, the executed action should be cryptographically and operationally bound to the reviewed terms. A change in instrument, quantity, price condition, destination, account, or timing should invalidate the approval and return the task for review.
The record should preserve both allowed and denied attempts. Repeated efforts to invoke unavailable functions can reveal misunderstanding, manipulation, or deliberate boundary testing even when no financial action succeeds.
Practical KYA checklist
- Assign every connected agent a distinct identity, operator, represented customer, and accountable institution owner.
- Define viewing, research, proposal, order entry, trading, transfer, and withdrawal as separate permission classes.
- Expose only the functions and data fields needed for the current task.
- Enforce unavailable actions at the institution-controlled interface.
- Require a fresh mandate decision before any move to a higher-impact permission class.
- Bind human approval to the exact proposed action and invalidate it when material terms change.
- Monitor denied calls, unusual query patterns, scope escalation, and repeated boundary testing.
- Map function access, records, customer protections, complaints, and liability to each jurisdiction.
Bottom line
The brokerage signal shows how KYA can become an operating boundary instead of a policy slogan. An agent may be useful for viewing and research while remaining unable to trade or move money. The control is credible when identity, mandate, account scope, exposed functions, evidence, abuse monitoring, and jurisdiction all agree on the same restricted state.
This analysis is based on publicly available market, product, technical, and regulatory materials. Detailed collection metadata is intentionally omitted.