Notifications
Clear all
Topic starter
02/08/2026 12:05 pm
TL;DR: MCP turns LLMs from chat-only systems into tool-using agents that can read files, create tickets, and interact with development workflows, but it also expands the attack surface through prompt injection, path traversal, and supply-chain style abuse, according to Semgrep. The governance problem is no longer whether AI can act, but how identity, privilege, and context boundaries are enforced when it does.
NHIMG editorial — based on content published by Semgrep: MCP: Model, Context... Propaganda? What security teams need to know about the latest hyped up AI tech
By the numbers:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%).
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
Questions worth separating out
Q: What breaks when an AI agent is allowed to call tools without strict scope controls?
A: The main failure is privilege expansion.
Q: Why do AI agents create accountability problems for IAM and NHI teams?
A: AI agents create accountability problems because traditional IAM proves who authenticated, while agent governance must prove what the actor did with that access.
Q: How can organisations tell whether an MCP integration is safe to keep in production?
A: A safe MCP integration has a named owner, documented scopes, observable activity, and a working offboarding path.
Practitioner guidance
- Implement allow-listing for MCP servers Approve only vetted internal or trusted external MCP servers, and require explicit review before any new tool is added to an AI workflow.
- Isolate every MCP tool in low-privilege execution Run MCP-backed services in containers or serverless functions with zero default permissions and narrow filesystem or API access.
- Pin tool context and validate instructions before execution Use context protection controls that lock tool descriptions after first trust and reject unexpected changes in server metadata.
What's in the full article
Semgrep's full post covers the operational detail this analysis intentionally leaves for the source:
- Implementation detail for allow-listing MCP servers and deciding which internal tools qualify for trust.
- Examples of running MCP services in isolated environments with low or zero default permissions.
- Practical context-protection ideas for pinning tool descriptions and resisting prompt injection.
- Semgrep's own use case for wiring MCP into developer security workflows before code is saved.
👉 Read Semgrep's analysis of MCP security risks for AI agents →
MCP and AI agent tool access: are your controls keeping up?
Explore further
02/08/2026 1:10 pm
MCP creates a new identity and privilege boundary, not just a new integration pattern. Once an LLM can choose and call tools, the security question becomes who or what is authorised to act, under which context, and with which constraints. That moves MCP into the same governance territory as service accounts, delegated access, and privileged automation. The practical conclusion is that AI tool access must be modelled as a controlled identity surface, not a convenience feature.
A question worth separating out:
Q: What is the difference between sandboxing an MCP server and trusting the model to behave safely?
A: Sandboxing limits what the server can reach if it is compromised. Trusting the model assumes the LLM will always interpret instructions correctly and stay within intent, which is not a control. The safer pattern is to combine isolation, least privilege, and explicit validation so the model never becomes the last line of defence.
👉 Read our full editorial: MCP changes how AI agents reach tools, data, and risk
