The Model Context Protocol (MCP) is an open standard that lets AI applications connect to external tools and data through servers. When one of those servers fronts a file repository, an AI agent can search, read, and sometimes write your files through a handful of tool calls. That is the value of MCP, and it’s also the exposure.
Most MCP security guidance focuses on the protocol: authenticating clients, validating tokens, and vetting servers. That guidance matters. But the specification governs who may talk to an MCP server. It does not govern which of your files that server will return once the conversation starts. This guide covers what the spec requires, which MCP risks reach your files, and how to put control on the file itself.
What Is Model Context Protocol (MCP) and How Does It Access Files?
MCP has three parts. A client is the AI application, such as an assistant or an agent framework. A server exposes tools and resources, such as "search files" or "read this document." And behind the server sits the system it talks to, such as a SharePoint site or a Google Drive.
The server reaches that system with its own credentials, and this is the part that decides the exposure. A file-access server pointed at your SharePoint tenant usually authenticates with one service account, often granted broad read scope so that search works across sites. Every tool call from every connected agent runs under that one identity.
That makes the service account the blast radius. If the credential can read a whole tenant, any request that gets through the server can read a whole tenant. Your blast radius isn't a choice you made. It's an architecture you inherited from the connector.
Discover What Your MCP Servers & AI Agents Can Read
Continuously inventory sensitive data across SharePoint and Google Drive, evaluate MCP server service account permissions, and identify over-broad agent access before a breach occurs.
MCP Authorization Specification: Technical Scope and Security Limits
The MCP authorization specification is more specific than most summaries suggest, and it is clear about its own scope.
On the requirements side, when authorization is used on an HTTP transport, it follows OAuth 2.1. The MCP server acts as an OAuth resource server. Servers must validate that an access token was issued specifically for them, and must not accept or pass through tokens meant for other resources. Clients must send the OAuth resource parameter and implement PKCE. Insufficient permissions return a 403.
On the open side, three things stand out:
- Authorization is optional: The spec says so directly. A server that does not implement it is still a valid MCP server.
- Local servers are told to skip it: Implementations using the STDIO transport should not follow the spec and should retrieve credentials from the environment instead.
- The authorization server is out of scope: How scopes are decided, and what the server's own backend credential can reach, are left to the implementer.
The spec secures the door to the server. What the server can read behind the door is set by its own credential, and nothing in the protocol narrows it to the files a given request should see.
Mapping MCP Vulnerabilities to File-Layer Exposure Risks
Several documented MCP risks end in file access. The table shows how each one gets there and which layer holds the control.
| Risk | How it reaches your files | Where the control lives |
|---|---|---|
| Over-broad server credential | The service account can read a whole site or drive, so every tool call inherits that reach | Server configuration, plus file-layer policy (OWASP LLM06: Excessive Agency) |
| Servers with no authorization | Authorization is optional, so a server can serve files to any client that can reach it | Server configuration and network policy |
| Tool poisoning | Instructions hidden in a tool's description steer the agent to read or send files | Server vetting, plus rules on what a file may be sent to |
| Tool descriptions changed after approval | A server that passed review changes behavior later | Re-review on change, plus controls that do not depend on trusting the tool |
| Token theft | Stolen tokens produce requests that look legitimate to the server | OAuth controls, short-lived tokens |
Two columns matter here. The server-side controls reduce the chance of a bad request reaching your files. The file-side controls decide what happens when one does.
Enforcing File-Layer Access Controls Behind MCP Tool Servers
Three layers work together. Each one assumes the one before it can fail.
At the server: Require authorization on every HTTP server. Use short-lived tokens and validate the audience. Give each server its own least-privilege credential scoped to one data domain, instead of one account for everything. Keep an allowlist of approved servers, and re-review a server whenever its tool descriptions change.
At the file: This is the layer the protocol cannot provide. Classification labels drive policy, so the system knows which files are sensitive before any agent asks. AI egress rules decide what reaches an AI tool: block the file, limit it to approved tools and groups, or allow it with sensitive fields redacted. For restricted or high-risk files, per-file FIPS 140-3 validated encryption with more than 20 contextual controls ensures that even a valid server token is insufficient without explicit file-level authorization. The file evaluates who and what is asking, from where and in what context, and a request that does not meet policy is denied and logged. The file defends itself, whichever path the request arrives by.
In the record: Every file action is recorded, and the log can be exported with cryptographic verification that it has not been altered. Guardian anomaly alerts flag unusual access, such as an agent reading a controlled library in bulk, and Drop the Gate can freeze that access automatically. For what a useful log contains, see Audit Logs for File Access.
Theodosian's discovery and classification step comes first in practice. You cannot scope a server's credential to the right files until you know which files are sensitive and which agents can already reach them. See Best Sensitive Data Discovery Tools in 2026.
MCP Server Security Review: A 5-Point Vetting Checklist
A short review before connection catches most of the avoidable exposure. Ask these five questions about any server.
| Question | What a good answer looks like |
|---|---|
| Who operates it, and how is it maintained? | A named owner, a release process, and a way to be told when it changes |
| What can its backend credential read? | Scoped to the data the use case needs, not a whole tenant |
| Does it require authorization? | Yes, with tokens issued for that server and short-lived |
| How do tool descriptions and updates reach you? | Changes are visible and trigger a re-review |
| What does it log? | Which agent asked for which file, and when |
If an answer to the second question is "the whole tenant," the file layer is where you narrow it. Agentic AI Security: The Governance Gap covers why agents need identities and scopes of their own, and AI Guardrails for Enterprise Data covers which controls belong at which layer.
When the container breaks, the file doesn't. An MCP server acts as a container with broad credential access. Persistent file-layer enforcement ensures that a single connector does not dictate security limits for all data behind it.
Enforce Persistent Security Behind Every MCP Tool Server
Wrap sensitive assets in FIPS 140-3 validated encryption, enforce contextual access rules, and automatically block unauthorized AI agent reading.
FAQs: Model Context Protocol Security and Data Protection
Does MCP encrypt or restrict the files an agent reads?
No. MCP authorization controls access to the server. The server's backend credential decides which files it can return, and the protocol does not encrypt file contents or narrow results to a request's context. File-level encryption and policy are a separate layer.
How do I find out which AI agents can already reach our sensitive files?
Start with discovery. Theodosian's continuous discovery maps which people and which AI agents can reach which files across SharePoint, Google Drive, Box, and other repositories, with each file classified as PII, PCI, PHI, ITAR, trade secret, or another category. That gives you a list of real exposure before you scope any server's credentials.
Should we block MCP servers entirely?
Blocking outright tends to push use toward unmanaged tools, the same pattern as shadow AI. A better default is to approve servers one at a time, scope each credential to one data domain, and put file-level controls behind them so a single server cannot set the limit for everything it touches.