MCP server collaboration raises new identity and trust boundaries

At a glance

What this is: This article explains how MCP servers are moving beyond one-way tool execution into collaborative workflows, with explicit review points for ambiguity, security, and control.

Why it matters: That matters because IAM teams now have to govern not just who or what can call a tool, but when server-side collaboration changes the identity, consent, and trust model around access.

By the numbers:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• 53% of MCP servers expose credentials through hard-coded values in configuration files.

👉 Read WorkOS's analysis of MCP server collaboration and elicitation patterns

Context

Model Context Protocol was designed around a clean request-response pattern, but production use has exposed a governance gap: sensitive flows, ambiguous requests, and server-side policy decisions do not fit neatly into a one-way model. For IAM and NHI teams, the question is how to preserve explicit control when servers start participating more actively in execution.

In practice, MCP collaboration patterns such as sampling and elicitation are not about giving the server full autonomy. They are about moving decisions into clearer checkpoints, where authentication, consent, and structured input can be handled without leaking secrets or guessing across identity boundaries. That distinction matters for both NHI governance and broader access control design.

Key questions

Q: How should security teams govern MCP workflows that mix models, servers, and users?

A: Treat MCP as a delegated workflow problem, not just a protocol feature set. Security teams should assign control points for sampling, external authorisation, and structured clarification, then log who approved each transition. The goal is to keep identity, consent, and execution boundaries explicit whenever a server participates more actively in the workflow.

Q: Why do MCP collaboration patterns change IAM and NHI assumptions?

A: Because they move important decisions into runtime. Traditional IAM assumes the access decision is made before execution and then enforced during use. MCP collaboration patterns create mid-session checkpoints, external identity interactions, and server-involved coordination, so governance must account for who had authority at each step, not just who had standing access.

Q: What breaks when MCP servers are allowed to initiate actions?

A: The clean request-response assumption breaks first, followed by the audit trail that depends on a single initiating identity. If servers can trigger downstream work, teams must distinguish between human intent, model reasoning, and server-originated execution. Without that separation, authority becomes difficult to prove after the fact.

Q: Should organisations treat MCP server collaboration as a Zero Trust problem?

A: Yes, but only if Zero Trust is applied to identity boundaries as well as network paths. The important question is whether each collaboration step is explicitly authorised, observable, and limited to the minimum required scope. If a workflow can cross from model context into authentication or execution without a clear trust boundary, it is already outside healthy Zero Trust practice.

Technical breakdown

Sampling in MCP: server-side prompting without silent execution

Sampling lets an MCP server ask the model for help with intermediate reasoning instead of acting as a passive responder. The server can request a completion, inspect assumptions, and then continue only after the human has reviewed the exchange. Architecturally, that creates a bounded collaboration loop: state stays with the server, reasoning is delegated to the model, and user oversight remains explicit. The important detail is that sampling does not remove control from the workflow; it makes the decision points more visible. In identity terms, this is closer to supervised delegation than autonomous execution.

Practical implication: define which server-initiated prompts are reviewable, and log the approval boundary before any downstream access occurs.

URL-mode elicitation and OAuth boundaries in MCP

URL-mode elicitation exists because some interactions must leave the model and client context entirely. OAuth authorisation, credential entry, and enterprise SSO are examples where secrets must not pass through the model context at all. The server pauses execution, sends the user to a trusted external surface, and resumes only after the callback returns. That makes the browser or identity provider the trust anchor, not the LLM or the MCP client. For security teams, the architectural lesson is that protocol convenience cannot override credential containment or federation boundaries.

Practical implication: route all credential-bearing or federated authentication flows through trusted external surfaces, never through the model context.

Form-mode elicitation for ambiguous execution paths

Form-mode elicitation handles runtime ambiguity by forcing structured input before execution continues. Instead of allowing the model to guess, the server asks for the missing variables in a JSON Schema and validates the response before selecting a path. This is especially relevant when environment, timing, or approval scope could change the security outcome. The mechanism matters because it replaces probabilistic interpretation with deterministic input capture. In governance terms, it is a control for ambiguity, not a guarantee of safety. It reduces the risk that the wrong action is taken simply because the request was underspecified.

Practical implication: require structured user input for environment-sensitive operations so ambiguous requests cannot fall through to implied defaults.

Threat narrative

Attacker objective: The objective is to exploit widened collaboration boundaries so that identity and execution decisions are made with less predictable oversight.

1. Entry occurs when a server accepts a user request that requires model assistance, then extends that request into a collaboration loop for reasoning or clarification.
2. Credential access or abuse appears when the workflow reaches an external authorisation step and the server must handle OAuth or other sensitive identity interactions outside the model context.
3. Escalation happens if the server begins to initiate tool use or execution paths without clear capability boundaries, turning collaboration into broader delegated authority.
4. Impact is the creation of a larger and less predictable trust surface, where identity, consent, and execution controls are harder to reason about end to end.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Server collaboration is not the same as server autonomy. MCP’s new patterns still rely on explicit checkpoints, human review, and constrained execution. That matters because many identity programmes will misread collaborative workflow as a reason to relax governance when the opposite is true. The stronger the server’s role in workflow coordination, the more carefully teams must define where trust begins and ends.

Identity review models built for static access do not map cleanly to runtime collaboration. Sampling and elicitation introduce decisions that happen during execution, not just at provisioning time. Access governance, approval logic, and audit design all need to account for identity-bearing interactions that resolve mid-session. Practitioners should treat runtime collaboration as a governance boundary, not a UX enhancement.

Shared control only works when the protocol keeps authority explicit. URL-mode elicitation is the clearest example here because it preserves the separation between the model context and the credential-bearing transaction. That is the standard to compare against whenever an AI workflow begins to touch authentication or sensitive authorisation steps. The lesson for practitioners is to preserve protocol boundaries that keep secrets out of the model path.

Bidirectional tool use creates a trust expansion problem, not just a feature discussion. Once servers can initiate actions or steer workflows, the identity question changes from “who called what” to “who is allowed to trigger what next.” That expands the policy surface across NHI, human approval, and emerging agentic workflows. Practitioners should re-evaluate whether their current controls can still explain who had authority at each step.

Runtime ambiguity is the named governance gap here. MCP servers are learning to collaborate because LLMs are too willing to guess when they should ask, and that exposes a broader assumption in identity governance: decision paths are known before execution begins. That assumption fails when the workflow depends on live clarification. The implication is that governance has to model uncertainty as an execution-state problem, not just an access-list problem.

From our research:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
• 48% of organisations still lack a complete blind spot for compliance and breach investigation when they cannot track and audit the data their AI agents access, according to SailPoint research.
• For a broader breach lens, review The 52 NHI breaches Report for how identity assumptions fail across real-world incidents.

What this signals

Runtime collaboration will push more identity decisions into the execution layer. That means programme owners should expect more controls to move from provisioning into workflow governance, especially where MCP servers touch authentication or structured approval flows. The practical shift is toward instrumentation that can prove who authorised each transition, not just who held access.

Runtime ambiguity: once systems start asking clarifying questions instead of guessing, governance can no longer treat uncertainty as a UX issue. It becomes an auditable state change that should be visible to IAM, NHI, and security operations teams. Teams that already struggle with machine-driven access reviews should expect the same problem to appear in MCP-linked workflows.

With SailPoint reporting that 80% of organisations have already seen agents act beyond intended scope, the direction of travel is clear: control models must assume active runtime behaviour, not passive tool use. MCP collaboration patterns make that gap more visible, which is useful only if practitioners translate visibility into policy and evidence.

For practitioners

• Map collaboration checkpoints to identity controls Identify every sampling, elicitation, or external authorisation step in MCP-enabled workflows and assign a named owner for approval, logging, and exception handling. Treat these checkpoints as governance events, not application details.
• Keep credential-bearing flows out of model context Require OAuth, SSO, payment, and token exchange to occur only through trusted external surfaces, with the model and client treated as untrusted for secret handling. This should be enforced in architecture review and threat modelling.
• Define policy for server-initiated actions now If your MCP roadmap includes bidirectional tool calls, predefine which tools a server may invoke, what runtime signals can trigger them, and which approvals must precede any server-originated execution.
• Instrument ambiguous workflows as audit events Log when a request is paused for structured clarification, what fields were missing, and how the final execution path was selected. That creates evidence for reviews when the wrong path would otherwise look like a normal request.

Key takeaways

• MCP collaboration is expanding, but the governance problem is still authority, consent, and traceability at runtime.
• Sampling, elicitation, and external authorisation reduce guessing, but they also create new checkpoints that identity teams must govern.
• Teams should focus on preserving credential boundaries and proving who authorised each step, especially as bidirectional tool use becomes more common.

Key terms

• Sampling: A collaboration pattern where an MCP server asks the model for a completion or intermediate reasoning instead of executing blindly. In practice, it adds a reviewable checkpoint to a workflow, allowing a human to inspect assumptions before the server continues.
• URL-mode elicitation: A protocol pattern that moves sensitive user interaction out of the MCP client and model context into a trusted external surface. It is used for OAuth, credential entry, and similar flows where secrets must stay outside the conversation path.
• Form-mode elicitation: A structured input mechanism that pauses execution until the user supplies required fields defined by schema. It replaces guessing with explicit runtime clarification, which is especially useful when the correct action depends on environment or approval scope.
• Bidirectional tool calls: A proposed MCP capability where servers can initiate actions or request tools, rather than only replying to model requests. This changes the governance problem from simple delegation to shared control over who can trigger downstream work.

Deepen your knowledge

MCP collaboration patterns and runtime identity boundaries are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is starting to govern AI-enabled workflows that cross authentication and execution boundaries, this is a strong place to begin.

This post draws on content published by WorkOS: Beyond request-response, how MCP servers are learning to collaborate. Read the original.