Accountability usually sits with the organisation that allowed the tool to run without sufficient provenance, isolation, and egress controls. In regulated environments, teams should also map the incident to secrets management, privileged access, and software supply chain control obligations.
Why This Matters for Security Teams
A hostile mcp server is not just “bad code”; it is an execution path that can observe, request, and exfiltrate developer secrets once a client trusts it enough to connect. That makes accountability a governance issue, not a mystery blame exercise. The operational failure usually starts earlier, in tool approval, network trust, and secrets exposure controls, which is why NHI programs now treat MCP-like integrations as part of the secrets and supply chain attack surface. NHIMG’s analysis of the State of MCP Server Security 2025 found that 24,008 unique secrets were exposed in MCP configuration files in 2025 alone.
Security teams often assume the developer owns the secret, the platform team owns the runtime, and the vendor owns the server. In practice, that split fails when the organisation permits a tool to run with broad trust and no provenance checks. This is why the OWASP Top 10 for Agentic Applications 2026 is increasingly relevant even for non-agentic MCP deployments: the risk is not only leakage, but autonomous tool execution against secrets and downstream systems. In practice, many security teams encounter the incident only after the secret has already been reused elsewhere, rather than through intentional control testing.
How It Works in Practice
Accountability normally follows control ownership, not just technical authorship. If the organisation approved an MCP server, connected it to internal resources, and allowed it to request secrets or tokens, then the organisation owns the failure to apply provenance, isolation, and egress restrictions. If a third-party server was introduced through an approved integration path, the question becomes whether procurement, platform security, and identity teams required enough evidence before trust was extended. The OWASP Non-Human Identity Top 10 is useful here because secret misuse is often the symptom of weak non-human identity governance, not a one-off developer mistake.
In practice, mature teams map responsibility across four layers:
- Tool onboarding: who approved the MCP server, its origin, and its code or package provenance.
- Identity and secrets: who issued the API keys, service tokens, or certificates, and whether they were scoped and short-lived.
- Runtime containment: who enforced sandboxing, network egress filtering, and least-privilege access to internal tools.
- Detection and response: who logged tool actions, detected abnormal secret access, and revoked credentials quickly.
That approach aligns with the NIST SP 800-53 Rev 5 Security and Privacy Controls expectation that access, audit, and configuration management are shared control responsibilities. It also fits NHIMG research on the Guide to the Secret Sprawl Challenge, which shows that fragmented secret ownership makes incident attribution and cleanup much harder. These controls tend to break down when MCP servers are allowed direct access to developer environments or cloud credentials because the server can chain requests faster than manual review can react.
Common Variations and Edge Cases
Tighter controls often increase friction for developers, so organisations have to balance speed against the risk of uncontrolled tool trust. That tradeoff becomes sharper when MCP servers are used for local development, CI pipelines, or rapid prototyping, where teams may accept broad permissions “temporarily” and never revisit them. Current guidance suggests that temporary exceptions should still have an owner, an expiry date, and a review path; there is no universal standard for this yet, but the direction is consistent across NHI and agentic AI guidance.
One edge case is a contractor-built or open-source MCP server that was never formally adopted, yet was still allowed to run in a workstation or build environment. In those cases, accountability may be shared between the user who installed it, the platform team that failed to restrict execution, and the organisation that lacked software provenance checks. Another edge case is when the server steals secrets from a local developer machine rather than a central vault. The secret owner may be the application team, but the control failure often sits with endpoint hardening, token storage, or browser and shell exposure practices.
For teams formalising governance, the practical test is simple: if the server can read secrets, call tools, or reach internal systems, then approval must include identity scoping, runtime isolation, and revocation authority. NHIMG’s OWASP Agentic Applications Top 10 and the Analysis of Claude Code Security both reinforce the same operational point: trust without containment turns a tool into a credential-moving threat surface.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Covers secret rotation and exposure handling when a tool steals developer credentials. |
| OWASP Agentic AI Top 10 | Agentic tool abuse models map closely to hostile MCP server behavior. | |
| CSA MAESTRO | Addresses governance for autonomous or tool-using systems that can access secrets. | |
| NIST AI RMF | Supports accountability and risk treatment for AI-enabled systems with autonomous actions. | |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access control is central when an MCP server can reach secrets. |
Inventory exposed secrets, revoke them fast, and enforce short-lived credentials for all non-human identities.
