Who is accountable for securing MCP-related APIs across code, cloud, and runtime?

Why This Matters for Security Teams

MCP-related APIs do not stay neatly inside one control plane. They can be introduced in application code, exposed through cloud services, and exercised at runtime by automation that behaves differently from the original design. That creates a shared accountability problem: if ownership is split too loosely, discovery gaps and delayed remediation become the norm. The practical risk is not abstract. NHIMG’s The 2026 Infrastructure Identity Survey found that 52% of respondents see AI security decision-making power shifting toward platform and infrastructure teams.

That shift matters because API risk is usually distributed across build, deploy, and run stages. Security teams need application owners to know what was coded, cloud teams to know what was exposed, and platform owners to know what executed with real privilege. Current guidance suggests that accountability must be explicit enough to survive handoffs, incident response, and post-deployment drift, which is why NIST controls in NIST SP 800-53 Rev 5 Security and Privacy Controls remain relevant for assignment and review of responsibility. In practice, many security teams encounter ambiguous ownership only after an MCP-connected service has already been exploited or over-permissioned.

How It Works in Practice

The most effective operating model assigns one accountable owner and multiple collaborating teams. Application security owns the API design review, authentication flows, input validation, and any code-level exposure. Cloud security owns the deployment boundary, network exposure, secrets handling, and service-to-service trust. Platform governance owns policy enforcement, inventory, logging, and runtime guardrails. That division matches the reality that MCP-related APIs can appear in source repositories, in managed cloud endpoints, and in agent runtime paths such as tool calls or orchestration layers.

Practitioners should treat this as a traceability problem, not just an access problem. Start with an inventory of where MCP endpoints are defined, where they are deployed, and which identities can reach them. Then require security review at each stage:

• Code: identify MCP handlers, tool definitions, and embedded credentials before merge.
• Cloud: confirm exposed routes, IAM bindings, secret scopes, and logging coverage.
• Runtime: validate which identities can invoke tools, what policy is evaluated, and what gets revoked after use.

This is where runtime evidence becomes essential. NHIMG’s Analysis of Claude Code Security shows why code-adjacent AI systems can create new security paths faster than traditional review cycles. For governance, the OWASP Top 10 for Agentic Applications 2026 is useful for mapping risks such as excessive agency, tool misuse, and unsafe output handling to the teams that can actually fix them. These controls tend to break down when cloud teams deploy shared MCP services without an explicit application owner because no single team can prove end-to-end accountability.

Common Variations and Edge Cases

Tighter ownership often increases coordination overhead, requiring organisations to balance clear accountability against delivery speed. That tradeoff is real, especially in fast-moving platform environments where one API may be reused by several products or agents. The best practice is evolving, but current guidance suggests avoiding “everyone owns it” language because it usually means no one can answer for a failed control.

There are two common edge cases. First, in centrally managed platform teams, the platform may be operationally responsible for runtime controls while application teams remain accountable for the API design and intended use. Second, in highly regulated environments, compliance may require formal control owners distinct from engineering owners, but that does not replace technical accountability. If MCP APIs can reach sensitive systems, the accountable owner should still be able to state who can change them, who can approve exceptions, and who can revoke access.

NHIMG’s 230M AWS environment compromise illustrates why cloud exposure cannot be treated as a side issue, while the Snowflake breach reinforces that identity and access mistakes often become platform-scale incidents. Accountability gets blurry in multi-tenant platforms, embedded partner integrations, and agent fleets that self-initiate tool calls, because the service owner, the cloud owner, and the policy owner may all assume someone else is watching the same failure mode.

Related resources from NHI Mgmt Group

• How should security teams extend change management across design, code, and cloud?
• Who is accountable for network containment when MCP servers run across multiple clouds?
• Who is accountable for reducing attack surface across code, pipelines, and cloud assets?
• Who should own context-aware security decisions across code, pipelines, cloud, and runtime?