MCP security blind spots are expanding agentic AI attack surfaces

At a glance

What this is: This analysis argues that MCP deployments are introducing five common security blind spots that expand agentic AI attack surfaces across databases, APIs, and business systems.

Why it matters: For IAM and NHI practitioners, the issue is that tool access, identity controls, and auditability must now cover agent-to-server interactions, not just human and service account access.

By the numbers:

• More than 90% of organizations maintain dangerous default configurations in MCP servers.
• 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 Noma Security's analysis of MCP security blind spots in agentic AI

Context

Model Context Protocol, or MCP, connects AI agents to tools and data sources. That makes it useful for automation, but it also turns each server into an identity and access boundary that traditional application security often does not model well. The result is an NHI governance problem, because the risk is not only what the agent can do, but what every attached tool can reach.

Noma Security frames the issue as five blind spots that are already appearing in production deployments: typosquatting, excessive capabilities, data exfiltration through untrusted code or remote services, plain text secrets in configuration files, and weak observability. That mix is familiar to IAM teams, but MCP compresses the failure modes into a faster-moving agent runtime. In practice, many organisations are still treating MCP as a feature layer rather than a governed identity plane.

The starting position described here is not unusual. It reflects what happens when teams adopt agentic systems faster than they define trust boundaries, privilege scoping, and traceable audit controls for machine actions.

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 deployments create NHI risk beyond normal application security?

A: MCP links agents directly to tools and data sources, so a single server can inherit access across multiple systems. That changes the risk model from isolated application vulnerabilities to cross-system identity and privilege exposure. If the agent or server is compromised, the resulting blast radius can extend far beyond one application boundary.

Q: What is the difference between OAuth-based MCP authentication and stored secrets?

A: OAuth uses short-lived, centrally managed tokens that can be scoped and revoked through the identity provider. Stored secrets are static credentials that tend to spread through files, endpoints, and backups. For MCP, OAuth reduces secret exposure and makes credential governance more consistent across the agent lifecycle.

Q: When should organisations delay MCP rollout until controls are in place?

A: Delay rollout when the server cannot be verified, permissions cannot be scoped, or actions cannot be logged. Those three gaps turn an agent tool into an uncontrolled access path. If the organisation cannot prove provenance, limit privilege, and audit usage, the deployment is not ready for production.

Technical breakdown

Typosquatting in MCP ecosystems

Typosquatting in MCP ecosystems works because trust is often inferred from package names, community popularity, or tooling defaults. A malicious or unofficial server can mimic a legitimate package closely enough that an operator installs it without noticing the difference. Once deployed, the server can sit in the agent chain with access to prompts, credentials, and downstream systems. The security issue is not just code quality. It is identity confusion at the tool layer, where the wrong server can inherit trust that was meant for the right one. That makes package provenance and publisher verification part of identity governance for agentic AI.

Practical implication: verify MCP package provenance and require publisher checks before any server is trusted in production.

Why excessive capabilities become default privilege

MCP servers often expose multiple tools, but many deployments leave all of them enabled by default. That creates a privilege model where the agent receives more authority than its task requires, including read access to sensitive data or destructive actions such as deletion. In IAM terms, this is standing privilege translated into machine-to-tool access. The problem grows when the agent can invoke tools dynamically, because access review no longer maps neatly to a single application role. Least privilege still applies, but it must be enforced at the tool and action level rather than at the server level alone.

Practical implication: scope each MCP server to only the tools required for the approved task set and review destructive actions separately.

Secrets, OAuth, and auditable machine identity

Hard-coded secrets in MCP configuration files create brittle machine identity. If a token is embedded in a local config file, that credential can leak through file sharing, endpoint compromise, or backup misuse. OAuth changes the pattern by shifting authentication to an identity provider and using short-lived tokens with centralized governance. That is closer to modern NHI management because it reduces long-lived secret exposure and improves revocation. The architectural goal is not just better convenience. It is a cleaner identity lifecycle, where the system can authenticate, scope, rotate, and revoke access without depending on static secrets stored on endpoints.

Practical implication: replace stored secrets with OAuth or vault-backed token handling wherever MCP server design allows it.

Threat narrative

Attacker objective: The attacker wants to turn a trusted agent tool into a durable path for credential theft, data exfiltration, and broader system compromise.

1. Entry occurs when an operator installs a typosquatted or unofficial MCP server that resembles a trusted package.
2. Escalation follows when the server is granted default permissions that expose sensitive tools, credentials, or destructive actions.
3. Impact emerges as the compromised server harvests data, injects malicious prompts, or creates persistent access paths into connected business systems.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MCP security is really NHI governance at the tool boundary. Once agents connect to databases, APIs, and internal systems, the important control question becomes which tool can act, under what identity, and with what blast radius. Traditional application security does not fully answer that question because MCP collapses identity, authorisation, and execution into a single runtime decision. Practitioners should treat each server as a governed access surface, not a convenience layer.

Ephemeral agent behaviour does not remove trust debt. Short-lived actions still depend on durable assumptions about package provenance, server identity, and permission scope. If those assumptions are weak, the organisation inherits risk every time a new server is onboarded or a tool is enabled. The field needs a clearer model for ephemeral credential trust debt, because agents move fast but governance still has to know what is being trusted and why.

Default-permissive MCP design is incompatible with least privilege. If every tool ships enabled, the organisation is already behind before policy is applied. This mirrors the same failure pattern seen in service accounts and over-scoped tokens, but now the damage can spread across connected systems in a single action chain. Security teams should move from server-level approval to tool-level authorisation and continuous review.

Observability is now a control requirement, not a nice-to-have telemetry layer. Without traceable logs for tool calls, parameters, accessed data, and returned results, incident response cannot reconstruct what an agent did. That leaves compliance teams, auditors, and responders blind when an MCP server behaves unexpectedly. Practitioners should assume that unlogged agent actions are effectively ungoverned actions.

OAuth and vault-backed secret handling are the practical path out of static NHI exposure. The article points toward a familiar but still underused answer: move from embedded secrets to centrally managed, short-lived credentials wherever possible. That approach aligns with modern identity lifecycle controls and reduces the number of places where a leaked file becomes a security incident. Teams should prioritise systems that can eliminate stored secrets altogether.

From our research:

• 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%), according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• For a broader control model, see OWASP Agentic AI Top 10, which maps tool misuse and identity abuse to concrete agentic risks.

What this signals

Ephemeral credential trust debt: MCP deployments often feel temporary and experimental, but the trust decisions made during onboarding can persist for the life of the environment. That means the real programme risk is not just exposure at first install, but unmanaged permission creep, incomplete revocation, and tool sprawl over time. Teams should fold MCP into identity lifecycle governance, not treat it as an isolated AI project.

The control direction is clear: agent-to-server telemetry, package provenance checks, and short-lived credentials must be brought into the same governance workflow that already covers NHI secrets and privileged access. As NHI adoption expands, the organisations that can prove who or what acted, through which tool, and with which privilege will be better placed to contain AI-driven incidents and satisfy auditors.

With 80% of organisations already reporting agent behaviour outside intended scope, per AI Agents: The New Attack Surface report, the governance gap is no longer theoretical. MCP simply makes the failure modes easier to trigger and harder to see, which is why runtime control has to become part of the access model.

For practitioners

• Inventory every MCP server in use Build a register of all MCP servers, their publishers, installed versions, and connected data sources. Verify whether any package names resemble trusted tools but come from different publishers, and quarantine anything that cannot be tied to a known source.
• Enforce tool-level least privilege Disable every non-essential tool by default and require approval before enabling destructive or sensitive capabilities. Review permissions at the individual tool level, especially where a single MCP server can reach multiple systems or datasets.
• Replace embedded secrets with managed identity flows Prefer OAuth or vault-backed token handling over plaintext credentials in configuration files. Where static secrets remain unavoidable, restrict file exposure, shorten token lifetimes, and tie revocation to the identity provider lifecycle.
• Add audit trails for agent-to-server calls Log every tool invocation, parameter set, accessed record, and returned result so that investigations can reconstruct the full impact chain. Use the logs to map blast radius and to distinguish normal automation from anomalous behaviour.
• Isolate MCP runtime execution Run MCP servers in containers with constrained filesystem and network access so a compromised server has less room to move. Use container controls to simplify rollback and to reduce host-level persistence if the server is abused.

Key takeaways

• MCP changes the NHI problem from credential management to governed tool execution.
• Production risk grows fastest where packages cannot be verified, tools are enabled by default, and actions are not logged.
• Teams should prioritise provenance, least privilege, short-lived credentials, and traceable runtime controls before wider MCP rollout.

Key terms

• Model Context Protocol: Model Context Protocol is an open way for AI agents to connect to tools and data sources. In security terms, it creates a new trust boundary because the agent can act through external systems, making provenance, authorization, and logging central to NHI governance.
• Non-Human Identity: A non-human identity is any machine, workload, service account, token, certificate, or agent that authenticates and acts without a person directly behind each action. These identities need lifecycle management, least privilege, rotation, and auditability just like human identities, often with higher speed and volume.
• Blast Radius: Blast radius is the amount of damage a compromised identity, server, or tool can cause before containment stops it. For MCP and agentic AI, it measures how far an unsafe action can spread across systems, data, and business workflows after a single trust failure.

Deepen your knowledge

MCP security blind spots, tool-level least privilege, and secretless authentication are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for agentic AI and MCP deployments, the course provides a practical starting point.

This post draws on content published by Noma Security: five critical MCP security blind spots in enterprise AI deployments. Read the original.