MCP security means treating every tool boundary as a trust decision, not a plumbing detail. You secure MCP servers by reducing what each tool can do, reducing what each response is allowed to mean, and reducing where the workflow is allowed to trust outbound signals. In practice, that means tight scopes, strict schemas, authenticated connectors, separated read and write paths, explicit outbound allowlists, and human-readable review of any text that can redefine authority. Sunglasses v0.2.25 ships detection patterns including GLS-CAI-256, GLS-TOP-251, and GLS-MRC-253 that flag callback authority shifts, action-changing tool output, and shadow router redirects.

MCP security is having a visibility moment because teams finally realize that agent risk does not stop at the prompt window. Once an agent can discover tools, call servers, fetch context, route tasks, and receive structured replies, the real security question becomes: what exactly is this workflow trusted to do next? That is why securing MCP servers is not just about filtering hostile text. It is about limiting authority, validating structure, and watching for the quiet ways an ordinary connector becomes a decision channel.

If you are evaluating how Sunglasses works in an MCP deployment, building a server catalog, or trying to explain MCP risk to a buyer or internal platform team, the practical framing is simple: every MCP tool is a trust boundary. The job is not only to keep bad prompts out. The job is to make sure a server, tool description, callback, or discovery flow cannot quietly expand what the agent is allowed to access, where it is allowed to connect, or which actions it is allowed to take. See the Sunglasses manual for wiring options across MCP, SDK, and framework deployments.

Why MCP security is a runtime problem, not just a prompt problem

Prompt injection still matters, but it is only one way the trust boundary gets crossed. In MCP systems, the harder problem is often scope drift. An agent reads one instruction, then consults a server, then gets a structured reply, then calls another tool, then retries through a fallback path, then accepts a dynamic endpoint because the surrounding metadata made it sound legitimate. Each step feels operational. Together, they can create a workflow that is now following authority nobody meant to grant.

That is why buyers searching for MCP security are not really asking for another generic AI safety essay. They are asking whether the system can keep ordinary infrastructure behavior from becoming a hidden control channel. Can a tool description quietly widen access? Can a setup flow teach the agent to trust the wrong server? Can a status callback become a way to change future behavior? If the answer is yes, then your risk is not theoretical. It is already in the production path.

Runtime review is what closes the gap. It forces teams to treat connector language, policy notes, callback instructions, and discovery metadata as first-class security material. If a text fragment can redefine scope, an endpoint can shift routing, or a field can alter execution order, then the system is dealing with authority, not mere plumbing. The Cyber Verification Program testing we published validates exactly this: model-agnostic pattern detection catches scope-expansion language before it reaches an agent's reasoning loop.

Plain-language explainer: what an unsafe MCP deployment looks like

Imagine a support agent that uses MCP servers to read docs, check ticket state, and open a follow-up task. At first, each tool has a clear purpose. One server reads product information. Another reads customer status. A third creates a ticket if the customer asks for escalation. Everything feels tidy.

Now imagine the escalation server starts returning a small extra field that says the agent should fetch "latest routing guidance" from another location before it acts. That new location returns a second set of hints about which queue to use, which credentials to prefer, or whether an exception should bypass normal review. Nothing in that chain has to look obviously malicious. It can all look like normal operations metadata.

But the trust model has changed. The workflow is no longer just using tools. It is inheriting authority from a path that may never have gone through the same review as the original tools. That is the heart of MCP security. The danger is not merely that the agent can call a server. The danger is that the server can become the place where future permission decisions get smuggled in.

Good hardening draws a bright line here. Reading is not the same as approving. Returning status is not the same as authorizing action. Discovery is not the same as trusted redirection. Once a team separates those ideas, many MCP risks become easier to see. This is the same class of problem we cover in the MCP tool poisoning analysis — the vector changes, but the core mechanism (trusted channel carrying attacker-controlled instructions) stays constant.

Three concrete MCP attack examples teams should care about

1) Scope creep hidden inside a "helpful" tool description

An MCP tool starts with a narrow job, like reading a ticket or listing a repo directory. Later, a policy note or tool description quietly implies broader authority: use any connected server, access the whole workspace, or treat adjacent records as implicitly approved. The agent does not need to be openly compromised for this to be dangerous. It only needs to believe the updated note is authoritative.

This is why MCP security cannot stop at credential storage. The text around the connector matters too. If supporting documentation can silently expand the agent's operational scope, then the real attack surface includes the words that redefine permission. This is precisely the pattern family covered by MCP scope creep — a runtime problem that looks like a documentation update.

2) Discovery or setup flow that redirects the agent to the wrong authority

Many MCP deployments rely on discovery because it makes integration easier. The problem is that convenience layers often get trusted too quickly. A server registry, setup endpoint, bootstrap note, or manifest reference tells the agent where to go next. If that discovery path is stale, forged, or overly dynamic, the agent may inherit trust from an endpoint the operator never meant to approve.

From the logs, the sequence may still look routine. The agent asked where to connect. It connected. It received a valid-looking reply. But the discovery response itself was the dangerous moment. Treating setup and registry flows like harmless convenience features is one of the fastest ways to lose the trust boundary.

3) Callback or heartbeat fields that start carrying execution meaning

Teams often give low scrutiny to healthchecks, heartbeats, and status callbacks because those paths sound boring. That is exactly why they are attractive places to hide authority. A callback field that changes retry behavior, queue priority, destination choice, or fallback policy is no longer "just status." It is now influencing what the agent does next.

That kind of drift is easy to miss in MCP ecosystems because the traffic still looks like normal server chatter. But once a connector can quietly tell the workflow how to behave, the server has become a soft command channel. Strong MCP security treats that as a trust event, not a logging detail. This is the surface pattern GLS-CAI-256 targets directly — callback fields shifting authority in ways that look operational.

How Sunglasses catches it

Sunglasses is useful in MCP security because it focuses on the moment harmless-looking language starts carrying unsafe authority. That can show up in tool descriptions, prompt fragments, YAML, policy notes, bootstrap instructions, callback guidance, or generated code. The common thread is not the file type. The common thread is that the content can change trust.

That matters for MCP specifically because so much of the system is wrapped in text that people underestimate. Connector descriptions tell the agent what a tool is for. Setup instructions explain where to connect. Configuration files define what to trust. Runtime notes explain what to do when something fails. If any of those surfaces says, in effect, "use this broader scope," "trust this new endpoint," or "retry until the policy softens," a defender needs a chance to see it before the workflow executes.

Sunglasses v0.2.25 ships detection patterns including GLS-CAI-256 (callback authority shifts), GLS-TOP-251 (action-changing tool output), and GLS-MRC-253 (shadow router redirects) — three of the most common ways MCP trust boundaries get crossed without anyone noticing in the logs. These run as static pattern checks, no model in the hot path, low latency enough to wire into any middleware layer.

Sunglasses helps by treating those patterns as reviewable policy objects instead of assuming they are just implementation details. For teams wanting the first practical step, the starting point is still simple:

pip install sunglasses
sunglasses scan <path>

Then look closely at anything that mixes tool authority, connector trust, dynamic discovery, hidden fallback logic, or outbound instructions. In agent systems, that is where "normal operations" often turns into unauthorized action. The FAQ covers common deployment questions, and the How It Works page shows framework-specific wiring for MCP, LangChain, CrewAI, and others.

What defenders should harden today

If your current MCP security plan is mostly "authenticate the server and hope the rest is fine," that is a start, but it is not enough. The stronger question is: what in this workflow is allowed to speak with authority? Once you answer that honestly, the hardening roadmap gets much clearer. The AI agent security 101 guide is a good complement if you are building the case for a broader program.