By Sapumal Herath · Owner & Blogger, AI Buzz · Last updated: February 6, 2026 · Difficulty: Beginner
MCP (Model Context Protocol) is often described as the “USB‑C for AI tools.”
That’s a useful mental model—because MCP makes it easier for AI apps to plug into connectors (Git, filesystems, ticketing, databases) instead of rebuilding integrations from scratch.
But there’s a security catch: once an AI system can call tools, risk shifts from “wrong answer” to wrong action. And MCP expands your attack surface by adding more servers, more connectors, and more trust boundaries.
This guide explains MCP security in plain English: what can go wrong, what controls matter most, and a practical hardening checklist you can copy/paste.
Note: This is a defensive, educational guide. It does not provide exploit instructions. If you’re deploying MCP servers in production, involve security/compliance and treat it like any other privileged integration.
🎯 What MCP changes (plain English)
MCP standardizes how AI apps and tool servers communicate (using JSON‑RPC). MCP servers can expose:
- Tools: actions the AI can request (search repo, read file, create issue, etc.)
- Resources: data objects the AI can read
- Prompts: reusable prompt templates (depending on server features)
In practice, MCP increases capability. The security question becomes:
- Which servers are we connecting to?
- What tools do they expose?
- What permissions do those tools run with?
- What happens if untrusted content manipulates tool use?
⚡ The 5 MCP security failure patterns teams hit first
1) 🧠 Prompt injection becomes “tool injection”
If the assistant reads untrusted content (webpages, PDFs, tickets), hidden instructions can steer the agent into unsafe tool calls—especially when permissions are broad.
Practical fix: treat external content as untrusted, keep tools read-only by default, and require approvals for any write/irreversible action.
2) 🪪 Weak trust in “capabilities” (what a server claims vs what it should be allowed to do)
One MCP risk highlighted by recent research is that servers can claim capabilities without a strong attestation mechanism—making “capability trust” a hard problem if you assume server claims are always honest.
Practical fix: treat MCP server capabilities as requests, not truth. Enforce your own allowlists and policy gates in the client/host environment.
3) 🔄 Multi-server trust propagation (chain risk)
Agents often use multiple MCP servers together (Git + filesystem + web + tickets). That can create “unsafe combinations,” where each piece looks safe alone, but together enables high-impact actions.
Practical fix: model “tool chains” as workflows and apply system-level guardrails: approvals, budgets, circuit breakers, and auditing across all servers.
4) 🧾 Tool description ≠ tool behavior (misleading or inconsistent tool descriptions)
MCP tools are often exposed through natural-language descriptions. If the description doesn’t accurately match what the tool actually does, agents can make unsafe decisions based on false assumptions.
Practical fix: adopt a “tool transparency” review: audit tool descriptions against actual behavior, and block tools that can do more than they claim.
5) 🔐 Connector vulnerabilities (classic AppSec still matters)
MCP servers are still software. They can have security bugs (path validation, argument injection, unsafe file handling). In early 2026, public reporting highlighted vulnerabilities in a Git MCP server that were patched—reinforcing that connectors can be exploited like any other service.
Practical fix: patch management + least privilege + isolation + monitoring. Treat MCP servers like privileged infrastructure.
🚩 Real-world signal: Git MCP server vulnerabilities (what this teaches)
Without going into exploitation detail, here’s the practical lesson from the public Git MCP server vulnerability disclosures:
- Some issues were related to path validation and restrictions not being enforced consistently.
- Some issues were related to unsafe argument handling passed into underlying commands.
- Researchers noted that risks can become more severe when multiple MCP servers are chained (for example, Git + filesystem style integrations).
Takeaway: if your MCP server can touch files, repos, or production resources, it needs strict scoping, patching discipline, and containment switches.
✅ MCP Hardening Checklist (copy/paste)
Use this checklist before you connect MCP servers to production tools and data.
🔐 A) Least privilege (permissions first, features second)
- Default read-only tools in pilots (search, list, fetch, summarize).
- Scope access tightly (specific repo/folder/project/queue; avoid broad tokens).
- Separate environments: dev/staging/prod MCP servers and credentials.
- Minimize data exposure: don’t give RAG or tools access to “everything” by default.
🧑⚖️ B) Approval gates for high-impact actions
- Draft-only by default for outbound messages, tickets, commits, and updates.
- Human approval required for send/publish/delete/merge/payment/permission changes.
- Two-person approval for irreversible production changes (where possible).
🧠 C) Prompt injection defenses (especially indirect injection)
- External content is untrusted (web, PDFs, inbound tickets, emails).
- Separate instructions from data (don’t let documents “write your rules”).
- Structured tool calls (schemas) instead of free-form “do anything” actions.
- Block tool escalation: no requesting broader permissions mid-run without an admin workflow.
🧾 D) Tool transparency checks (description vs behavior)
- Review tool descriptions for accuracy and completeness.
- Audit tools that have side effects (write, delete, payment, network access).
- Remove or quarantine tools whose behavior is broader than documented.
📈 E) Observability + audit logs (make incidents explainable)
- Log tool calls: server name, tool name, parameters, timestamps, user identity.
- Log retrieval sources (for RAG) so you can trace “why it said that.”
- Log approvals for write actions (who approved, what changed).
- Log safely: redact sensitive fields; set retention limits; restrict access.
🧯 F) Containment switches (assume something will go wrong)
- Disable tools quickly (global kill switch for connectors).
- Switch to draft-only for any customer-facing or external output.
- Throttle usage (step limits, token budgets, tool-call quotas).
- Preserve evidence (prompts, outputs, retrieved content, tool calls).
🧪 Mini-labs (no-code tests you can do this week)
Mini-lab 1: Tool permission mapping (Read / Write / Irreversible)
- List every MCP tool available to your agent.
- Label each tool as Read, Write, or Irreversible.
- Set policy: Read tools can run; Write needs approval; Irreversible requires extra controls (or disable).
Mini-lab 2: “Tricky content” injection resilience
- Collect 10 realistic docs the agent might read (tickets, PDFs, wiki pages).
- Test whether the agent ever tries to change goals or call unexpected tools after reading them.
- Add safeguards: instruction/data separation, allowlists, approval gates, and limits.
Mini-lab 3: “What changed?” drill (incident readiness)
- Pick a recent deployment window (last 30 days).
- Answer in 5 minutes: what changed (server versions, tool list, permissions, prompts, RAG sources)?
- If you can’t, you need stronger versioning + audit logs.
🔗 Keep exploring on AI Buzz
📚 Further reading (primary + high-quality references)
- MCP Specification (Base Protocol + Lifecycle + Auth notes)
- MCP Specification (Earlier revision)
- “Breaking the Protocol”: Security analysis of MCP (Jan 2026)
- Tool description vs code mismatch study in MCP servers (Feb 2026)
- The Register: Git MCP server vulnerabilities & patching (Jan 2026)
- NVD: CVE-2025-68143 (MCP Git server)
- NVD: CVE-2025-68144 (MCP Git server)
🏁 Conclusion
MCP is a big step toward reusable AI tool integrations—but security is not automatic.
If you remember one rule: connectors are privileged infrastructure. Start read-only, scope access tightly, require approvals for high-impact actions, log tool calls, test against tricky content, and keep containment switches ready.
Leave a Reply