Sensitive actions inside the client blur the boundary between prompt handling and identity assurance. That can expose tokens, credentials, or payment data to the session context and create false confidence that a client acceptance equals successful authorization. The result is a weaker trust model and harder incident investigation.
Why This Matters for Security Teams
When sensitive user actions stay inside the MCP client, the client becomes both the place where intent is expressed and the place where trust is implicitly granted. That collapses two separate security decisions into one UI event. It is a problem for payment flows, privileged data access, and any action that should have explicit authorization outside the session context. The risk is not just exposure; it is also audit ambiguity.
Current guidance from the OWASP Agentic AI Top 10 and NHI research such as AI Agents: The New Attack Surface report points to the same structural issue: once a client can both collect sensitive input and trigger downstream actions, the trust boundary becomes easy to misread. In practice, teams often discover the weakness only after tokens, credentials, or sensitive records have already been handled inside the client session, rather than through deliberate control design.
How It Works in Practice
Safe MCP design treats the client as an interaction surface, not the final authority for sensitive operations. The client can capture intent, but the authoritative checks should happen in a broker, policy engine, or service that can evaluate identity, task scope, and risk at request time. That distinction matters because client-side approval does not prove that the user, agent, or workload is authorised to complete the action.
A workable pattern is to move sensitive actions behind runtime controls: short-lived credentials, explicit scoped tool permissions, and server-side policy evaluation. The emerging model is closer to intent-based authorization than static RBAC. For autonomous workloads, that means using workload identity to prove what the agent is, then issuing just-in-time credentials only for the task at hand. Standards and implementation guidance from OWASP Top 10 for Agentic Applications 2026 and the The State of MCP Server Security 2025 research both reinforce that hard-coded secrets and broad tool access are still common failure modes.
Operationally, security teams should separate the following functions:
- Session handling: the client may collect user intent, but should not hold long-lived secrets.
- Authorization: the server or policy layer should decide whether the action is allowed.
- Credential issuance: tokens should be ephemeral, scoped, and revoked after use.
- Audit logging: the sensitive action should be logged where the control decision is made, not only in the client.
This approach is also easier to defend when agents chain tools or move across systems, because the decision point remains outside the UI layer. These controls tend to break down when MCP clients are allowed to cache credentials locally or forward raw payment and identity data into tool calls without server-side policy enforcement.
Common Variations and Edge Cases
Tighter client-side controls often increase operational friction, requiring organisations to balance user experience against stronger authorization boundaries. That tradeoff is real, especially in workflows where the client needs to prefill data or guide a user through a regulated action.
There is no universal standard for this yet, but current guidance suggests that sensitive actions should be broken into two steps: client-side intent capture and server-side approval. This is especially important when the action touches secrets, payment information, or privileged admin functions. In those cases, the client should pass a minimal request, while the broker checks policy, risk signals, and workload identity before any secret is revealed or any action is executed.
Edge cases appear in multi-agent systems and embedded copilots, where one client session may trigger multiple downstream calls. The risk rises further when the mcp server itself stores secrets in configuration, a pattern highlighted in JetBrains GitHub plugin token exposure and other NHI incidents. The practical rule is simple: if the action matters enough to need trust, it is too sensitive to validate only inside the client. Security teams should assume the client can be compromised, instrumented, or simply misunderstood, then design for enforcement after the UI event rather than inside it.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A3 | Client-bound sensitive actions create confused trust and unsafe tool execution. |
| CSA MAESTRO | TRUST-03 | MAESTRO addresses agent trust boundaries and policy enforcement for tool use. |
| NIST AI RMF | AI RMF governance applies when client UX masks actual risk and authorization gaps. |
Move sensitive approvals out of the client and enforce runtime checks before tool execution.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
