What breaks when an MCP server is used without separate identity and secret selection for the agent and the user?

Why Separate Identity and Secret Selection Matters for MCP

An MCP server becomes risky when the agent and the user are collapsed into one credential path. The server can no longer tell whether a request should be authorized as an autonomous workload action or as a user-initiated action with different scope, approval, and audit requirements. That breaks least privilege, muddles accountability, and makes incident response slower because the evidence does not cleanly distinguish intent from execution. NHIMG research on The State of MCP Server Security 2025 shows why this matters operationally: 53% of MCP servers expose credentials in configuration files, and only 18% implement any form of tool scoping.

For teams working with autonomous assistants, the failure is not just over-permissioning. A single identity also hides where the task context changed, which secret was selected, and whether the agent exceeded the user’s intended authority. Current guidance suggests that MCP should preserve identity separation all the way through authorization and credential retrieval, not merely at login. In practice, many security teams discover the failure only after a tool action has already executed with the wrong principal attached, rather than through deliberate testing.

How It Works in Practice

The safer pattern is to treat the user and the agent as distinct decision subjects. The user establishes intent, while the agent executes a bounded task under its own workload identity. The MCP server should evaluate both at runtime: who requested the action, what the agent is allowed to do, and which secret is appropriate for that exact tool call. This is where separate identity and secret selection matter most. The agent should not inherit the user’s broad session token by default, and the user should not be forced to hold every secret needed by downstream tools.

A practical flow looks like this:

• The user authenticates and grants a task-specific scope.
• The agent receives an ephemeral workload identity or short-lived token for the action.
• The MCP server selects a secret based on the agent’s role, tool, and context, not on a shared session.
• Secrets are issued with tight TTLs and revoked after completion.
• Logs record both principals so reviewers can see who asked and what executed.

This approach aligns with the control logic described in NIST AI Risk Management Framework and the OWASP Agentic AI Top 10, both of which emphasise context-aware governance over static trust. It also matches the NHI guidance in Ultimate Guide to NHIs, where identity lifecycle, rotation, and visibility are core controls, not afterthoughts. These controls tend to break down in shared MCP deployments where multiple users, tools, and tenants reuse one server-side session because secret provenance becomes impossible to prove.

Common Variations and Edge Cases

Tighter separation often increases operational overhead, requiring organisations to balance stronger auditability against more complex orchestration. That tradeoff is real, especially in fast-moving agent pipelines where every additional approval step can slow tool execution. Current guidance suggests that the right answer depends on how much damage a tool can do if it is invoked with the wrong credential set.

There is no universal standard for this yet. Some environments use per-user delegated access for low-risk reads, while reserving agent-only service credentials for write actions or privileged tools. Others apply policy-as-code so the MCP server can choose a secret dynamically based on task type, data sensitivity, and risk signals. The key edge case is cross-tenant or shared-workspace systems: if the same MCP server brokers actions for many users, conflating identity can leak one user’s authority into another user’s task chain.

NHIMG’s The State of MCP Server Security 2025 also underscores the credential exposure problem behind these design choices. In environments that still store secrets in config files or hard-code them into tool manifests, identity separation alone is not enough. The model, the agent, and the secret source all need distinct controls, otherwise the system remains difficult to govern and easy to misuse.

Related resources from NHI Mgmt Group

• What breaks when an MCP server does not verify bearer tokens on agent connections?
• What breaks when an MCP server accepts user-controlled file paths without strict validation?
• What breaks when user behavior analytics is used without identity and threat context?
• What do security teams get wrong when they treat privileged account management as one control instead of separate account, user, and identity problems?