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.
Editorial analysis by NHI Mgmt Group, based on content published by Semgrep: “MCP: Model, Context… Propaganda? What security teams need to know about the latest hyped up AI tech”.
Key questions
Q: What breaks when MCP servers run with shared local trust?
A: Shared local trust breaks isolation because any process on the machine may be able to call the server, and the server may inherit privileges that were never intended for broad reuse.
Q: What happens when AI agents use untrusted MCP servers?
A: When AI agents connect to untrusted MCP servers, the organization can inherit supply chain risk through the integration path.
Q: How should security teams secure MCP deployments in SaaS and developer environments?
A: Security teams should treat MCP as a new trust boundary, not just another integration layer.
Practitioner guidance
- Implement an MCP allow-list Approve only known, vetted, and internally managed MCP servers, and block ad hoc connections from developer environments and runtime agents.
- Isolate MCP servers by privilege tier Run MCP servers in containers or serverless environments with no default permissions, then grant only the minimum filesystem and network access required.
- Validate every tool argument server-side Reject path traversal, unsafe file paths, and untrusted command parameters at the MCP boundary before the tool executes.
Bottom line: MCP changes the control problem by letting AI models act through tools, not just generate text.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:10 pm
MCP makes context a security boundary, not a convenience layer. The protocol does not just connect models to tools, it moves trust decisions into the path where models decide what to call and what to read. That creates a new governance surface for IAM and NHI teams because tool access now behaves like delegated machine privilege. Practitioners should treat MCP context as an access control domain, not just prompt plumbing.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: What should teams do when AI tools can read files and run commands?
A: They should apply privileged dependency controls before approval, including provenance checks, least-privilege scoping, runtime monitoring, and prompt or data redaction. If the tool can execute or access sensitive paths, it should be treated like a high-risk integration. The control objective is to prevent hidden automation from bypassing the enterprise boundary.
👉 Read our full editorial: MCP changes how AI agents reach tools, data, and risk