MCP for teams
Is MCP secure? What teams should know
MCP is a protocol, so its security depends on how servers are built and run. Here are the real risks, the controls that matter, and what to check before you connect.
"Is MCP secure?" is the right question with a slightly wrong shape. MCP is a protocol, not a product, so asking if it is secure is like asking if HTTP is secure. The answer depends almost entirely on what is on either end of the connection and how it is configured.
So the useful version of the question is: what do I actually need to check before I let an AI tool connect to an MCP server that touches my data? Let us walk it.
The protocol vs the server
The protocol part is the boring, good part. MCP supports authenticated connections, encrypted transport, and scoped access. There is nothing in the spec that forces you to expose data in the open.
The risk lives in the servers. An MCP server is software someone wrote that sits in front of your data and decides what to expose and to whom. A careless server leaks; a careful one does not. If you are new to the architecture, what is MCP lays out the client/server split this all rests on.
So when you evaluate "is this secure," you are really evaluating a specific server and how it is run.
The risks that actually bite
A short, honest list of what goes wrong in practice:
- Over-exposure. A server pointed at a whole filesystem or database, with no filtering, hands the model far more than the task needs. Least exposure is a server property, and many sloppy setups skip it.
- No access control. If a server serves the same data to everyone who connects, then "sharing it with the team" means everyone sees everything, including the things only some people should. Access control has to be enforced on the server, not just hidden in a UI.
- Untrusted servers. Connecting to an unverified community server is connecting unknown code to your data and, in the worst case, to actions a model can take. Treat it like installing any third-party integration.
- Over-broad tool permissions. Tools let a model take actions. If those actions are not least-privilege, a confused or manipulated model can do more damage than read a file.
- Prompt injection through results. Content a server returns can contain instructions aimed at the model. If your setup blindly trusts tool output as gospel, that is an attack surface worth knowing about.
None of these are flaws in MCP. They are properties of how a server is built and operated. Which is good news: they are all things you can check.
Local vs remote, on security
Teams often assume local is automatically safer. It is not that simple.
A local server keeps data on one machine and never crosses the network, which is genuinely useful, but it is only as safe as that machine, and it gives you no central control across a team. A remote server is reachable over the network, so it must authenticate every connection and encrypt traffic, but a well-run hosted endpoint can be far more controlled and auditable than a dozen ad hoc local setups. We cover the full tradeoff in local vs remote MCP servers.
The security question is not local versus remote. It is authentication, encryption, and access control, present or absent.
A short checklist before you connect
Whatever the server, confirm these:
- It authenticates connections. No anonymous access to anything sensitive.
- It encrypts traffic in transit for remote endpoints.
- It scopes access per user, server-side. Sharing a source should never mean everyone sees every part of it.
- Tool permissions are least-privilege. The model can do what the task needs and no more.
- The vendor is known for anything sensitive. Prefer a server someone stands behind over an unverified one.
How BaseThread approaches this
Since BaseThread is a shared context server a whole team connects to, access control is the center of the design, not a bolt-on. Context is curated and scoped by role and membership, so reading the company layer never means a person can read every project. That gate is enforced server-side, on every read and every write, not just hidden in the interface.
The curated approach helps on the exposure front too. Because integrations with tools like Notion and HubSpot distill the signal rather than dumping every record into the model, the server is not handing over a raw firehose in the first place. The local Mac bridge keeps desktop traffic on the machine, and the remote endpoint at mcp.basethread.ai authenticates and encrypts every connection, so the same access rules hold whichever surface a teammate uses. BaseThread is in closed beta, and security posture is reviewed as part of that. See how it works for the full flow.
The mental model
Do not ask "is MCP secure." Ask "does this server authenticate me, encrypt my traffic, and only show me what I am allowed to see." Those three answers are your security posture.
TL;DR
MCP is a protocol, so its security depends on the servers you connect to, not the standard itself. The protocol supports authentication, encryption, and scoped access; the risks come from servers that over-expose data, skip access control, run untrusted code, or grant over-broad tool permissions. Local versus remote is not the deciding factor; authentication, encryption, and server-side access control are. BaseThread treats access control as central, scoping curated context by role and membership and enforcing it server-side on every read and write.
Curated context, scoped by role, enforced server-side on every read and write.
Related reading
What is MCP (Model Context Protocol)? A 2026 guide
MCP is an open standard that lets AI tools read outside context and call tools through one protocol. Here is what it is, how it works, and why it matters.
Local vs remote MCP servers: which your team needs
Local MCP servers run on your machine, remote ones are hosted at a URL. Here is how they differ, which tools each suits, and why teams usually want both.
MCP for teams: one context layer across your AI tools
MCP for teams turns scattered docs and decisions into one context layer every AI tool reads, so Claude Code, Cursor, and ChatGPT share the same source.
What is a remote MCP server (and when teams need one)?
A remote MCP server is a hosted endpoint any AI tool can connect to over the network. Here is how it differs from a local server and when a team should use it.
Frequently asked questions
Is MCP secure?
MCP is a protocol, not a single product, so security depends on how a given server is built, hosted, and authenticated. The protocol itself supports authenticated connections and scoped access. The real risk surface is the servers you connect to: what data they expose, who they let in, and whether they enforce access control. Vet each server the way you would any integration that touches your data.
What are the main MCP security risks?
The big ones: a server that exposes more than it should, a server with no access control so every connected user sees everything, untrusted or unverified third-party servers, and over-broad tool permissions that let a model take actions it should not. Prompt injection through tool results is also a live concern. Each is a property of the server and setup, not of MCP itself.
Is a remote MCP server less secure than a local one?
Not inherently. A local server keeps data on one machine but is only as safe as that machine. A remote server is reachable over the network, so it must authenticate every connection and scope access, but a well-run hosted endpoint can be more controlled than scattered local setups. What matters is authentication, encryption in transit, and access control, not local versus remote alone.
How do I check if an MCP server is safe to connect?
Confirm it authenticates connections, encrypts traffic, and scopes what each user can read and do. Prefer servers from a known vendor over unverified community ones for anything touching sensitive data. Check that access control is enforced server-side, not just hidden in the UI, and that tool permissions are least-privilege.