Who is accountable when a malicious MCP server or Skill reaches production?

Why This Matters for Security Teams

A malicious mcp server or Skill is not just a bad integration, it is a supply chain entry point with delegated authority. Once a tool is approved for production, it can mediate data access, trigger actions, and shape agent behaviour across systems. That makes ownership a governance issue, not a narrow engineering issue. Current guidance suggests treating these components like production software with explicit approval, versioning, and rollback, rather than as harmless add-ons.

This is especially important because agentic environments expand the blast radius of a single weak control. The OWASP Agentic Applications Top 10 and OWASP Top 10 for Agentic Applications 2026 both reflect the same operational reality: if a server or Skill can influence tool use, then trust in the tool is trust in the workload. In NHI Management Group analysis of the State of MCP Server Security 2025, 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, which shows how quickly governance failures turn into credential exposure.

In practice, many security teams discover the problem only after a production agent has already been connected to an unreviewed tool, rather than through intentional change control.

How It Works in Practice

Accountability should follow the approval path, the distribution path, and the operational path. The team that publishes the MCP server or Skill owns secure design and release hygiene. The platform team owns the admission controls that decide what can be installed. The application or agent owner owns runtime behaviour, scope, and monitoring. Security owns policy, review gates, and exception handling. That split aligns with the principle in NIST SP 800-53 Rev 5 Security and Privacy Controls that control ownership must be explicit and testable.

In operational terms, a secure process usually includes:

• pre-production review of tool capabilities, permissions, and data flows
• signed or version-controlled releases for servers and Skills
• defined approval gates for installation into agent runtimes
• scope limits for credentials, API access, and downstream actions
• logging that ties each tool invocation to a named owner and version
• revocation or quarantine procedures when a tool changes unexpectedly

NHIMG research on Analysis of Claude Code Security reinforces a practical point: tool trust must be continuously revalidated, not assumed from initial approval. That matters because MCP servers often sit close to secrets, internal APIs, and workflow automation, which means a compromised server can become a lateral movement path rather than a single bad plugin. The best practice is evolving toward policy-as-code, runtime allowlisting, and short-lived credentials, but there is no universal standard for this yet. These controls tend to break down when teams let developers self-install tools directly into production agents because approval ownership becomes ambiguous and audit trails fragment.

Common Variations and Edge Cases

Tighter approval controls often increase release friction, requiring organisations to balance developer speed against blast-radius reduction. That tradeoff becomes sharper when Skills are distributed across multiple repositories or when MCP servers are managed by third parties. In those cases, the question is not only who approved the tool, but who can prove ongoing oversight after the first release.

There are also edge cases where accountability is shared but not equal. A vendor-hosted Skill may be built externally, yet the enterprise still owns the decision to connect it to production data or privileged agents. Likewise, an internal platform team may operate the registry, but the application team still owns the business impact if the tool is over-permissioned. Guidance suggests that shared responsibility works only when the RACI is written down before deployment, not after an incident.

The broader NHIMG view of NHI governance in the Ultimate Guide to NHIs - The NHI Market is that accountability must include lifecycle management, not just access assignment. That is especially true when unreviewed tools can be added through marketplaces, CI pipelines, or prompt-driven workflows. In those environments, the cleanest answer is operational accountability at the point of approval and continuous accountability at the point of use.

Related resources from NHI Mgmt Group

• Who should be accountable when a high-risk code change reaches production without review?
• Who is accountable when a malicious MCP server exposes enterprise data or actions?
• Who is accountable when an MCP server is abused through a malicious package or proxy?
• Who is accountable when a malicious OTA update reaches production devices?