Secure MCP shifts the risk from protocol to tool access governance

At a glance

What this is: This is an analysis of how the Model Context Protocol changes the security problem from simple connectivity to tool-level access governance and credential exposure.

Why it matters: It matters because IAM, PAM, and NHI teams now need to govern agent and service permissions inside MCP workflows, not just the API or host they sit on top of.

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.

👉 Read Hadrian's analysis of the secure MCP security problem

Context

Model Context Protocol is a structured way for AI systems to connect to tools and data sources, but the security question starts where the protocol ends: which tools are exposed, which credentials are embedded, and who can use them. For MCP, the primary risk is not the transport layer itself, but the governance gap between agent intent and effective privilege.

That gap matters because AI systems increasingly act through delegated access rather than direct human authentication. When an MCP server bundles secrets, grants broad tool permissions, or lacks auditability, it creates a non-human identity governance problem that sits squarely between IAM, PAM, and AI security.

Hadrian’s framing is useful because it shifts the discussion away from protocol novelty and toward operational control. That starting position is increasingly typical for security teams encountering MCP in production, because the first failure mode is usually not exploitation of the protocol spec but weak access design around it.

Key questions

Q: How should security teams govern MCP servers in production?

A: Treat each MCP server as a governed access boundary, not just a utility. Require publisher verification, tool-level approval, least-privilege scopes, and audit logging before production use. The goal is to control what the agent can reach, how long it can reach it, and how every action is traced for response and compliance.

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. If those interfaces are not bound to lifecycle controls, teams lose visibility into who or what is using enterprise capabilities and when.

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. If API keys, tokens, or credentials are stored in plaintext or environment variables, any process that reads the file may reuse the privileges. That makes secret rotation necessary but insufficient unless the underlying integration is also reviewed and constrained.

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.

Technical breakdown

Why MCP creates a new tool access surface

MCP standardises how AI applications discover and call external tools, but that convenience also concentrates trust. The server becomes a broker for actions, data, and often credentials, which means a single poorly governed integration can expose multiple downstream systems. Security problems usually appear when tool permissions are inherited from the host application instead of explicitly scoped per use case. In practice, that turns the MCP layer into a privilege aggregation point rather than a neutral transport.

Practical implication: inventory every MCP server as an access broker, not just an integration endpoint.

How secrets and config files become the weak link

MCP deployments often rely on configuration files to define endpoints, tool mappings, and authentication material. If those files contain hard-coded secrets or long-lived tokens, the protocol inherits classic secrets-management failure modes: static exposure, reuse, and poor revocation. The problem is amplified when secrets are shared across environments or bundled with tool definitions, because compromise of one configuration path can unlock multiple systems. This is a familiar NHI pattern, even when the identity belongs to software rather than a person.

Practical implication: treat MCP configuration as a secrets-bearing control plane and scan it accordingly.

Why tool permission scoping matters more than protocol adoption

A secure MCP design depends on the principle that an agent should only reach the tools needed for a narrowly defined task. Without access scoping, a compromised or misbehaving agent can move from benign querying into unauthorised actions such as data access, workflow mutation, or credential abuse. This is where NHI governance becomes central: if the AI system is acting as a delegated identity, then least privilege, approval boundaries, and revocation controls must apply at the tool level, not just the account level.

Practical implication: enforce tool-level least privilege and require explicit scoping for every MCP integration.

Threat narrative

Attacker objective: The attacker seeks to convert one exposed MCP integration into broader access across multiple connected systems and data stores.

1. Entry occurs through an MCP deployment that exposes tools or credentials in configuration files or overly permissive server settings.
2. Escalation follows when the agent or attacker uses those permissions to reach systems beyond the intended task scope.
3. Impact occurs when unauthorised tool calls, data access, or secret reuse enable broader compromise across connected services.

NHI Mgmt Group analysis

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.

Hard-coded secrets are the most obvious symptom, but over-scoped tool permission is the deeper failure mode. A configuration file full of credentials is visible and measurable, but the more persistent risk is that a single agent account can reach many tools with no task-specific boundary. That is a standing privilege problem in a new wrapper. Teams should focus on whether each MCP integration has a narrow, revocable privilege envelope.

MCP will accelerate shadow AI if discovery does not include tool registrations and delegated access paths. Security teams already struggle to find all service accounts, tokens, and certificates; MCP adds another layer of hidden access relationships. The named concept here is tool access sprawl, meaning the unchecked growth of AI-connected tool permissions across environments. Practitioners should extend discovery, review, and offboarding processes to the MCP layer before adoption widens.

OWASP-NHI and agentic AI guidance will become more relevant as MCP moves into production systems. MCP is not just an AI integration pattern, it is also a trust boundary where agent identity, tool identity, and data access converge. That makes it a natural fit for OWASP-NHI thinking, alongside emerging agentic AI controls, because the governance question is whether delegated software can be constrained with the same rigor as human access. Practitioners should map MCP deployments to identity controls now, while the architecture is still changing.

What this signals

Tool access sprawl: MCP adoption will widen the number of places where AI-enabled systems hold direct access to tools, secrets, and data paths. That means security teams should extend discovery, entitlement review, and offboarding beyond human IAM and into machine and agent workflows, using OWASP Agentic AI Top 10 and NIST AI Risk Management Framework principles where the agent boundary is real.

The operational signal to watch is not just whether MCP exists, but whether each server has clear ownership, bounded tool permissions, and live revocation paths. If those controls are missing, the programme will accumulate hidden non-human identities that are hard to audit and harder to contain when an incident occurs.

For practitioners, the next step is to treat MCP rollout as a governance programme, not an integration task. Link any new deployment to secrets management, access scoping, and change control so the protocol does not outrun the security model.

For practitioners

• 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. Prioritise any server that can trigger writes, exports, or administrative actions, because those are the highest blast-radius paths. Use that inventory to assign an owner, a risk tier, and a review cycle.
• 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. Validate that the runtime can still authenticate after rotation or revocation, because unreachable secrets are not a control. This reduces the chance that one leaked config file becomes a multi-system compromise.
• 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. Separate read-only and write-capable integrations, and require re-approval before adding new tools or broader scopes. This prevents a compromised agent from turning a narrow integration into a general-purpose access path.
• Extend offboarding and revocation to delegated AI access When a workflow, agent, or integration is retired, revoke its tokens, remove its tool registrations, and verify that downstream services no longer trust it. This is especially important where MCP servers are copied between environments, because stale registrations can outlive the business use case they supported.

Key takeaways

• MCP expands the attack surface by turning AI connectivity into a privileged access problem, especially when tools and secrets are bundled together.
• The strongest quantitative signal in current research is not protocol complexity but exposure, with hard-coded credentials and unscoped tool access already common.
• Security teams should govern MCP as delegated NHI infrastructure, with inventory, least privilege, and revocation controls applied at the tool layer.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Tool access sprawl: The uncontrolled growth of tools, permissions, and delegation paths exposed to AI-enabled workflows. It becomes a governance problem when each new integration adds hidden privilege, making inventory, review, and offboarding progressively harder across environments.
• Delegated non-human identity: A machine or agent identity that acts on behalf of a user or system and inherits access to connected tools. The control problem is not only authentication, but the scope, duration, and downstream reach of that delegation once the session is established.

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.

👉 Hadrian's full post covers the operational testing workflow, prioritisation logic, and remediation detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in practical terms. It helps security and identity practitioners build the controls needed to manage delegated access as AI-connected systems expand.