Who is accountable when an MCP App exposes unsafe content or a Task runs beyond policy?

Accountability should sit with the teams that own gateway policy, application design, and operational oversight, not with the protocol itself. The protocol defines the mechanism, but the enterprise must decide launch rights, budgets, timeouts, and guardrails. Security, platform, and application owners should share responsibility for enforcing those controls and proving they work during review and incident response.

Why This Matters for Security Teams

Accountability becomes ambiguous the moment an MCP App can call tools, retrieve data, or continue a task after the original request has drifted out of policy. The protocol itself is not the control plane. Enterprise teams still need ownership for launch approval, policy design, data boundaries, and incident response. That is why current guidance from OWASP Agentic AI Top 10 and NIST Cybersecurity Framework 2.0 both push responsibility toward governance, not transport mechanics.

In NHI operations, this is not theoretical. NHIMG’s AI Agents: The New Attack Surface report found that 80% of organisations report AI agents have already performed actions beyond intended scope, while only 44% have implemented policies to govern them. That gap matters because unsafe content is often a symptom of broader control failure, not a single bad prompt or one-off tool call. In practice, many security teams encounter the breach trail only after the MCP App has already exposed data, exceeded time bounds, or chained actions across systems.

How It Works in Practice

The cleanest accountability model is shared, but not vague. The application owner is responsible for what the MCP App is allowed to do, the platform or gateway team is responsible for enforcement, and the security function is responsible for policy, auditability, and review. The question is not whether the protocol permits a task to continue. The question is whether the enterprise issued a bounded authorisation for that work and can prove it.

In operational terms, this usually means three layers of control. First, define launch rights and task scopes in policy, including what content classes, tools, and data sources are in-bounds. Second, enforce timeouts, budgets, and revocation at the gateway so a task cannot keep running indefinitely. Third, log the decision path, task owner, and resource usage so that a review can show who approved the action and why.

• Use policy-as-code to decide whether a task may start, continue, or terminate.
• Issue short-lived credentials or task-specific tokens rather than standing access.
• Separate content moderation from execution approval, because unsafe output and unsafe action are different failures.
• Require traceable ownership for the MCP App, the connected tools, and the downstream data set.

That approach is consistent with NIST CSF 2.0 and the control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls, which both assume accountable owners, measurable enforcement, and reviewable logs. NHIMG’s Regulatory and Audit Perspectives section reinforces that point for NHIs: if the system can act, it must also be auditable. These controls tend to break down when MCP deployments are embedded inside fast-moving engineering teams with no explicit policy owner and no gateway-level kill switch.

Common Variations and Edge Cases

Tighter MCP governance often increases delivery overhead, requiring organisations to balance developer speed against assurance and traceability. That tradeoff becomes sharper when teams want autonomous tasks, but do not want the operational burden of reviewing every action.

There is no universal standard for this yet, but current guidance suggests that accountability shifts with the control point. If the unsafe content comes from a model response, the application team still owns the deployment and safety guardrails. If a task runs beyond policy because the gateway failed to stop it, platform owners may be accountable for enforcement gaps. If a human approved an overbroad task scope, the approval workflow is the failure. In practice, the right answer depends on where the decision was supposed to be made, and whether that decision was logged.

Edge cases often appear in delegated or multi-tenant environments. A central platform team may set generic limits, while product teams define their own task policies. In that model, shared responsibility works only if ownership boundaries are explicit and reviewed regularly. NHIMG’s Lifecycle Processes for Managing NHIs is useful here because it frames identity governance as a lifecycle problem, not a one-time configuration. When MCP Apps are allowed to chain tools across business units, accountability usually breaks down because no single team can explain the full execution path after the fact.

Related resources from NHI Mgmt Group

• How can organizations manage the risk of credential leaks in MCP frameworks?
• What challenges do unmanaged API keys pose within MCP?
• Who is accountable when a Docker API policy bypass exposes host secrets?
• Who is accountable when an MCP client exposes data through overbroad permissions?