Notifications
Clear all
Topic starter
15/08/2026 6:10 pm
TL;DR: MCP security weaknesses in Anthropic and Microsoft reference implementations show that the real risk sits in the execution layer, where prompt injection can turn trusted agent actions into RCE, SSRF, and credential theft, according to AppSOC. The core problem is that existing IAM assumptions still treat agent actions as bounded requests, even though tool access can expand into filesystem, cloud, and secret exposure.
NHIMG editorial — based on content published by AppSOC: The MCP Security Crisis: Why Your AI Agents Are an Open Door
By the numbers:
- A scan of 7,000+ MCP servers found that 36.7% shared this exact flaw.
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
Questions worth separating out
Q: How should teams govern AI agents that use MCP?
A: Treat each connected agent as a non-human identity with an owner, a scope, and a review cycle.
Q: Why do MCP-based agents create more risk than ordinary API integrations?
A: Because the agent is choosing actions, chaining tools, and preserving context across steps.
Q: What do security teams get wrong about AI access risk?
A: Many teams focus on the model while ignoring the identity path that reaches it.
Practitioner guidance
- Inventory every MCP server and connector Build a continuous discovery process for all MCP servers, agent processes, and third-party connectors so shadow deployments do not bypass governance.
- Scope every tool to a narrow trust boundary Write authorisation rules for each MCP tool, including allowed operations, allowed destinations, and allowed environments.
- Separate agent identity from human credentials Use delegated, task-scoped credentials for agents rather than sharing human secrets across tool chains.
What's in the full article
AppSOC's full blog post covers the operational detail this post intentionally leaves for the source:
- The article’s step-by-step 7-step defence model for MCP environments, including discovery, authentication, and authorization.
- Specific examples of how adaptive guardrails and AI-DLP fit into an agentic security stack.
- The article’s discussion of observability-based threat detection for MCP sessions and metadata endpoint abuse.
- The open-source risk knowledge base concept for tracking weak MCP implementations and known CVEs.
👉 Read AppSOC's analysis of MCP security risks and AI agent access control →
MCP server security and AI agent access control gaps?
Explore further
15/08/2026 6:18 pm
MCP creates a runtime authorisation problem, not just a model safety problem. Prompt filters only address what the model says. They do not govern what the agent can do once it holds delegated tool access, which is where the real compromise path begins. Practitioners should treat MCP as part of the identity control plane, not as a content safety layer.
A few things that frame the scale:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to The State of MCP Server Security 2025.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: How do security teams know whether MCP server governance is working?
A: They should be able to answer four questions at any time: what servers exist, which are official, what credentials they can use, and what systems they contact. If those answers are unclear, governance is not working. The signal is not just fewer alerts, but clear attribution and scoped access across the fleet.
👉 Read our full editorial: MCP security exposes the weak link in AI agent access control
