MCP security exposes the trust gap in AI agent tool access

At a glance

What this is: This is an analysis of Model Context Protocol security, highlighting that MCP expands AI agent access to tools and data while creating new trust and privilege risks.

Why it matters: It matters because IAM, PAM, and NHI teams now have to govern agent-to-tool access, not just human logins or static service accounts, across development and runtime environments.

By the numbers:

• 84% of professional developers use or plan to use AI tools daily, highlighting the importance of granular permissioning.
• 5.5% exhibited tool-poisoning vulnerabilities, instances where modified or malicious servers altered tool outputs, injected false command responses, or redirected data flows to unauthorized endpoints.

👉 Read Knostic's analysis of MCP server security risks and control gaps

Context

MCP security is the control problem created when AI agents, IDEs, and external tools exchange capabilities through a standard protocol instead of bespoke integration code. The primary keyword here is MCP security, and the question is whether identity and access controls still hold when an agent can request tools, read files, and run commands through a shared trust layer.

The article argues that the weak point is not MCP itself but the assumption that every server, plugin, and command path is already trustworthy. For identity programmes, that pushes the boundary of governance toward endpoint verification, scoped permissions, and auditability across agent-server interactions, especially where development environments carry elevated access.

That makes MCP a practical identity issue as much as an application-security issue. If the protocol is treated like a simple plugin interface, teams will miss how quickly a spoofed server or over-broad permission can turn an AI coding assistant into a high-trust execution path.

Key questions

Q: How should security teams govern AI agent access through MCP?

A: Security teams should govern MCP as an identity and privilege boundary, not as a simple integration layer. That means authenticating servers, scoping tool permissions to the smallest viable workspace, logging every agent-server interaction, and separating trusted capabilities from experimental ones. If the agent can execute commands, treat that path like privileged access.

Q: Why do MCP-connected agents increase the risk of privilege sprawl?

A: MCP-connected agents increase privilege sprawl because they can chain file, shell, and API actions across shared environments once broad access is granted. A single over-permitted server can cascade into wider execution than the original task required. The governance answer is to limit each server, session, and workspace to a narrow, reviewable scope.

Q: What do security teams get wrong about MCP plugin risk?

A: Teams often treat plugins as if they were ordinary extensions, when in practice they can become trust-bearing execution components. If a plugin can influence tool output or run commands, it must be validated, scanned, and constrained before use. The mistake is assuming registry presence equals legitimacy.

Q: How do you know if MCP security controls are actually working?

A: You know MCP controls are working when untrusted endpoints are blocked, privileged tool calls are minimal, and audit logs show only approved commands and data flows. If teams cannot reconstruct which server asked for what, or if secrets appear in configuration files, the control set is not operating as intended.

Technical breakdown

How MCP creates a trusted tool execution layer

Model Context Protocol uses a client-server pattern where the agent or IDE requests capabilities and the server exposes them in a structured way. JSON-RPC keeps the exchange simple and extensible, which is useful for connecting files, APIs, shell commands, and search tools. The security problem is that the protocol standardises trust at the transport and capability layer, but it does not by itself guarantee that the server is authentic, the tool is safe, or the response is truthful. That means a compromised server can shape both what the model sees and what it executes.

Practical implication: treat every MCP endpoint as an identity-controlled execution boundary, not a benign integration.

Why spoofed MCP servers and prompt injection are especially dangerous

A spoofed or malicious MCP server can return falsified tool output, hide unsafe instructions, or redirect the agent into unintended actions. Because the agent often trusts tool descriptions and follows chained instructions, prompt injection can move from one response into multi-step execution without a human check. In this model, the attack is not limited to one bad prompt. It becomes a trust-chain problem where the server, the tool metadata, and the agent’s execution sequence all matter. Once the model accepts poisoned context, downstream actions inherit that compromise.

Practical implication: validate server identity and tool integrity before the agent is allowed to consume or act on responses.

How over-privileged MCP permissions turn one mistake into environment-wide impact

MCP becomes risky when agents get broad file, shell, or network access across workspaces. Over-privileged permissions let one compromised tool call cascade into code execution, data exposure, or configuration drift in shared environments. The article’s point is that least privilege still applies, but the blast radius is larger because agents can chain commands quickly and repeatedly. If permissions are not scoped per workspace and session, a single unsafe integration can spread across development systems that were assumed to be isolated.

Practical implication: scope permissions per workspace and isolate sessions so one MCP failure cannot propagate laterally.

NHI Mgmt Group analysis

MCP security is becoming the control plane for AI agent trust. The protocol standardises how agents request tools and data, so identity decisions now happen at the point of tool exposure rather than only at user authentication. That shifts governance from one-time login checks to continuous validation of endpoints, permissions, and command paths. Practitioners should treat MCP as part of the identity boundary, not just the integration layer.

Tool poisoning shows that content trust and identity trust are now linked. When a server can alter tool outputs, the agent may execute actions based on manipulated context rather than original intent. That is not only an application-security flaw. It is a governance problem because the trust decision and the action decision collapse into the same runtime moment, which makes post hoc review weaker. Practitioners need to treat server integrity as a prerequisite for agent authority.

Over-privileged agent access creates identity blast radius, not just feature creep. Once an MCP-connected agent can read files, run commands, and reach APIs, the privilege model becomes much more consequential than traditional plugin risk. The named concept here is identity blast radius: the distance an attacker can travel after one credentialed or trusted MCP action. Teams should measure blast radius by workspace, server, and command class, then reduce it before broad deployment.

Least privilege for MCP has to be enforced at the server, workspace, and session level. A general policy statement is not enough when tools can be chained dynamically across development workflows. The useful governance model is one that limits what each server can expose, what each session can retain, and what each agent can call without separate trust checks. Practitioners should assume that capability sprawl will arrive faster than manual review cycles.

MCP governance will converge with NHI governance and AI agent oversight. The same questions that apply to service accounts now apply to agent identities, tool permissions, secrets exposure, and audit evidence. That means IAM and security teams should stop separating “developer tooling” from identity governance. The programme that owns non-human access will increasingly own MCP risk as well.

From our research:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, according to The State of MCP Server Security 2025.
• In the same research, 53% of MCP servers expose credentials through hard-coded values in configuration files, which makes secret storage a governance issue rather than a local hygiene problem.
• For broader AI-access risk context, see LLMjacking: How Attackers Hijack AI Using Compromised NHIs for a different view of how exposed credentials are exploited in practice.

What this signals

Identity blast radius will become the right way to size MCP risk. Teams should stop asking only whether an integration is trusted and start asking how far one trusted server can move before controls intervene. In environments where multiple IDEs, plugins, and agent frameworks share access, blast radius is now a measurable governance variable, not a theoretical concern.

With 53% of MCP servers exposing credentials through hard-coded values in configuration files, per The State of MCP Server Security 2025, development teams need inventory, not assumptions. The next control failure will often be configuration sprawl, not model failure.

That shifts the operational question from whether agents can use tools to whether each tool path is separately owned, logged, and revocable. Programmes that already govern service accounts and secrets should extend those controls into MCP-connected IDEs before usage becomes entrenched.

For practitioners

• Validate every MCP endpoint before trust is granted Require certificate checks, allowlists, and hash validation for servers and plugins before they are loaded into IDEs or agent workflows. Treat verification failure as a hard stop, not a warning.
• Scope tool permissions to the smallest workable workspace Assign file, shell, and API access per workspace and per server, then review those scopes whenever extensions or configurations change. Avoid all-access defaults in shared development environments.
• Isolate agent sessions and reset them after completion Run MCP-connected agents in sandboxes or ephemeral containers so credentials, context, and command history do not persist beyond the task. This reduces lateral spread when a server or plugin is compromised.
• Audit agent-server interactions continuously Log tool calls, outbound connections, unusual command bursts, and configuration drift so security teams can spot poisoned context or silent misuse early. Store logs safely and review them alongside access governance evidence.
• Scan plugins and configuration files before deployment Check new MCP extensions against approved inventories and known unsafe commands before they reach production development workflows. Pay particular attention to secrets stored in config files or environment variables.

Key takeaways

• MCP security is an identity problem because the protocol turns tool exposure into a privileged trust decision.
• Real-world MCP research shows both hard-coded secrets and tool-poisoning risks, so configuration review and endpoint verification cannot be optional.
• Teams should reduce identity blast radius by scoping permissions, isolating sessions, and auditing every agent-server interaction.

Key terms

• Model Context Protocol: A standard that lets AI agents, IDEs, and tools exchange structured requests and responses. In security terms, MCP defines how capabilities are exposed and consumed, which makes identity, authentication, and permission scoping part of the protocol trust model rather than an afterthought.
• Tool Poisoning: A failure mode where an MCP server or plugin alters tool output, metadata, or responses so the agent acts on manipulated context. The risk is not only bad content, but bad execution decisions, because the agent can chain subsequent actions from poisoned instructions.
• Identity Blast Radius: The amount of damage an attacker or misbehaving tool can cause once one trusted identity path is abused. For MCP, this measures how far a compromised server, plugin, or session can move across files, commands, APIs, and shared workspaces before controls stop it.
• Scoped Agent Permission: A narrowly defined access grant for an AI agent or MCP server that limits which tools, folders, APIs, and commands it may use. The goal is to make each permission reviewable, revocable, and tied to a specific task rather than to a broad environment.

What's in the full article

Knostic's full research covers the operational detail this post intentionally leaves for the source:

• A deeper walkthrough of MCP server security failure modes, including spoofed endpoints, prompt injection, and unsafe command execution
• The full benchmark data behind hard-coded credentials, tool-poisoning findings, and configuration exposure patterns
• Practical examples of endpoint validation, plugin scanning, and policy enforcement inside development environments
• Implementation detail on how the Kirin layer adds real-time guardrails within IDE workflows

👉 The full Knostic article covers MCP threat scenarios, best practices, and the Kirin implementation detail.

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.