If you have built anything with LLMs and external tools, you have felt the pain the Model Context Protocol was designed to solve: every model, every framework, and every data source wired together with bespoke glue, none of it reusable. MCP is the standard that replaces the glue. This primer covers what it is, how it works, and — because standardizing integrations also standardizes an attack surface — what it means for security.
The definition
MCP (Model Context Protocol) is an open standard, introduced by Anthropic in late 2024 and adopted broadly across the industry since, for connecting AI applications to external tools and data sources. The common analogy is a USB-C port for AI: instead of a custom connector for every combination of model and system, you implement the protocol once and any compliant client can talk to any compliant server. It has become one of the fastest-adopted standards in the AI ecosystem because it turns an N-times-M integration problem into N-plus-M.
How it works
MCP uses a client-server architecture with three roles:
- Host — the AI application the user interacts with (an assistant, an IDE, an agent framework).
- Client — the connector inside the host that maintains a connection to a single server.
- Server — a lightweight program that exposes a specific capability: access to a database, a filesystem, a SaaS API, a code repository.
Communication runs over JSON-RPC, and servers expose three main primitives: tools (functions the model can invoke to take actions), resources (data the model can read for context), and prompts (reusable templates). Transports include a local stdio option for servers running on the same machine and an HTTP-based option for remote servers. The practical upshot: a developer writes an MCP server for their internal system once, and any MCP-capable assistant can use it — no per-model integration work.
Why security teams need to care
Standardizing how models reach tools and data also standardizes a set of risks. MCP does not create these threats, but it makes them portable and common, which means they deserve a deliberate posture.
Tool poisoning. A model reads tool descriptions and schemas as context to decide what to call. A malicious or compromised server can embed instructions in those descriptions — hidden text the user never sees in the UI — to manipulate the model. This is prompt injection delivered through the tool layer, and it is one of the most discussed MCP-specific risks.
The confused deputy, again. An MCP server often holds real credentials for the system it fronts. If a model is tricked — through a poisoned document, a poisoned tool description, or a malicious resource — into calling that server's tools maliciously, the server executes with its legitimate privileges. The API calls are authorized; the intent is not.
Over-permissioned servers. A server wired with a broad token, or exposing more tools than a task needs, hands any successful manipulation a large blast radius. Least privilege applies to servers exactly as it applies to any other credentialed component.
Rug pulls and unpinned definitions. A server benign at approval time can change its tool definitions afterward. If your host trusts a server's schema without re-verifying it, an update can introduce malicious behavior after you have granted trust.
Lookalike and untrusted servers. As with any registry-driven ecosystem, typosquatted or impersonating servers, and servers from unvetted sources, are a supply-chain risk. A server is software you are running and trusting; treat it that way.
Using MCP safely
- Vet servers like dependencies. Prefer servers from sources you trust, pin their versions, and review what they expose before connecting.
- Scope server credentials tightly. Give each server the narrowest permissions its job requires. A read-only integration should hold a read-only token.
- Prefer least-privilege, read-oriented servers for anything sensitive, and gate consequential actions behind human approval in the host.
- Isolate and sandbox local servers, and restrict network egress for servers that do not need it.
- Treat tool descriptions and resources as untrusted input that can carry injection, and monitor what your servers are actually being asked to do.
How Safeguard helps
Safeguard engages with MCP from both sides. As a consumer-facing capability, Safeguard runs its own MCP server — a deliberately scoped, read-oriented integration that lets the AI assistants your engineers already use query security findings, dependency risk, SBOM data, and remediation plans directly, without handing the model broad access to your environment. It is a working example of the least-privilege pattern this post argues for: expose the context, not the keys.
On the defensive side, Safeguard treats the servers and tool packages in your own agent infrastructure as part of the software supply chain. Software composition analysis inventories the MCP servers and tool libraries your systems depend on and reconciles them against vulnerability and reputation data, so a typosquatted or compromised server surfaces as a finding. The Griffin AI detection engine inspects the integration code where a tool call becomes a real action for the missing-authorization and injection-sink patterns that give a poisoned server its reach, and auto-fix remediation proposes the corrected, least-privilege wiring. See how the platform compares to point tools in the comparisons.
MCP is genuinely good infrastructure — it is why AI integrations stopped being bespoke. Adopt it, and apply the same supply-chain hygiene to servers that you already apply to packages. Create a free account or read the documentation to get started.