Every MCP server on HostedMCP has a short note at the bottom: listed servers run with the permissions you give them, so review the source before installing. We put it there because the most common MCP security problem isn't a clever exploit. It's someone pasting a database URL with full write access into a server they found five minutes earlier.
This guide covers both kinds of risk. The ordinary ones, like over-broad credentials, are where most incidents start. The protocol-level ones, like token passthrough and confused deputies, matter if you build or host servers. We've grounded each in the official MCP security best practices for the 2026-07-28 revision, plus what we see in our own catalog.
Önemli çıkarımlar
- Most MCP incidents start with ordinary mistakes: over-broad credentials and servers nobody checked.
- The model reads untrusted text, so any tool it holds can be steered by a web page, issue or email.
- Local servers run with your permissions; remote servers must follow OAuth 2.1 and never pass tokens through.
- Least access, approval for anything that writes, pinned versions and fewer servers per agent prevent most problems.
| Risk | Who it affects | Main defense |
|---|---|---|
| Prompt injection through content | Anyone whose agent reads web pages, issues or email | Approval before writes; no irreversible tools next to untrusted input |
| A local server runs as you | Anyone installing stdio servers | Trusted publishers, scoped secrets, pinned versions |
| OAuth mistakes in remote servers | Server builders and hosts | Follow the MCP authorization spec; no token passthrough |
| Too much in one place | Agents with many servers | Give each agent only the servers its task needs |
Why MCP changes the security picture
A traditional integration is code a developer wrote, calling an API in ways they decided in advance. With MCP, a model decides at runtime which tool to call and with which arguments, based on everything in its context. Some of that context is text nobody on your team wrote: a web page the model fetched, a GitHub issue, an email, the result of another tool.
That's the whole problem in one sentence. The model is a decision-maker that reads untrusted input. Most MCP risks are some version of "untrusted text steered a tool call" or "a tool had more access than it needed when that happened".
Risk 1: prompt injection through content
Say you've connected a GitHub server with permission to comment and close issues, and you ask your agent to triage new issues. One issue contains, buried in a long log, a line that tells the assistant to close every open issue as a duplicate. A model that follows instructions found in data can do exactly that.
Nothing in the protocol prevents this, because the model's reasoning isn't something a protocol can validate. What helps is layering. Good hosts ask for approval before tools that change data and show you the arguments. Good servers mark tools that write or delete, so hosts can treat them differently. And you can keep the agent's access narrow for the job: triage needs to read and label, not close and delete.
Dikkat edin
An agent that reads untrusted content should not hold tools that can do irreversible things without a person confirming. This is the rule we follow ourselves.
Risk 2: a local server runs as you
A local server is a program on your computer, started by your AI app, with your user's permissions. It can read the files you can read and reach the network you can reach. The MCP security best practices treat this as its own risk: a malicious or compromised local server can run arbitrary commands with the client's privileges, which is why one-click install flows must get explicit consent and show the exact command.
Local servers are a large share of our catalog, especially among developer tools, and many of them need secrets. On 11 November 2026, 11,660 servers declared environment variables, and 12,757 of those variables were marked as secrets: API keys, tokens and passwords that sit in your client's config file.
How the servers in our catalog say they authenticate, from the READMEs our enrichment model read (measured November 14, 2026):
| Kimlik doğrulama | Sunucular | Paylaş |
|---|---|---|
| Yok | 18.603 | 46% |
| API anahtarı veya OAuth | 10.519 | 26% |
| API anahtarı veya token | 9.247 | 23% |
| OAuth | 2.389 | 6% |
What to do about it is mostly common sense, applied consistently.
Prefer servers from the vendor of the product, or from a publisher whose other work you can see. Our server pages show the publisher and mark official servers.
Check that the source is public and alive. A package with no linked repository, or a repository last touched a year ago, is a bigger bet. Each HostedMCP page shows the last commit and release date.
Read the tool list before installing. If a "weather" server has a tool that runs shell commands, stop.
Scope the secret. Give a database server a read-only user. Give a GitHub server a fine-grained token for one repository. Point a filesystem server at one project folder, never your home directory.
İpucu
Pin versions for anything important.
npx -y some-server@latestruns whatever was published most recently, every time it starts;npx -y some-server@1.4.2runs the version you checked.
The spec names one more local risk worth knowing if you run proxies: in a setup where a web page can reach a local MCP proxy, a cross-site scripting bug in that page can escalate into command execution through the proxy's stdio server. If you run an MCP gateway or proxy on localhost, treat it like any other local service with an attack surface.
Risk 3: remote servers and OAuth
Remote servers don't touch your machine, but they hold tokens for many users and talk to other services on their behalf, which brings a different set of problems. The MCP security best practices list several by name.
| Attack | What goes wrong | Defense |
|---|---|---|
| Token passthrough | A server accepts a token not issued to it, or forwards the user's token upstream | Accept only tokens issued for this server; never forward them |
| Confused deputy | A proxy with a static client ID grants a malicious client a code without real consent | Per-client consent in the proxy |
| Server-side request forgery | OAuth discovery points the client at internal URLs such as cloud metadata | Clients validate discovery URLs |
| Mix-up attack | A malicious authorization server sends a code to an honest server's token endpoint | iss validation (RFC 9207), added in 2026-07-28 |
| Authorization URL abuse | A server returns a javascript: URL or shell metacharacters |
Clients validate the URL before opening it |
| Localhost redirect impersonation | Another local process catches a code sent to localhost |
Careful redirect handling in desktop clients |
| Over-broad scopes | A leaked token can do far more than the task needed | Ask for the narrowest scope |
The rule behind the first row is direct: MCP servers must not accept any tokens that were not explicitly issued for the MCP server.
The 2026-07-28 revision also deprecated OAuth Dynamic Client Registration in favor of Client ID Metadata Documents, and the stateless design replaced protocol sessions, so the older session-hijacking concerns are now framed as hijacking of the state handles a server issues. If your server keeps state, make those handles unguessable and bind them to the user.
Risk 4: too much in one place
The quietest risk is concentration. One agent with a GitHub server, a Slack server, a database server and a browser server can read code, read messages, query customers and visit any website, all in one context. A single injected instruction then has a lot to work with, including ways to send data out.
Splitting helps. Give an agent the servers for the task at hand rather than everything you have. Keep servers that read sensitive data away from servers that can post to the outside world, or at least make the outbound ones require approval.
A checklist for people installing servers
Before you add a server, a few minutes of checking avoids most problems.
- Know who publishes it. Vendor-official, or a maintainer you can look up.
- Confirm the code is public and maintained recently.
- Read every tool's name and description. Anything that doesn't fit the server's purpose is a red flag.
- Give it the least access: read-only users, single-repository tokens, one folder.
- Keep write and delete actions behind your approval, and don't approve permanently until you trust it.
- Pin versions for servers you depend on, and update deliberately.
- Remove servers you no longer use. Every installed server is attack surface and context window.
Every server page on HostedMCP shows the publisher, the last commit, the environment variables it needs and its full tool list, which covers the first four checks in a minute.
A checklist for people building servers
If you maintain a server, you carry more of the responsibility.
- Expose the smallest set of tools that does the job, named after tasks.
- Mark tools that write or delete with the destructive hint so hosts can ask first.
- Validate every argument as if it came from an attacker, because it might.
- Log to stderr, never to stdout, and never log secrets.
- For remote servers, follow the MCP authorization spec: OAuth 2.1, only accept tokens issued for your server, no token passthrough, narrow scopes.
- Treat state handles as secrets: random, bound to the user, short-lived.
- Document every permission and environment variable your server needs, with placeholder values only.
Our guide to building an MCP server shows the basics with the current SDKs, and MCP vs API explains why returning less data is also a security win.
Running MCP in a team
Once more than a few people use MCP at work, ad-hoc installs stop scaling. A few habits make it manageable.
| Habit | Why it helps |
|---|---|
| An approved, pinned server list in the repository | Everyone runs the same reviewed versions |
| Separate identities for agents | Audit logs show which actions an agent took; revoking it locks nobody out |
| Hosted servers for SaaS products | No API keys on laptops; access follows the product's admin controls |
| Logged tool calls | After a surprise, the log shows which content steered the model |
| Updates reviewed like dependencies | New code with your permissions gets read before it runs |
Keep an approved list. Pick the servers your team may use, pin their versions, and share the config through the repository rather than each person's home directory. Claude Code's project-scoped .mcp.json and VS Code's workspace .vscode/mcp.json exist for exactly this, and our client guides show where each tool keeps project config.
Give agents their own identities. A service account or bot token for the agent, separate from any person's credentials, makes it obvious in audit logs which actions an agent took and lets you revoke it without locking anyone out.
Prefer hosted servers for SaaS. When a vendor runs the MCP server for its own product, you skip distributing API keys to laptops, and access is governed by the same OAuth grants and admin controls as the rest of the product. Our remote server list is a quick way to see which vendors offer one.
Log tool calls. Most hosts can record which tools ran with which arguments. Keep those logs where you keep other audit logs, and look at them after anything surprising happens; they usually show exactly which piece of content steered the model.
Review updates like dependencies. A server update is new code running with your permissions. Read the changelog for servers that can write to production systems, the same way you would for a library.
What HostedMCP does and doesn't check
We're a directory, not a security auditor, and it's worth being clear about the line. For every listing we read the repository, packages and README, record the publisher, last commit, releases and declared environment variables, and show the full tool list. Listings from bulk publishers are flagged, and forks and mirrors are merged into the original.
We don't run the servers or audit their code. A listing on HostedMCP means we found it and described it accurately, not that it's safe for your environment. That judgment stays with you, and the checklists above are how we'd make it.
If you're new to all of this, what MCP is and what an MCP server is are good places to start, and our remote server list is the easiest way to try servers that never touch your machine.