TL;DR: MCP adoption is creating five recurring security blind spots, including typosquatting, excessive permissions, hard-coded secrets, and weak observability, according to Noma Security. The practical issue is not just exposure in individual servers, but the way agent interactions can cascade across connected systems and widen blast radius.
At a glance
What this is: This analysis identifies five MCP security blind spots that are already affecting production deployments, with cascading risk across connected AI agents, databases, APIs and business systems.
Why it matters: IAM, IGA and security teams need to treat MCP as an identity and privilege boundary, because agentic workflows can expand blast radius, bypass least-privilege assumptions and outpace existing audit models.
Context
MCP security is the governance problem that emerges when AI agents are allowed to reach databases, APIs and business systems through a common tool layer. The risk is not just exposure in one server. It is the way trust, access and observability break down once agent interactions become the path into production systems.
For identity teams, MCP turns what looks like an integration pattern into a non-human identity problem. Each server, token, package and tool permission becomes part of the effective access model, and that model fails when defaults are permissive, provenance is weak or audit trails are incomplete.
Noma Security's article argues that these failures are already present in live deployments, not just theoretical lab scenarios. That makes MCP governance a current control gap rather than a future architecture discussion.
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. This creates a local attack surface where authentication is bypassed or reduced to process proximity instead of explicit authorisation.
Q: Why do default-enabled MCP tools increase enterprise risk?
A: Because they let an agent inherit capabilities far beyond the task it was meant to perform. If read-only workflows also retain delete, export or write functions, least privilege is no longer real. The risk is amplified in connected environments where one over-granted server can touch many systems and widen the blast radius.
Q: How do security teams know whether MCP server governance is working?
A: They should be able to answer four questions at any time: what servers exist, which are official, what credentials they can use, and what systems they contact. If those answers are unclear, governance is not working. The signal is not just fewer alerts, but clear attribution and scoped access across the fleet.
Q: When should organisations prioritise blast-radius controls over more agent features?
A: They should prioritise blast-radius containment as soon as one MCP server can reach multiple business systems or sensitive data sets. Feature expansion without containment simply creates a larger failure domain. The safer sequence is to limit downstream reach first, then expand functionality only after the trust model is visible and tested.
Technical breakdown
Typosquatted MCP packages turn trust into an access vector
Typosquatting in MCP is a supply-chain pattern where a malicious or unofficial package is named so closely to a trusted one that teams install it by mistake. Because MCP servers sit directly in the agent-to-system path, the package is not just code. It becomes an identity-bearing control point that can inherit trust, collect credentials, or influence downstream tool use. The danger is amplified when the package name looks legitimate and the deployment process relies on human recognition rather than provenance checks.
Practical implication: verify package provenance and publisher identity before any MCP server is allowed to mediate agent access.
Default-permissive tools break least privilege for agentic workflows
Many MCP deployments expose all available tools by default, which collapses least privilege into broad capability inheritance. In practical terms, an agent that only needs read access can also inherit deletion, modification or export capabilities if those tools remain enabled. That creates a structural mismatch between the task and the access granted. In identity terms, the server is not merely a connector. It is a privilege broker, and default-enabled functionality turns that broker into a standing risk multiplier.
Practical implication: move from default-permissive to default-restrictive tool exposure and review each capability against task scope.
Hidden secrets and weak audit trails make MCP hard to govern
When API tokens and other secrets are hard-coded into MCP configuration files, the credential boundary becomes fragile and easy to leak. When the platform also lacks traceable logging, the organisation loses the ability to reconstruct which agent invoked which tool, with what parameters, and against which data. That combination creates a governance blind spot: credentials can spread quietly while the audit record needed to detect or contain misuse remains incomplete. In effect, the identity layer exists without reliable lifecycle or observability controls.
Practical implication: use short-lived authenticated access and insist on tool-level logging before MCP is approved for production.
Threat narrative
Attacker objective: The attacker aims to gain durable reach into agentic AI workflows so they can harvest credentials, manipulate tools and expand access into connected systems.
- Entry begins when a user or team installs a typosquatted or unofficial MCP server that appears to be a trusted package.
- Credential access follows when the server or its configuration path exposes tokens, prompts or other secrets needed for agent operation.
- Escalation occurs when the server gains broad tool permissions and can invoke destructive or data-access functions beyond the original task.
- Impact follows as the compromised or over-privileged server enables data exfiltration, system disruption and cascading effects across connected business functions.
Breaches seen in the wild
- Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
- Firebase misconfiguration exposure 2024: Missing Firebase security rules on 916 websites exposed 125 million user records and 19.87 million plaintext passwords; a quarter were fixed.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
MCP security blind spots are an identity governance problem, not just an AI tooling problem. Once an MCP server can mediate access to databases, APIs and business systems, it becomes part of the organisation's effective identity perimeter. That means provenance, privilege scope and auditability matter as much as code quality. The practitioner conclusion is that MCP must be governed as a non-human identity surface.
Default-permissive MCP configurations are a standing privilege problem. The article's 90% figure on dangerous defaults shows how quickly least privilege collapses when every tool ships enabled. This is not a minor tuning issue. It is a governance model that grants more capability than the agent needs and then expects downstream controls to clean up the excess. The practitioner conclusion is that capability scoping belongs at issuance, not after deployment.
Ephemeral credential trust debt is now visible in MCP deployments. Hard-coded secrets in configuration files create a persistent liability because the credential is both portable and easy to expose. OAuth-based flows reduce that exposure by shifting to user-bound, short-lived tokens with central governance. The practitioner conclusion is that teams should treat stored MCP secrets as unresolved trust debt, not as a convenience trade-off.
Agentic AI blast radius is the right named concept for MCP risk. A compromised server does not fail in isolation. It can cascade through connected tools, data stores and workflows, which means the real control objective is not only preventing compromise but also limiting how far one broken component can propagate. The practitioner conclusion is that blast-radius analysis should be built into MCP approvals and incident planning.
Observability is the control that determines whether MCP can be governed at all. Without traceable records of tool calls, parameters and accessed data, organisations cannot prove what an agent did or contain what it touched. That breaks both investigation and accountability. The practitioner conclusion is that logging quality is part of the access model, not a separate monitoring task.
From our research library:
- 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.
- Read next: MCP Security Guide
What this signals
Agentic AI blast radius: MCP changes the governance question from whether a single server is trusted to how far one server can propagate if it is compromised. That means security teams should measure downstream reach, not just server health, because one lookalike package or over-permissive tool set can affect multiple business functions at once.
The more MCP becomes the control plane for agent actions, the more identity teams need to treat tool permissions like active authorisation decisions rather than static configuration. OAuth-based access, scoped capabilities and traceable logs are the minimum ingredients for making that control plane governable in production.
For practitioners
- Audit MCP server provenance Inventory every MCP server in use, verify publisher identity, and remove any lookalike or unofficial package that was installed on naming similarity alone.
- Enforce default-restrictive tool sets Disable destructive and sensitive tools unless a task explicitly requires them, then recertify the enabled set whenever the workflow changes.
- Replace stored secrets with short-lived auth Prefer OAuth-based authentication or vault-backed issuance so MCP clients do not depend on hard-coded tokens in configuration files.
- Require agent-to-server audit logs Capture which tools were invoked, what parameters were passed, what data was accessed, and what results were returned for every MCP interaction.
- Test blast radius before production approval Map which downstream systems each server can reach, then block any deployment where a single agent action can cross multiple business functions without containment.
Key takeaways
- MCP security failures are not isolated software bugs. They are identity and privilege failures that can cascade across agent-driven workflows.
- The article describes recurring blind spots in production deployments, including typosquatting, overbroad tools, stored secrets and weak auditability.
- The strongest mitigation is not more agent freedom. It is tighter provenance checks, scoped permissions, short-lived credentials and logs that prove what each tool call did.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST AI RMF sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Plain-text MCP secrets and exposed config files are central risks in the article. |
| NHI-05 — Overprivileged NHI | The article shows MCP servers shipping with too many tools enabled by default. | |
| Recommendation — Scan MCP configuration paths for exposed secrets and replace them with short-lived authenticated access. Reduce MCP tool sets to the minimum required for each agent task. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agents inherit excessive capabilities through MCP servers and misuse them across connected systems. |
| Recommendation — Bound agent privileges to task scope and block inherited capabilities that exceed approved use. | ||
| NIST AI RMF | GOVERN — AI Governance and Accountability | The article is fundamentally about governance, accountability and control over agentic AI access paths. |
| Recommendation — Establish governance for MCP approvals, permission review and accountability before production use. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Typosquatting, secrets exposure and overbroad tools create pathways for credential theft and spread. |
| Recommendation — Map MCP threat scenarios to credential access and lateral movement detections in your monitoring stack. | ||
Key terms
- MCP Security: MCP security is the set of controls that protect Model Context Protocol connections between agents, tools, and data sources. It covers connector permissions, secret handling, and policy enforcement because the protocol can become a direct path from agent intent to enterprise action.
- Agentic Blast Radius: The scope of potential damage if an AI agent's identity or credentials are compromised, amplified by the agent's autonomy, breadth of access, and ability to chain actions at machine speed. Typically much larger than the equivalent blast radius for a static service account.
- Capability scoping: Capability scoping is the practice of limiting what a tool or agent can read, modify, execute, or reach. In MCP governance, it is the control that turns a broad approval into a narrow one by separating informational access from command, network, and secret-bearing actions.
- Ephemeral Credential Trust Debt: Ephemeral credential trust debt is the hidden risk that appears when short-lived tokens create a false sense of safety while permissions remain broad. The credential expires quickly, but the underlying blast radius stays large unless identity scope, revocation, and audit controls are also tightened.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on May 31, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org