Who is accountable when an MCP server is abused through a malicious package or proxy?

Why This Matters for Security Teams

An mcp server abused through a malicious package or proxy is not just a software supply-chain incident. It is a governance failure because the connector sits on a path that can carry identity, tokens, and delegated tool access into production workflows. Current guidance suggests treating these components as part of the access plane, not as disposable integrations. That framing is reinforced by the OWASP Agentic AI Top 10 and NHIMG’s analysis of the State of MCP Server Security 2025, which shows how often tool access is left unscoped.

The practical question is who approved the connector, who trusted the package source, and who allowed the proxy to inherit privilege. If those decisions were made without workload identity, least privilege, and reviewable policy, accountability cannot be pushed downstream to the developer who merely installed a dependency. In the real world, malicious packages and reverse proxies usually succeed because teams treated them as plumbing rather than as production control points. In practice, many security teams encounter MCP abuse only after credentials are exposed or tool actions are already being replayed through an attacker-controlled path, rather than through intentional pre-deployment review.

How It Works in Practice

The accountable operating model is to place MCP connectors, proxies, and package sources under the same governance chain as other privileged production services. That means assigning an owner, defining an approval path, and requiring runtime controls for every tool invocation. The strongest pattern is emerging around workload identity and just-in-time access, not long-lived static secrets. When an MCP server or proxy needs to call a downstream system, it should prove what it is through cryptographic workload identity and obtain only the minimum privilege needed for the task.

Security teams should verify four things:

• Connector provenance is trusted and continuously monitored, including package integrity and publisher reputation.
• Tool permissions are explicitly scoped, rather than inherited from an overly broad service account.
• Secrets are short-lived and rotated automatically, with revocation when the task or session ends.
• Policy checks happen at request time, not just at onboarding, so a proxy cannot silently expand its reach.

This is where standards thinking matters. The OWASP Agentic AI Top 10 is useful for framing tool abuse and unsafe delegation, while NHIMG’s LiteLLM PyPI package breach shows how dependency compromise can become credential compromise. The operational takeaway is that approval should cover both the software artifact and the access model behind it. These controls tend to break down when teams allow unsigned or rapidly changing proxies to sit between the agent and downstream systems because the proxy becomes an unreviewed privilege amplifier.

Common Variations and Edge Cases

Tighter connector governance often increases friction for developers, requiring organisations to balance deployment speed against the cost of deeper review and shorter credential lifetimes. That tradeoff is real, especially when multiple teams share MCP infrastructure or when proxies are used to normalize access across many back-end systems. There is no universal standard for this yet, but current guidance suggests that shared MCP services need clearer ownership than ad hoc sidecar tooling.

Edge cases matter. A package maintainer compromise is still the responsibility of the team that chose to trust that package in production. A reverse proxy that transforms or relays requests does not remove accountability if it also widens access, stores tokens, or logs secrets. Likewise, if an MCP server is operated by a platform team but approved by application owners, responsibility is distributed, not erased. The cleanest model is shared accountability with a named service owner, a named approver for access scope, and a security function that validates whether the runtime policy matches the intended use.

NHIMG’s AI Agents: The New Attack Surface report and the Shai Hulud npm malware campaign both reinforce the same lesson: once a connector can execute or delegate privileges, accountability must follow the access path, not the convenience boundary. The model breaks down fastest in environments that rely on unsigned community packages and standing secrets inside shared proxies.

Related resources from NHI Mgmt Group

• Who is accountable when an AI agent takes action through an MCP server?
• Who is accountable when malicious code enters through a package registry?
• Who is accountable when a malicious MCP server exposes enterprise data or actions?
• Who should own MCP server risk in an IAM programme?