The model breaks when the system assumes a logged-in customer is the same thing as explicit agent delegation. MCP can drive many tool calls across multiple systems in one session, so authentication alone does not prove authority for each action. Teams need machine-readable consent, scoped delegation, and traceable attribution for every downstream call.
What breaks in the customer identity model when MCP assumes a human session?
The first thing that breaks is the trust boundary. A customer login proves a person is present in the browser or app, but it does not automatically prove authority for each tool action an MCP workflow may trigger across systems.
That mismatch turns a simple authenticated session into an overbroad delegation channel. Once the workflow fans out into multiple requests, the system needs explicit consent, scope, and attribution for each downstream action, not just a valid initial session.
Why human-session authentication is not enough for delegated actions
MCP changes the shape of the transaction. A single customer session can result in repeated calls, cross-system operations, and state changes that are materially different from the original login event, so the security question becomes “who authorised this action?” rather than only “who authenticated at the start?”
That is why this pattern needs machine-readable delegation rather than informal user presence. The workflow must carry enough context to distinguish a user’s general login from a specific grant to act on that user’s behalf, especially when the call chain spans apps, services, or tool gateways.
In identity terms, this is the same reason teams separate authentication from authorisation and governance. A session can be valid while still being too broad, too long-lived, or too weakly attributed for the underlying business action.
What customer-facing MCP workflows must preserve end to end
Customer identity workflows need three things to survive the move from login to tool execution: explicit consent, narrowly scoped delegation, and durable auditability. Those three controls make the downstream calls defensible when the workflow is replayed, reviewed, or challenged later.
Good practice is to bind the delegated right to a specific purpose, system, and time window. If the workflow can continue after the user intent has changed, or if a different tool can reuse the same session context without fresh authorisation, the model is too loose for customer-facing action.
That is also where attribution matters. Each downstream call should remain traceable to the original user consent and the exact agent or workflow step that consumed it, so investigators can reconstruct whether the action was user-approved, overreached, or improperly reused.
For teams studying the identity side of this problem, Customer IAM (CIAM) Guide is the most direct internal reference for consent, customer authentication, and delegated access patterns.
For the broader boundary between people, machines, and delegated access, Human vs Non-Human Identity explains why human login state and machine authority are not interchangeable.
For workflows that need identity and privilege discipline across repeated operations, IAM and IGA Basics provides the core distinction between authentication, authorisation, entitlements, and governance.
Risk and Threat Considerations
When a human-session model is stretched across an MCP workflow, the main risk is confused authority. A valid login can be reused for actions the customer never intended, and a compromise of the workflow, token, or tool chain can turn a normal session into a broad impersonation path.
Failure mechanism: The system treats session possession as blanket permission, so delegated tool calls inherit authority without a fresh, machine-readable consent or scope check. That creates an abuse path for overreach, replay, and misuse across multiple downstream systems.
Impact: The result can be unauthorised account changes, data exposure, or customer-initiated actions being executed outside the intended scope. It also weakens auditability, because investigators cannot easily prove which calls were explicitly approved and which were merely convenient extensions of an active session.
For the protocol side of the boundary, the Model Context Protocol: Authorization specification is the clearest external reference for audience-bound tokens and avoiding token passthrough.
The agentic security lens is also relevant because delegated tool use can become identity and privilege abuse when authority is too broad; the OWASP Agentic AI Top 10 captures that control failure well.
When the workflow depends on user tokens or bearer-style delegation, sender-constraining helps reduce replay risk. The RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP) is directly relevant to binding a token to the client that should use 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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | MCP workflows can overextend delegated authority across tool calls. |
| Recommendation — Bind each tool action to explicit scope and authority checks. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Customer sessions and downstream calls depend on sound credential and token handling. |
| AC-6 — Least Privilege | The workflow must limit each downstream action to minimum necessary authority. | |
| Recommendation — Rotate and scope authenticators that carry customer authority. Constrain delegated access to the minimum action scope required. | ||
| OWASP ASVS | V8 — Authorization | Per-action authorisation is central when a session fans out into multiple tool calls. |
| V10 — OAuth and OIDC | MCP delegation relies on token-based identity and consent flow correctness. | |
| Recommendation — Require explicit authorization checks for every state-changing action. Use scoped OAuth flows that preserve user consent and token audience. | ||
Practitioner Guidance
What to verify: Verify that every MCP-exposed action has its own authorisation decision, not just a shared session token. If a downstream tool can move money, change data, or trigger side effects, the workflow needs an explicit delegation record that survives outside the browser session.
Decision rule: If the system cannot answer “who approved this exact call?” with a durable record, treat the design as too permissive for customer identity use. In that case, prefer scoped consent, step-up approval for sensitive actions, and per-call attribution over session-wide trust.
Practitioner takeaway: The right design is not “user logged in, therefore all tool calls are allowed”, it is “each meaningful action has provable user authority, bounded scope, and traceable execution.”