Who is accountable when an MCP client exposes tokens or executes hostile input?

Accountability sits across the application team, the identity team, and the platform owner because the failure spans protocol handling, endpoint policy, and local runtime behaviour. NIST zero trust and application security controls both apply, but neither replaces the need for client-side authorization governance.

Why This Matters for Security Teams

An MCP client is not just a transport layer. It is a policy enforcement point that can leak tokens, forward hostile prompts, or execute tool calls with the wrong trust assumptions. When the client handles credentials, input parsing, and outbound authorization, accountability becomes shared across the application team, the identity team, and the platform owner. That is why guidance from OWASP Agentic AI Top 10 and NIST zero trust thinking both matter here.

The practical risk is not abstract. NHIMG research shows that 44% of NHI tokens are exposed in the wild, often through collaboration tools and code paths that were not designed as secret stores, according to The 2025 State of NHIs and Secrets in Cybersecurity. In mcp environment, that means a client bug or unsafe logging decision can turn a local issue into a broad identity incident. In practice, many security teams encounter token exposure only after a downstream system has already accepted the leaked credential and started misusing it.

How It Works in Practice

Accountability should follow control ownership, not just root-cause blame. The application team owns how the MCP client validates input, isolates execution, and avoids passing raw tokens into untrusted contexts. The identity team owns credential issuance, scope, TTL, revocation, and whether the token is fit for a short-lived workload. The platform owner owns runtime guardrails such as endpoint policy, sandboxing, egress controls, logging hygiene, and alerting.

In a well-run design, the client should never rely on static trust in the model or the tool chain. Instead, it should use least-privilege tokens, short-lived credentials, and explicit request-time checks before any tool call. That lines up with NIST SP 800-53 Rev 5 Security and Privacy Controls, especially access control, audit logging, and system integrity expectations. For agentic systems, the safer pattern is to treat the client as a constrained broker, not a general-purpose executor.

• Use per-request or per-session tokens with narrow scope and automatic revocation.
• Validate and canonicalise tool input before it reaches execution paths.
• Block token material from logs, telemetry, crash dumps, and prompt history.
• Evaluate authorization at runtime, not only through static app roles.
• Require clear ownership for client code, identity policy, and platform controls.

These controls should be tested against hostile input, malformed tool responses, and prompt injection paths, not only normal traffic. NHIMG’s 52 NHI Breaches Analysis shows how often identity failures are followed by access abuse rather than contained as isolated events. These controls tend to break down when MCP clients run inside loosely governed developer workstations or shared CI runners because local debug logs, environment variables, and plug-in behavior can bypass the intended policy layer.

Common Variations and Edge Cases

Tighter client-side controls often increase development and operational overhead, requiring organisations to balance speed of integration against the cost of stronger validation and runtime isolation. That tradeoff is real, especially when teams want fast MCP adoption across multiple tools and agent flows.

There is no universal standard for exact accountability boundaries yet, so current guidance suggests using a RACI-style model that names the application owner for client behavior, the identity owner for token governance, and the platform owner for runtime containment. This becomes especially important when clients chain into other tools, because responsibility can blur if one system forwards secrets into another without explicit user intent. The broader agentic risk model in OWASP Agentic Applications Top 10 reinforces that hostile input and unauthorized action are design issues, not just incident-response issues.

One additional edge case is delegated access from third-party MCP hosts. In those setups, the host operator may control transport, while the app team still controls the client logic. That split can leave teams assuming someone else is monitoring token exposure. In practice, the accountability gap appears when a leaked token is still valid, still scoped broadly, and still accepted by downstream services before anyone has the authority to revoke it.

Related resources from NHI Mgmt Group

• Who is accountable when an MCP client exposes data through overbroad permissions?
• Who is accountable when client-side input history exposes regulated data?
• Who is accountable when a third-party MCP tool changes its description?
• What are the risks of using static credentials in MCP servers?