MCP centralizes AI tool access, but trust and supply chain risk remain

At a glance

What this is: This is an analysis of how Model Context Protocol can standardize AI tool access and centralize governance, while still leaving trust and supply chain exposure unresolved.

Why it matters: It matters because MCP may simplify AI integration, but IAM and NHI teams still need controls for tool permissions, logging, and untrusted server risk.

By the numbers:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• 53% of MCP servers expose credentials through hard-coded values in configuration files.
• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read Noma Security's analysis of MCP security controls and AI tool governance

Context

Model Context Protocol is a standardized way for AI systems to connect to tools and data sources, but standardization does not remove the security work. In NHI governance terms, each connected tool, token, and server becomes part of the enterprise trust boundary, which means the protocol layer must be treated as an access-control surface rather than a convenience feature.

The core tension is simple: MCP can make AI integrations more manageable, yet it can also concentrate risk if teams connect agents to untrusted servers or leave permissions too broad. That puts IAM, authorization, logging, and supply chain review at the center of AI security decisions, especially as agentic systems begin to act with execution authority.

For practitioners, this is a familiar pattern in a new wrapper. Centralized visibility helps, but any protocol that expands tool connectivity also increases the consequences of weak scoping, weak monitoring, or weak third-party hygiene.

Key questions

Q: How should security teams govern AI agents that use MCP servers?

A: Security teams should govern MCP-connected agents as non-human identities with constrained tool reach, not as simple integrations. That means assigning owners, scoping permissions by use case, logging every tool call, and reviewing each connected server as part of the trust boundary. If the server cannot be trusted, the agent should not inherit broad access.

Q: What is the difference between MCP standardization and real security control?

A: MCP standardization gives teams a common interface for AI tool access, but real security control comes from identity, authorization, logging, and isolation around that interface. A standard can reduce integration chaos, yet it does not guarantee least privilege or safe third-party behaviour. Security outcomes depend on how the protocol is governed in production.

Q: Why do AI agents complicate zero trust architecture?

A: AI agents complicate zero trust architecture because they can chain decisions and call tools faster than human review can keep up. Zero trust still applies, but every tool invocation, credential, and data request needs continuous verification and explicit policy. Without that, autonomy can outrun the control plane.

Q: When does MCP create more risk than it reduces?

A: MCP creates more risk when teams use it to connect high-privilege tools without strong scoping, monitoring, or review of external servers. In that situation, the protocol centralizes access but also concentrates failure. The risk rises fastest when untrusted connectors can reach sensitive data or write-capable systems.

Technical breakdown

MCP as a centralized access layer for AI tools

MCP works as a standard communication layer between AI systems and external tools or data sources, similar to a controlled API gateway for agent actions. Instead of every agent integrating directly with each service, the protocol provides a common interface for discovery, authorization, logging, and policy enforcement. That reduces integration sprawl and gives security teams a single place to inspect which tools are available to which AI workflows. The governance value is not automatic, however. If the connected server is untrusted or overprivileged, the protocol simply standardizes the path to risk rather than eliminating it.

Practical implication: Treat MCP servers as governed access points, not neutral plumbing.

Why centralized logging matters for prompt injection and misuse

Prompt injection becomes more dangerous when an AI system can call tools without strong controls, because malicious instructions can translate into real actions. Centralized logging lets teams baseline normal agent behaviour, trace tool calls, and spot anomalies such as unexpected data access or unusual command sequences. This matters because agent abuse is rarely visible at the prompt alone; the damage appears when the model acts on tool permissions. In NHI terms, telemetry must cover both identity events and tool execution events so that governance teams can reconstruct intent, scope, and impact.

Practical implication: Correlate prompts, tool calls, and identity events in one audit trail.

Tool isolation and scoped permissions reduce blast radius

MCP can support separation between non-deterministic AI behaviour and deterministic tool access, which is useful when code interpreters, web access, or APIs are involved. By isolating high-risk tools and limiting access by role, use case, or domain, organizations reduce the blast radius if an agent is manipulated or misconfigured. This is especially relevant for NHI because the agent may not be a single identity in practice; it may operate through several tokens, connectors, and delegated credentials. Security design should assume that any one of those elements can become the weak link.

Practical implication: Segment high-risk tools and enforce least privilege at the connector layer.

Threat narrative

Attacker objective: The attacker wants to turn the AI integration layer into an execution path for unauthorized data access or operational action.

1. Entry through a trusted-looking MCP server or connector that an AI workflow is allowed to call.
2. Escalation when the agent inherits broad tool permissions, enabling it to access data or perform actions beyond intended scope.
3. Impact when the compromised connector is used to exfiltrate sensitive information, modify systems, or trigger downstream misuse.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

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

NHI Mgmt Group analysis

Centralized protocol control only helps if the connected identities are already trustworthy. MCP can improve visibility, but visibility is not the same as assurance. If teams connect agents to unvetted servers or leave permissions broad, they create a cleaner path to the same old failures. Practitioners should use MCP to tighten governance, not to justify weaker review of the identities and tools behind it.

Model Context Protocol creates a new form of identity blast radius. When an agent can route through multiple connectors, the operational risk is no longer just one token or one API key. The effective blast radius includes every tool the agent can reach, every data source it can query, and every downstream action it can trigger. Security teams should evaluate MCP through the lens of NHI lifecycle control and privilege containment.

Prompt injection becomes more actionable when tool execution is exposed. A malicious prompt is dangerous mainly when it can produce tool calls, file reads, or state changes. Centralized logging, policy enforcement, and anomaly detection are therefore not optional extras. They are the only way to distinguish normal agent autonomy from manipulated behaviour in a production environment.

Scoping controls matter more than protocol adoption. The article’s real lesson is that a protocol can reduce integration chaos without solving authorization design. That means role-based and attribute-based policy, rate limits, isolation, and review of connected servers still need to be explicit. Practitioners should measure success by reduced privilege and clearer accountability, not by the mere presence of a common standard.

Untrusted connectors are the supply chain problem hiding inside AI automation. Every external MCP server extends the enterprise trust chain, and each new dependency can introduce credential exposure, data leakage, or malicious tool behaviour. That makes third-party review, allow-listing, and runtime monitoring essential for any serious NHI governance program. Teams should treat connector onboarding as a security decision, not an integration task.

From our research:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, 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 governance lens on the broader control gap, see OWASP Agentic AI Top 10, which maps the security failures most likely to affect autonomous tool use.

What this signals

Ephemeral control is becoming the right mental model for AI tool governance. MCP may reduce integration friction, but practitioners should assume that any agentic access path can become high value the moment it reaches sensitive systems. With 80% of organisations already reporting AI agents acting beyond intended scope, per AI Agents: The New Attack Surface report, the governance gap is no longer theoretical.

The practical signal is that protocol adoption will not rescue weak entitlement design. Teams need to prepare for connector review, tool-level authorization, and evidence-driven access decisions because agent behaviour is dynamic and can outgrow static approvals quickly. That is especially true where AI systems are allowed to touch production data, secrets, or administrative interfaces.

For practitioners

• Inventory every MCP-connected tool and server Create a complete list of connectors, owners, permissions, and downstream data sources before allowing production use. Pay special attention to shadow tools, duplicated integrations, and servers that can reach sensitive systems.
• Enforce least privilege at the connector layer Scope access by role, use case, and data class so that an agent can only reach the tools it truly needs. Remove broad default permissions and review every connector that can trigger write actions or external calls.
• Correlate prompts with identity and tool telemetry Log prompt inputs, tool calls, authorization decisions, and response outputs in one audit path. This makes it possible to detect prompt injection, misuse, and abnormal execution patterns across agent workflows.
• Treat untrusted MCP servers as supply chain risk Apply third-party review, allow-listing, and runtime monitoring before connecting any external server. If a connector cannot be validated, isolate it or block it entirely.

Key takeaways

• MCP can improve AI governance only when teams treat connected tools as part of the identity perimeter.
• The bigger risk is not protocol adoption itself but untrusted connectors, broad permissions, and weak telemetry.
• NHI and IAM teams should evaluate MCP through blast radius, not convenience, because agentic access can scale failure as quickly as it scales productivity.

Key terms

• Model Context Protocol: A standardized protocol that lets AI systems connect to tools and data sources through a common interface. In practice, it becomes part of the enterprise trust boundary because it can concentrate identity, authorization, and logging decisions around agent actions.
• Non-Human Identity: A non-human identity is a machine- or software-based credential set used by services, workloads, bots, or AI agents to authenticate and act. These identities need the same lifecycle controls as human identities, including ownership, scoping, review, rotation, and offboarding.
• Identity Blast Radius: Identity blast radius is the amount of damage that can follow if a single credential, token, or agent is abused. For AI systems, it includes every tool, data source, and action path reachable through delegated access, making privilege containment a core control objective.

Deepen your knowledge

MCP governance, tool scoping, and AI agent identity risk are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls around connected AI systems, it is worth exploring.

This post draws on content published by Noma Security: Understanding MCP and its role in strengthening AI security. Read the original.