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 stays on the public side of that problem. It helps teams find an MCP server, inspect available evidence, see how recently it was checked, and run a lightweight public scan when the profile is missing or stale.
It does not claim to run an organization's private identity, policy, audit, or revocation controls. Those controls still have to exist where the agent operates.
The useful registry question is not "did it pass once?" It is "what was observed, how deep was the check, how old is the evidence, and what do we still need to verify?"