MCP permissions in wealth management: read access vs. action authority
An MCP connection can read live records and trigger changes. Learn how wealth firms can separate identity, data access, allowed actions, and human approval.
MCP permissions in wealth management should separate what an AI application can read from what it can change. A connection that retrieves a client briefing does not need the same authority as one that updates a client record. Before enabling either, establish whose identity the connection uses, which records it can reach, which operations it can perform, and when a person must approve the result.
Model Context Protocol, or MCP, gives AI applications a standard way to connect to external systems. Its tools specification describes operations that models can discover and invoke. MCP does not, by itself, define a wealth firm's approval policy. That responsibility belongs in the application, connected systems, and operating procedures.
Separate four permission decisions
Treat an MCP connection as four decisions, rather than a single enabled or disabled switch.
Identity. Establish the user and firm represented by the session. A tool call should not inherit an administrator's authority simply because the administrator installed the connection.
Data access. Define the households, accounts, documents, and fields that the user may retrieve. Read-only access still exposes information to the AI application and any other destination the workflow uses.
Action authority. Specify the operations that can change stored data or initiate another process. Reading a contact and changing that contact are different permissions, even when both appear in one conversation.
Approval. Decide which permitted operations also require review. A user's authority to update a record does not mean every model-generated update should execute without confirmation.
OWASP's excessive-agency guidance distinguishes unnecessary functionality, excessive permissions, and excessive autonomy. It recommends enforcing authorization in downstream systems, rather than asking the language model to decide whether an action is allowed.
Classify the work before granting access
Start with the intended job. For meeting preparation, an AI application might need to retrieve approved client context and summarize open items. Giving it unrelated write or delete operations creates authority that the job does not require.
Use these evaluation categories. They are not standard MCP scope names or OneVest tool identifiers.
- Read. Retrieve records the user already has permission to view. Evaluate field restrictions, retrieval volume, and where the returned information goes.
- Propose. Prepare a suggested update or task without committing it. Keep the proposal separate from the authoritative record.
- Write. Commit an approved change. Check the target, permitted fields, validation rules, and required review.
- External action. Send information or initiate work in another system. Evaluate that destination's permissions and approval requirements separately.
For each category, document the allowed object, operation, user, and condition. A broad instruction such as "manage this client" is not a useful permission boundary. A bounded instruction identifies the record and intended change, while the system still enforces what the user can do.
Keep authentication separate from authorization
Authentication establishes who is making the request. Authorization determines what that identity may do. Both need attention when a model can select operations across connected systems.
The July 2026 MCP authorization security considerations require servers to validate that incoming access tokens were issued for them. They also prohibit passing the received client token through to an upstream API; that upstream connection uses a separate token issued by its own authorization server.
These are protocol implementation requirements, not evidence of a particular vendor's configuration. Ask the implementation team which protocol revision and authorization flow it supports, how user permissions reach downstream systems, and how access changes take effect.
For a wealth firm, the practical test is whether an advisor's request stays within that advisor's permitted book and operations. A successful login is insufficient evidence. Test a request for an inaccessible household and a prohibited change, and inspect the actual system response.
Put review at the point of commitment
A review step needs to identify the action being approved. "Allow this connection" is different from "approve this update to this record."
For a record change, a useful review presents the target client, existing value, proposed value, and source of the new information. It should distinguish a model's inference from a verified client instruction. If the record changes before execution, the workflow should revalidate the proposal rather than silently apply an outdated decision.
The MCP tools specification recommends human involvement with the ability to deny tool invocations, visible tool activity, and confirmation prompts. It does not mandate one specific interface. Evaluate the actual application your team will use, not an assumed confirmation screen.
OneVest's Client Management page provides a concrete product example: advisors review and confirm extracted KYC fields before they are written back to the profile. That documented workflow does not establish that every MCP action has the same review mechanism. Confirm the behavior for each intended operation.
Treat returned content as evidence, not authority
A document, email, or retrieved note may contain instructions. Those instructions must not enlarge the session's permissions or replace the firm's approval policy.
OWASP identifies indirect prompt injection as one possible trigger for excessive agency. Its recommended controls include minimizing available functions, limiting downstream permissions, and requiring human approval for high-impact actions. A prompt telling the model to behave carefully is not a substitute for those controls.
Include a test document that asks the application to retrieve an unrelated household or send client information elsewhere. The desired result is a denied operation without unauthorized disclosure or write-back. Use synthetic data in a controlled test environment.
Also review the AI application's own handling of client information. Permission to read a record from the wealth platform does not settle the application's retention, logging, or additional-connection policies.
Test denied actions as carefully as successful ones
A useful demonstration proves the boundary, not only the happy path. Ask for evidence of the following scenarios.
- A permitted user retrieves the expected client context without unrelated records.
- The same user requests an inaccessible household and receives no protected data.
- A read-only workflow attempts a write and the connected system rejects it.
- A reviewer rejects a proposed change and the authoritative record remains unchanged.
- Access is removed and a subsequent request no longer succeeds under that permission.
- An ambiguous result is investigated before retrying, so a completed operation is not repeated accidentally.
For each test, retain the identity, requested operation, target, review decision where applicable, and observed outcome. Protect that evidence because it may contain client information. These are evaluation recommendations, not a universal regulatory checklist or proof that software alone meets a firm's obligations.
What OneVest's published materials establish
OneVest's MCP announcement describes authenticated sessions scoped to users and firms. It states that the server supports reads and write-back within the authenticated user's permissions, including client briefings, call logging, and record updates.
Its platform materials describe role-based access, logged actions, and human review where the firm's compliance controls require it. These are starting points for an implementation discussion. They do not establish every available operation, approval setting, AI-client configuration, or token policy.
Evaluate one bounded use case against the four decisions: identity, data, action, and approval. Expand only when the next use case has its own permission boundary and test evidence.