Problem
When a session is started on behalf of a user by a host application or an automated entry point, it runs under an application identity rather than the requesting user's identity. Any MCP server or external system that enforces per-user authorization therefore either denies the request or, worse, operates with broader permissions than the requesting user actually holds.
The available alternative is to configure long-lived static credentials centrally. That is unattractive for security review, does not reflect the requesting user's permissions, and is often not configurable by the teams that need it, because it requires organization-level administrative rights.
What is missing
- No supported model for delegated, least-privilege access on behalf of a requesting user.
- No distinction between user-delegated mode and workload-identity mode for unattended operation.
- No visibility into which identity and permission scope a given tool call used.
- Static credential configuration is only available to organization administrators, which blocks teams that cannot obtain those rights.
Proposed behavior
- A session can be created with a user-delegated credential, so MCP servers and external resources see the requesting user's effective permissions.
- A workload identity mode remains available for unattended operation where user delegation is inappropriate.
- Administrators can centrally approve MCP servers and policies, while individual sessions still obtain per-user authorization within those bounds.
- The session exposes, per tool call, which identity and scope were used, so access is auditable.
- Credentials never appear in prompts, model context, or serialized session state.
Example scenario
A session needs to read a work-tracking system and an internal data source, both of which authorize per user. The requesting user consents once; the session then acts within exactly that user's permissions and no further.
Acceptance criteria
- A documented authentication model covers both user-delegated and workload-identity modes.
- Least-privilege scopes are supported and enforced.
- Identity and scope for each external call are observable by the caller.
Related
Problem
When a session is started on behalf of a user by a host application or an automated entry point, it runs under an application identity rather than the requesting user's identity. Any MCP server or external system that enforces per-user authorization therefore either denies the request or, worse, operates with broader permissions than the requesting user actually holds.
The available alternative is to configure long-lived static credentials centrally. That is unattractive for security review, does not reflect the requesting user's permissions, and is often not configurable by the teams that need it, because it requires organization-level administrative rights.
What is missing
Proposed behavior
Example scenario
A session needs to read a work-tracking system and an internal data source, both of which authorize per user. The requesting user consents once; the session then acts within exactly that user's permissions and no further.
Acceptance criteria
Related