Writing

MCP Security Risks You Should Understand

·2 min read

MCP servers sit between agents and real systems.

That makes them powerful. It also makes them sensitive.

If an MCP server can read private data, create tickets, update records, trigger workflows, or move money, then every tool call deserves serious security design.

The main rule:

Treat MCP as production integration infrastructure, not demo glue.

Risk 1: Prompt Injection

Prompt injection happens when malicious instructions are hidden inside data the model reads.

Examples:

  • An issue title
  • A support ticket
  • A web page
  • A document
  • An email body

The dangerous part is that the content may look like normal data, but it tries to influence the agent's behaviour.

For MCP, the risk is higher when the agent can read untrusted content and then call tools with side effects.

Mitigation:

  • Treat external content as untrusted.
  • Separate instructions from data.
  • Require user confirmation for destructive actions.
  • Keep tool permissions narrow.

Risk 2: Tool Poisoning

Tool poisoning happens when a server exposes a benign tool description and later changes it to include hidden or harmful behaviour.

Because tool descriptions are part of the model's context, a poisoned description can influence the model's decisions.

Mitigation:

  • Pin tool definitions when possible.
  • Review unexpected tool-list changes.
  • Use trusted servers.
  • Monitor tool descriptions in production.

Risk 3: Over-Privileged Tokens

Agents should not run with broad, permanent access.

If one token can do everything, then one bad tool call can do too much damage.

Mitigation:

Recommended by LinkedIn

  • Use least-privilege scopes.
  • Bind permissions to the user and action.
  • Prefer short-lived access tokens.
  • Re-check authorisation on every tool call.

Risk 4: Cross-Server Token Replay

A token issued for one MCP server should not work against another server.

For protected HTTP MCP servers, use OAuth-based authorisation with Resource Indicators so access tokens are bound to the intended MCP server URI.

Mitigation:

  • Validate the token audience.
  • Reject tokens meant for another server.
  • Scope tokens to the specific resource server.

Risk 5: Weak Audit Trails

When an agent calls a tool, you need to know what happened.

A useful audit log should answer:

  • Which user was the agent acting for?
  • Which tool was called?
  • What arguments were used?
  • What result came back?
  • Was the action approved?
  • How long did it take?

Without that trail, incidents become hard to investigate.

A Compact Security Baseline


For any serious MCP server:

  • Authenticate every request.
  • Authorise every tool call.
  • Validate every input.
  • Sanitise every output.
  • Encrypt HTTP traffic.
  • Log every action.
  • Require confirmation for destructive operations.

The Takeaway

MCP security is not only about protecting the server.

It is about protecting the user, the downstream system, and the agent's decision loop.

Good MCP servers assume mistakes will happen and limit the blast radius.

Full knowledge base: https://sagart-cactus.github.io/learn-mcp/

Originally published on LinkedIn.