The Model Context Protocol is useful because it gives agents a standard way to connect with tools and data. The uncomfortable part is that every connection becomes an access relationship. If the server is weak, over-permissioned, poisoned, or poorly monitored, the agent can carry that risk into the workflow.
The Cloud Security Alliance's May 2026 research note, MCP Security Crisis: Systemic Design Flaws in AI Agent Infrastructure, frames the issue bluntly. But the operational lesson is simple: MCP security is not only a protocol debate. It is third-party access management arriving inside AI systems.
Know the server
Track who owns it, what it exposes, how it authenticates, and when it changes.
Know the permission
Separate read, write, admin, and execution paths instead of trusting a broad connector.
Know the exit
Have a revocation path before the first incident forces you to invent one.
Why this is different from classic vendor risk
Traditional vendor risk reviews assume a fairly stable relationship. A vendor has a contract, a security questionnaire, a list of subprocessors, and a procurement owner. MCP does not always enter through that front door. It can show up as a local developer tool, a convenience connector, a marketplace install, a hosted server, or a proof-of-concept that never gets removed.
That makes the old once-a-year vendor review pattern too slow. The right question is not just "Do we trust this vendor?" It is "What can this server do for the agent right now, and what evidence proves that?"
The control set buyers will expect
If you sell software that depends on MCP or connected agents, buyers are going to ask more specific questions. The smart move is to prepare evidence before the diligence request arrives.
- Which MCP servers are approved for production use?
- Which ones are experimental, local-only, or blocked?
- How are servers authenticated and scoped?
- Can a server execute commands, retrieve secrets, modify records, or call other tools?
- What logs show agent-to-server activity?
- How do you revoke access when a server changes, fails review, or is compromised?
The mistake to avoid: treating an MCP server like a library when it behaves more like a live integration with permissions.
What to do now
A practical MCP governance loop does not need to be complicated. Start by separating discovery, approval, runtime monitoring, and response.
- Discover: build a list of MCP servers, tool definitions, hosts, owners, and connected agents.
- Classify: mark what each server can touch: public data, internal records, secrets, execution environments, or customer systems.
- Approve: define which teams can add MCP servers and what review is required before production use.
- Contain: run higher-risk tools with constrained permissions, isolated execution, and clear network boundaries.
- Monitor: log tool calls and alert on new servers, permission expansion, unusual outputs, or unexpected network behavior.
- Revoke: make removal boring. If access cannot be cut quickly, it was not governed.
How CraftedTrust fits
CraftedTrust exists because MCP trust needs both a public and private plane. The public trust plane helps teams discover servers, inspect trust signals, review certifications, and consume advisories. The enterprise control plane is where organizations need policies, identity, audit history, trace analytics, governance dashboards, and administrative workflows.
That split matters. Public evidence helps buyers and builders decide what to consider. Enterprise evidence helps operators prove what is actually allowed and what happened in their environment.
The best MCP story is not "we scanned it once." It is "we know what this server is, what it can do, what changed, and how to stop it."