Someone on your team wants to point an AI client at real company data this week. They found an MCP server that does it, the install is one line, and they are waiting on you.
Nearly every well-ranked page on MCP security is written for a security team defending enterprise AI infrastructure. Useful work, wrong reader. This is the version for the person who actually signs off at a ten-to-fifty-person product company. One line of orientation, since what MCP is is covered elsewhere: an MCP server is a program that exposes tools an AI client can discover and call. The rest of this is the risk model and the decision.
Are MCP servers safe?
Some are and some are not, and the protocol is not what decides it. What decides it is which kind of server, holding what credentials, running on whose machine. A stranger's local server and a first-party hosted endpoint behind OAuth are two different products sharing one name, and they fail in completely different ways.
Almost every published risk list collapses those two into one question. That is why "are MCP servers safe" has no usable answer on page one: the honest answer is a split, and a taxonomy of seven risks cannot deliver a split.
The two servers that share one name
| Third-party server you run locally | First-party hosted server behind OAuth | |
|---|---|---|
| What code runs, and where | A package pulled from a public registry, executing on your laptop | The vendor's own service on their infrastructure; nothing installs locally |
| What credentials it holds | Whatever the logged-in user can already reach - shell environment, API keys, SSH keys, browser session | A scoped token for one account, issued by the vendor's authorization server |
| Who can revoke it | The person at that laptop, by editing a config file | An administrator, centrally, by revoking the token or the client |
| Is there an audit trail | None that outlives the process | Per-call, attributable to a specific person |
| What a bad update can do | Change behaviour silently on the next run, if the command resolves to "latest" each time | Change the tool surface server-side, where it is versioned and visible |
| Who to ask before installing | Nobody - it is one config block, with no approval gate | Whoever administers the vendor account |
Read the rows. The hosted column is not "safe" and the local column is not "dangerous." The hosted server hands your data to a third party you now depend on. The local one hands a stranger's code the run of a laptop that is already logged into everything. Those are different bets, and you can only make one of them well if you know which one you are making.
What actually goes wrong: the MCP security risks that matter
The documented risk categories sort cleanly into two families once you have the split.
The server itself is hostile or careless. Running an unvetted server is arbitrary code execution on the machine that runs it - that is not a vulnerability, it is the definition of installing software, and the AI framing tends to hide it. From there: tool descriptions crafted to steer a model toward actions you did not intend, unsanitised tool input reaching a shell, and credentials sitting in a plaintext config file where any other process on the machine can read them. Nearly every documented failure in this space lives in this family, and nearly all of it lives on laptops.
The server is fine and the model is fooled. Prompt injection is the durable one. Content the model reads - a ticket, a webpage, a support message - carries instructions, the model cannot reliably tell data from directive, and it then uses its legitimate tools to do something you would not have approved. Over-broad permissions turn that from an annoyance into exfiltration. Nothing about MCP causes this and nothing about MCP fixes it.
Gartner expects more than 40% of agentic-AI projects to be canceled by 2027. Very little of that will be protocol failure. MCP is now a governed Linux Foundation standard, which settles the "will this format survive" question and settles nothing about what any individual server does with your data.
A decision procedure you can run before Friday
Six checks. None of them requires a security team.
1. Name the profile out loud. Who wrote this server, and whose machine does it run on? If you cannot answer both in one sentence, stop here - every question below depends on the answer.
2. Ask what credentials it will hold, and how it gets them. A token pasted into a plaintext config file is a secret at rest with no rotation story and no owner. A token issued per-person by an authorization server can be revoked by someone other than its holder. This is the single largest difference in blast radius.
3. Check that authentication is delegated, not shared. OAuth 2.1 with PKCE means the host proves who is calling. A shared API key means the server knows a valid key was used and nothing else - including which of your five teammates used it.
4. Grant read before write. A read-only surface that turns out to be over-permissioned costs you a disclosure. A write surface that turns out to be over-permissioned costs you data. Most teams do not need write access in week one and take it because it was offered.
5. Decide who can revoke, and confirm they can do it without the user's cooperation. If revocation means asking a laptop's owner to delete a config block, you do not have revocation.
6. Write down where the audit trail lives. If the answer is "nowhere," that server does not get production data. This is the question that gets asked after an incident, and "we cannot reconstruct it" is a bad afternoon. Once several servers are in play, one place every call passes through is what an MCP gateway produces by construction, which is often the entire reason one gets bought.
Two of these get harder at team scale rather than at install time, and that ceiling is its own subject - what a local server costs once five people run it covers the per-machine install, the config drift, and the missing trail in detail. If you are choosing between vendors rather than evaluating one, the questions to ask about open standards and lock-in are a different four minutes on the same call. And if you want to know what a specific tool's own MCP server actually exposes before you install it, we keep a page per tool. Reviewing several at once has its own cost, separate from the security one - connecting more servers than you query covers what that does to the assistant.
Check this page instead of believing it
You should not take a security posture on description, including ours.
Run npx -y @aioproductoscom/mcp@latest with no PRODUCTOS_TOKEN set. With no token it starts in demo mode against a seeded showcase workspace called Brightline, exposing a read-only subset of the tools - no account, no credentials, nothing to cancel. Ask your host to list the tools, then ask it to change something. The list comes back from the protocol itself rather than from our marketing, and the write does not happen, because those tools are not on the surface a tokenless session gets. That is the claim in step 4 above, testable in about a minute.
For the hosted endpoint, the auth claim is fetchable rather than assertable. https://platform.aioproductos.com/.well-known/oauth-authorization-server and https://platform.aioproductos.com/.well-known/oauth-protected-resource are public discovery documents. They state the supported flows, including PKCE with S256 and Dynamic Client Registration. If a vendor tells you their server uses OAuth and cannot point you at equivalent documents, that is worth a follow-up question.
The honest counter-case
Three things this post does not let you conclude.
OAuth does not solve prompt injection, and neither does MCP. Authentication answers "who is calling." Injection is a question about what a legitimate caller was persuaded to do. A perfectly authenticated, correctly scoped, fully audited tool call can still be the wrong call, made by a model that read a poisoned ticket. Nobody in this market has solved that, us included.
A scoped token still permits everything it permits. "Least privilege" narrows the blast radius; it does not create judgement. If the token can read every customer record, a confused model can read every customer record and put the contents somewhere they should not be. Scope the grant to the job, not to the role.
Sometimes the answer is: do not connect it. Regulated data under an obligation you would have to explain to an auditor. A community server with no identifiable maintainer. Any server asking for write access on day one, before anyone has watched it work. Those are not "proceed carefully" cases. They are no, and treating every integration as a yes-with-mitigations is how the fifth install becomes the incident.
Our own posture is stated the same way. Data residency in the EU or US enforced at ingest, BYOK envelope encryption with a per-org key, roles enforced in the database through row-level security rather than only in the UI, and no AI training on customer data. We track 159 compliance controls across 18 frameworks, and that is readiness, not certification, until an external audit completes - the detail is public. We are not immune to prompt injection and will not claim to be.
Run the six checks on whatever your team wants to install this week, ours included. If you want to run the same evaluation against your own work rather than a seeded workspace, every plan starts on a card-required 14-day runway on your own data - the tiers are flat and listed, and the MCP surface is documented tool by tool before you connect anything.