Who is accountable when a hosted MCP platform exposes credentials?

Accountability sits with both the platform owner and the organisation that chose to place sensitive credentials there. If a hosted environment concentrates many servers and secrets, a single platform flaw can become a multi-tenant incident. Governance teams should document ownership, isolation expectations, and re-approval rules for hosted tools.

Why This Matters for Security Teams

Hosted MCP platforms compress risk because they concentrate OWASP Top 10 for Agentic Applications 2026 style exposure into a shared control plane. When secrets are stored in a multi-tenant service, one misconfiguration, one vulnerable integration, or one weak support process can expose many organisations at once. That is why accountability is not just a vendor issue. It also sits with the customer that approved the design, accepted the isolation model, and allowed sensitive credentials to live in a hosted boundary.

Current guidance suggests treating hosted MCP as a shared-responsibility problem with explicit ownership, not as a fully outsourced control. The practical question is who approved the placement of secrets, who defined the isolation expectation, and who must prove that revocation, rotation, and access review happen on time. NHIMG research on secret exposure shows why this is so urgent: Guide to the Secret Sprawl Challenge documents how quickly hidden credentials spread across tooling, while 52 NHI Breaches Analysis shows that identity sprawl turns a single leak into a broader incident.

In practice, many security teams encounter the ownership gap only after exposed secrets have already been reused elsewhere, rather than through intentional governance.

How It Works in Practice

For hosted MCP, accountability should be split into three layers: platform accountability, customer accountability, and operational accountability. The platform owner is responsible for secure isolation, encryption, logging, support workflows, and prompt notification. The customer remains responsible for deciding whether credentials should be hosted there at all, classifying the secrets, and ensuring the service aligns with internal policy. Operational accountability usually sits with the team that integrated the mcp server and granted tool permissions, because they control the actual risk path.

That means good governance is not just a contract clause. It should include named owners, periodic re-approval, and a mandatory review of whether long-lived static credentials are even necessary. NHIMG’s Ultimate Guide to NHIs — Static vs Dynamic Secrets explains why short-lived secrets reduce blast radius, and the OWASP Non-Human Identity Top 10 reinforces that credential lifecycle controls matter as much as access policy.

• Define who owns the hosted MCP service, who owns each secret, and who can approve changes.
• Prefer JIT credential provisioning and workload identity over persistent API keys where possible.
• Use intent-based authorisation so the platform evaluates what the agent is trying to do at runtime.
• Require logging, revocation, and rotation evidence before reauthorising the platform.

For standards mapping, this aligns with NIST SP 800-63 Digital Identity Guidelines for identity assurance and the governance expectations in OWASP Agentic AI Top 10, especially where autonomous workloads can chain tool calls faster than humans can review them. These controls tend to break down when the hosted platform offers only coarse tenant separation and no per-credential audit trail, because ownership cannot be proven after the fact.

Common Variations and Edge Cases

Tighter isolation often increases cost and operational overhead, requiring organisations to balance shared-platform convenience against the risk of credential concentration. That tradeoff becomes sharper in regulated environments, where a hosted MCP platform may be acceptable for low-risk tool access but not for production secrets, privileged tokens, or cross-domain credentials. Best practice is evolving, and there is no universal standard for this yet.

One edge case is a hosted platform used only for non-sensitive discovery or sandbox work. In that scenario, accountability still exists, but the impact of a leak is lower if the tenant uses separate test credentials and no production scopes. Another edge case is when the platform manages secrets for autonomous agents rather than human users. In those environments, static role-based rules are often too blunt because agents behave dynamically, so current guidance favours policy evaluated at request time, with JIT secrets and clear workload identity. That is consistent with the direction of OWASP Top 10 for Agentic Applications 2026 and NIST SP 800-63 Digital Identity Guidelines.

For governance, the safest answer is simple: the platform owner is accountable for the hosted control plane, but the organisation that placed secrets there remains accountable for the decision, the review cadence, and the business impact if those secrets are exposed.

Related resources from NHI Mgmt Group

• How can organizations manage the risk of credential leaks in MCP frameworks?
• How do organisations reduce the dwell time of exposed credentials at scale?
• How should organisations stop auto-sync from turning desktops into repositories of credentials?
• What challenges do unmanaged API keys pose within MCP?