Notifications
Clear all
Topic starter
02/08/2026 12:00 pm
TL;DR: MCP is moving from a promising integration layer to a security governance problem, because server-side tool access, credentials in configuration, and over-scoped permissions create new pathways for misuse, according to Hadrian and NHIMG reference research. The practical question is no longer whether agents can connect to tools, but whether those connections are scoped, auditable, and revocable before they become shadow access.
NHIMG editorial — based on content published by Hadrian: From MCP to Secure MCP: The Familiar Protocol Arc and the Unfamiliar Security Problem
By the numbers:
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
Questions worth separating out
Q: How should security teams govern MCP servers in production?
A: Treat each MCP server as a governed access boundary, not just a utility.
Q: Why do MCP servers create new risks for NHI governance?
A: MCP turns AI-facing integrations into persistent, callable access paths, which means secrets, resources, and tools all become part of the non-human identity surface.
Q: What breaks when secrets are stored in MCP configuration files?
A: A single exposed config can turn a helper process into a durable access path.
Practitioner guidance
- Classify every MCP server as a governed access point Create an inventory of all MCP servers, the tools they expose, the systems they can reach, and the credentials they store or reference.
- Remove hard-coded secrets from MCP configuration Scan configuration files for API keys, tokens, and certificates, then replace static values with centrally managed secrets and short-lived credentials where possible.
- Enforce tool-level least privilege for agents Define the exact tool set each MCP-enabled workflow needs, then block all other tool calls by default.
What's in the full article
Hadrian's full research covers the operational detail this post intentionally leaves for the source:
- The agentic testing workflow used to validate asset context and configuration changes in real environments.
- The specific remediation workflow for high-impact risks discovered through secure MCP-style integrations.
- The implementation detail behind reducing false positives while keeping tool-access boundaries visible.
- The end-to-end platform setup and autonomous execution steps that sit behind the summary findings.
👉 Read Hadrian's analysis of the secure MCP security problem →
Secure MCP and tool access governance: are your controls keeping up?
Explore further
02/08/2026 1:07 pm
Secure MCP is really an identity governance problem disguised as a protocol problem. The debate around MCP often focuses on interoperability, but the control failure usually sits in how tools, secrets, and permissions are assigned. Once an AI system can call external services on behalf of a task, it behaves like a delegated non-human identity and needs the same privilege discipline as any other workload or service account. Practitioners should therefore evaluate MCP through IAM and PAM, not only through API security.
A question worth separating out:
Q: What should teams do when MCP tools are added without access scoping?
A: Pause deployment until each tool has an explicit business purpose, a minimum permission set, and a named approver. Broad or default access should be treated as a governance defect, not a convenience. Without scoping, the system can invoke functions the business never intended, which is exactly how delegated access becomes abuse.
👉 Read our full editorial: Secure MCP shifts the risk from protocol to tool access governance
