Is an official MCP server safer than a community one?

Provenance is one of several signals, not the answer. A server published by the vendor whose system it reaches is a party you already have a relationship with, which is worth something. It tells you nothing about what the component asks for, whether it holds credentials, or whether it updates without review, and those are the questions that decide the outcome.

Can I sandbox an MCP server instead of reviewing it?

Containment helps and it does not remove the question, because the useful components are useful precisely by reaching something. A sandbox bounds the network and the filesystem. It does not bound the credential you handed the component so it could do its job, and that credential is generally the thing worth worrying about.

What should be written down when one is installed?

Publisher, version, what it declared it needs, whether it holds or can read a credential, and who approved it. Five lines, at the one moment when all five are visible. Reconstructing them later means reading the configuration and guessing at the rest.

Is it safe to install an MCP server?

It depends on what it asks for, who publishes it, and what happens when it updates, and those are three separate questions with three separate answers. An MCP server, a skill or a plugin runs inside your agent, which means it sits alongside your agent's context and can generally reach whatever credentials the agent holds. That is a supply-chain decision rather than an installation, and the moment to make it is before it is installed, because after that the permissions it asked for are no longer in front of anybody.

What it can reach is not what its description says

A component's description is written by its publisher and says what it is for. The interesting question is what it is able to do, which is a different list and is usually longer. The gap between the two is where a pre-install review earns its time.

Two specifics matter more than the rest. Whether the component handles credentials directly, because a component holding a write credential is a second thing that can write to your systems whether or not the agent asked it to. And whether it can make outbound requests, because a component that calls out on your behalf is doing so under your name.

Neither is visible from behavior. A component that never misuses a permission and a component that does not hold it look identical in every run you observe, right up until the run where they differ.

The clean-then-poisoned update

The pattern worth understanding is that a component is reviewed once, at install, and updated many times afterwards without review. Following the latest version means the code running inside your agent changes without anybody deciding it should.

That is why version pinning is a security control, not an engineering preference, and why publisher provenance matters more than a one-off inspection of the code. You are not deciding whether this version is safe. You are deciding whose future decisions you will accept automatically.

It is also why credential handling and approval behavior are worth reading together. A component that holds your credentials and can also update itself without your approval has both halves of the problem, and a shipped RedHub gate treats that combination as dispositive rather than as two separate findings.

This is a trust decision, not a code scan

Reading the source is useful and is not the answer, for a plain reason: you would have to read it again on every update, and you will not. The checks that survive contact with a real week are the ones that are cheap and repeatable. Who publishes it. Which version is running, pinned rather than tracking. What it declared it needs against what it is able to reach. Whether it holds a credential. Whether it can update itself.

Keeping the list of installed components current is the part that decays first, and it decays quietly, because installing a component is the fastest way to widen what an agent can reach and it does not look like a change to the agent.

Common questions

Is an official MCP server safer than a community one?: Provenance is one of several signals, not the answer. A server published by the vendor whose system it reaches is a party you already have a relationship with, which is worth something. It tells you nothing about what the component asks for, whether it holds credentials, or whether it updates without review, and those are the questions that decide the outcome.
Can I sandbox an MCP server instead of reviewing it?: Containment helps and it does not remove the question, because the useful components are useful precisely by reaching something. A sandbox bounds the network and the filesystem. It does not bound the credential you handed the component so it could do its job, and that credential is generally the thing worth worrying about.
What should be written down when one is installed?: Publisher, version, what it declared it needs, whether it holds or can read a credential, and who approved it. Five lines, at the one moment when all five are visible. Reconstructing them later means reading the configuration and guessing at the rest.

Find out where you stand

The assessment on this site asks up to 24 questions about what your agent can reach and what happens when it is wrong, and returns a score, a verdict and, where a control is short, the one thing to fix first. It takes about ten minutes, and questions your agent has no surface for are dropped rather than scored against you.

It is a self-assessment of design, permissions and recovery, not a penetration test, not an audit of a running system, and not a certification.

Run the assessment