MCP can be secure at the transport and protocol layer while still leaving the identity layer exposed. The risk comes from what sits underneath the protocol, including secrets, service accounts, and broad tool permissions. If those controls are weak, a secure protocol simply makes it easier to scale insecure access patterns across more systems.
Why This Matters for Security Teams
MCP can remove friction from how tools are discovered and called, but it does not remove the identity problem underneath. If the workload using MCP still authenticates with long-lived secrets, broad service accounts, or over-permissioned tool access, the protocol can spread exposure faster. That is why identity risk remains even when the transport and message format are sound. Current guidance from NIST Cybersecurity Framework 2.0 still points teams back to asset visibility, access control, and continuous governance.
The practical issue is that MCP often becomes a force multiplier for existing NHI weaknesses. A single compromised token, API key, or agent service account can reach more data, more tools, and more workflows once MCP is wired into production. That pattern mirrors the broader NHI exposure documented in the Ultimate Guide to NHIs, where 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface. In practice, many security teams encounter MCP-related abuse only after a tool has already been used outside its intended scope, rather than through intentional design.
How It Works in Practice
The protocol can be secure while the access model remains weak. In a typical MCP deployment, the agent, assistant, or automation layer authenticates to a set of tools and then asks for actions on behalf of a user or workflow. If that identity is static, the blast radius is determined by the permissions attached to it, not by the security of MCP itself. That is why identity design has to include short-lived credentials, tighter scoping, and explicit approval boundaries, not just secure endpoints.
Practitioners should think in terms of what the workload is allowed to do at runtime. That means tying access to workload identity, not only to a shared secret, and using JIT credential issuance where possible. It also means separating tool discovery from tool execution, so the agent cannot silently turn broad visibility into broad authority. The most useful control pattern is often a combination of RBAC for baseline entitlement, intent-based authorization for the specific action, and ephemeral secrets that expire quickly after use. The Top 10 NHI Issues and OWASP Agentic AI Top 10 both reinforce that agentic systems need runtime controls, not only static onboarding checks.
- Use workload identity for the MCP client or agent, not shared human-style credentials.
- Issue per-task secrets with the shortest workable TTL and revoke them automatically.
- Restrict tool permissions to the minimum action set required for each workflow.
- Log tool calls, token use, and downstream data access for audit and response.
- Review whether each MCP server can be reached only by approved identities and approved contexts.
These controls tend to break down when MCP is layered onto legacy automation, because legacy scripts and service accounts are rarely built for per-task authorization or rapid secret rotation.
Common Variations and Edge Cases
Tighter credential scoping often increases operational overhead, requiring organisations to balance reduced blast radius against deployment complexity. That tradeoff is especially visible when teams want MCP to support many tools, many tenants, or fast-moving agent workflows. There is no universal standard for this yet, but current guidance suggests favouring short-lived, context-aware access over durable credentials whenever the workflow can tolerate it.
Edge cases appear when the agent is autonomous enough to chain actions across multiple systems. In those environments, a protocol-secure MCP stack can still create hidden escalation paths if one tool exposes secrets, another allows data export, and a third can trigger writes. The AI Agents: The New Attack Surface report shows how often agents act beyond intended scope, which is why static IAM models struggle once behaviour becomes goal-driven. Teams should also align MCP governance with OWASP Top 10 for Agentic Applications 2026 and the identity governance patterns in the Ultimate Guide to NHIs so that runtime permissions, secret lifetime, and offboarding are treated as one control plane. The cleanest answer is not to distrust MCP, but to stop assuming protocol security is the same as identity security.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A03 | Agentic systems need runtime authorization and scope control for tool use. |
| OWASP Non-Human Identity Top 10 | NHI-03 | MCP increases the impact of long-lived or overused NHI credentials. |
| NIST AI RMF | GOVERN | Autonomous tool use needs explicit accountability and oversight. |
Reduce credential lifetime and rotate NHI secrets before they become reusable blast-radius amplifiers.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 3, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
