MCP Permission Checklist for Collaboration and File Servers at Banks, Broker-Dealers and Wealth Managers

Why collaboration and file servers need their own checklist

An MCP server is the connection point between an AI assistant and external tools, APIs and data sources. When that server fronts a collaboration platform or a file share, a single tool call can read a client record, edit a supervisory file or share a folder outside the firm.

OWASP guidance on secure MCP server development notes that, unlike traditional APIs, MCP servers operate with delegated user permissions, dynamic tool-based architectures and chained tool calls. One flaw therefore has a larger potential impact. A broad scope or an inherited credential is not a minor configuration issue in that model.

For banks, broker-dealers and wealth managers, the question an examiner or model risk reviewer asks is two-part: what was the AI allowed to do, and what did it do? Static permissions answer the first part only. The checklist below is organized so that each decision can be documented, reviewed and tested.

OWASP also separates guidance for building MCP servers from guidance for using third-party ones. Apply the full checklist to both, and use deeper vetting before connecting any external server to firm repositories.

1. Identity and credentials

Start by establishing whose authority each tool call carries. If the server inherits the signed-in user's access, the agent can reach everything that user can, including material the task never needs. If it runs on a shared service account, individual actions become hard to attribute.

Give each agent or MCP server its own credential, scoped to the tools it exposes, and assign a named owner. FINRA's 2026 Annual Regulatory Oversight Report describes identity and access management controls that enforce least privilege, require multi-factor authentication and maintain comprehensive access reviews, covering both human and non-human accounts. Agent and service identities belong in the same review cycle as employee accounts, with a documented cadence.

Record the identity model per server: user-delegated, dedicated service identity, or a combination. Where a call acts on behalf of a user, keep both the user and the agent identity in the record.

2. Scope by repository, folder and sensitivity

Define scope at the tool level, not the server level. A tool that searches a research library does not need access to client onboarding folders. Grant read, write, share and delete as separate capabilities, and default each to off until a use case justifies it.

Then restrict by repository and folder, and by sensitivity label where the platform supports one. NIST SP 800-123 advises setting identical permissions for the operating system and the server application, otherwise too much or too little access may be granted. Apply the same principle here: compare the effective permissions of the MCP server with those of the underlying file or collaboration platform, and resolve any mismatch in favor of the narrower one.

Finally, consider aggregation. The NCCoE concept paper on software and AI agent identity and authorization asks how to determine data sensitivity when an agent aggregates data, and whether users are authorized to see the aggregated response. Folder-level scoping alone does not settle this. Record how your firm decides the sensitivity of agent-produced output, and who owns that decision.

Where runtime policy enforcement complements native permissions

Native server and platform permissions remain the foundation. They set the outer boundary and should be reviewed regularly. They do not, however, show what an AI did within that boundary, and they cannot apply different treatment to two calls that use the same scope but carry different risk, such as reading one document versus bulk-exporting a folder.

Runtime policy enforcement fills that gap. Trussed enforces policy in the execution path across MCP servers and tool calls: allow, redact, block, rate limit, or escalate for human approval, applied to individual interactions and tool calls. The enforcement itself generates audit-ready evidence, so the record reflects decisions made at runtime, not reviewed after the fact. The scope is the individual call. It is not transaction-level governance or end-to-end workflow tracing.

This layer complements the checklist rather than replacing it. Scopes, identities and approvals still need to be designed and owned by your team, and the same checklist can be applied whether enforcement is built in-house or bought.